draft-ietf-bliss-shared-appearances-13.txt   draft-ietf-bliss-shared-appearances-14.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261, 4235 (if approved) M. Soroushnejad Updates: 3261, 4235 (if approved) M. Soroushnejad
Intended status: Standards Track V. Venkataramanan Intended status: Standards Track V. Venkataramanan
Expires: January 31, 2013 Sylantro Systems Corp Expires: June 24, 2013 Sylantro Systems Corp
July 30, 2012 December 21, 2012
Shared Appearances of a Session Initiation Protocol (SIP) Address of Shared Appearances of a Session Initiation Protocol (SIP) Address of
Record (AOR) Record (AOR)
draft-ietf-bliss-shared-appearances-13 draft-ietf-bliss-shared-appearances-14
Abstract Abstract
This document describes the requirements and implementation of a This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as shared appearances of an Address Protocol (SIP), it is referred to as shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. This of Record (AOR) since SIP does not have the concept of lines. This
feature is commonly offered in IP Centrex services and IP-PBX feature is commonly offered in IP Centrex services and IP-PBX
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2013. This Internet-Draft will expire on June 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements and Implementation . . . . . . . . . . . . . . . 7 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9
5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12 5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12
5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 12 5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 13
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13 5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 14 5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 14
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14
5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17
5.3.2. Appearance Numbers and Call Control . . . . . . . . . 18 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 18
5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 19 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 19
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21
7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23 7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23
8. User Interface Considerations . . . . . . . . . . . . . . . . 24 8. User Interface Considerations . . . . . . . . . . . . . . . . 24
skipping to change at page 4, line 17 skipping to change at page 4, line 17
11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58
11.12. Appearance Seizure Contention Race Condition . . . . . . 59 11.12. Appearance Seizure Contention Race Condition . . . . . . 59
11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60
11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62
11.15. Appearance Seizure Incoming/Outgoing Contention Race 11.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . . 65 Condition . . . . . . . . . . . . . . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 66 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
13.1. SIP Event Header Field Parameter: shared . . . . . . . . 66 13.1. SIP Event Header Field Parameter: shared . . . . . . . . 66
13.2. SIP Alert-Info Header Field Parameter: appearance . . . . 67 13.2. SIP Alert-Info Header Field Parameter: appearance . . . . 67
13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 67 13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68
13.4. XML Schema Registration . . . . . . . . . . . . . . . . . 68 13.4. XML Schema Registration . . . . . . . . . . . . . . . . . 68
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
15.1. Normative References . . . . . . . . . . . . . . . . . . 69 15.1. Normative References . . . . . . . . . . . . . . . . . . 69
15.2. Informative References . . . . . . . . . . . . . . . . . 70 15.2. Informative References . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction 1. Introduction
The feature and functionality requirements for SIP user agents (UAs) The feature and functionality requirements for SIP user agents (UAs)
supporting business telephony applications differ greatly from basic supporting business telephony applications differ greatly from basic
SIP user agents, both in terms of services and end user experience. SIP user agents, both in terms of services and end user experience.
In addition to basic SIP support [RFC3261], many of the services in a In addition to basic SIP support [RFC3261], many of the services in a
business environment require the support for SIP extensions such as business environment require the support for SIP extensions such as
REFER [RFC3515], SUBSCRIBE/NOTIFY primitives REFER [RFC3515], SUBSCRIBE/NOTIFY primitives
[I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces
skipping to change at page 8, line 10 skipping to change at page 8, line 10
REQ-3 A UA must be able to join (also called bridge or conference REQ-3 A UA must be able to join (also called bridge or conference
together) or pick up (take) an active call of another UA in the group together) or pick up (take) an active call of another UA in the group
in a secure way. in a secure way.
REQ-4 The mechanism should require the minimal amount of REQ-4 The mechanism should require the minimal amount of
configuration. UAs registering against the group AOR should be able configuration. UAs registering against the group AOR should be able
to participate in the appearance group without manual configuration to participate in the appearance group without manual configuration
of group members. of group members.
REQ-5 The mechanism must scale for large numbers of appearances, n, REQ-5 The mechanism must scale for large numbers of appearances and
and large numbers of UAs, N, without introducing excessive messaging large numbers of UAs without introducing excessive messaging traffic.
traffic.
REQ-6 Each call or session (incoming or outgoing) should be assigned REQ-6 Each call or session (incoming or outgoing) should be assigned
a common "appearance" number from a managed pool administered for the a common "appearance" number from a managed pool administered for the
AOR group. Once the session has terminated, the appearance number is AOR group. Once the session has terminated, the appearance number is
released back into the pool and can be reused by another incoming or released back into the pool and can be reused by another incoming or
outgoing session. outgoing session.
REQ-7 Each UA in the group must be able to learn the status of all REQ-7 Each UA in the group must be able to learn the status of all
appearances of the group. appearances of the group.
REQ-8 There must be mechanisms to resolve appearance contention among REQ-8 There must be mechanisms to resolve appearance contention among
the UAs in the group. the UAs in the group. Contention in this context means an appearance
number being associated with multiple dialogs that are not mixed or
otherwise associated.
REQ-9 The mechanism must allow all UAs receiving an incoming session REQ-9 The mechanism must allow all UAs receiving an incoming session
request to utilize the same appearance number at the time of request to utilize the same appearance number at the time of
alerting. alerting.
REQ-10 The mechanism must have a way of reconstructing appearance REQ-10 The mechanism must have a way of reconstructing appearance
state after an outage that does not result in excessive traffic and state after an outage that does not result in excessive traffic and
processing. processing.
REQ-11 The mechanism must have backwards compatibility such that a UA REQ-11 The mechanism must have backwards compatibility such that a UA
skipping to change at page 9, line 28 skipping to change at page 9, line 29
This section non-normatively discusses the implementation of the This section non-normatively discusses the implementation of the
shared appearance feature. The normative description is in shared appearance feature. The normative description is in
Section 5. Many of the requirements for this service can be met Section 5. Many of the requirements for this service can be met
using standard SIP mechanisms such as: using standard SIP mechanisms such as:
- A SIP Forking Proxy and Registrar/Location Service meets REQ-1. - A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
- The SIP Dialog Package meets REQ-2. - The SIP Dialog Package meets REQ-2.
- The SIP Replaces and Join header fields meets REQ-3. - The combination of the SIP Replaces and Join header fields meets
REQ-3.
- The use of a State Agent for the Dialog Package meets REQ-4 and - The use of a State Agent for the Dialog Package meets REQ-4 and
REQ-5. REQ-5.
REQ-6 suggests the need for an entity which manages the appearance REQ-6 suggests the need for an entity which manages the appearance
resource. Just as conferencing systems commonly have a single point resource. Just as conferencing systems commonly have a single point
of control, known as a focus, a Shared Appearance group has a single of control, known as a focus, a Shared Appearance group has a single
point of control of the appearance shared resource. This is defined point of control of the appearance shared resource. This is defined
as an Appearance Agent for a group. While an Appearance Agent can be as an Appearance Agent for a group. While an Appearance Agent can be
part of a centralized server, it could also be co-resident in a part of a centralized server, it could also be co-resident in a
skipping to change at page 10, line 11 skipping to change at page 10, line 13
(e.g. when two UAs request the use of the same appearance number, (e.g. when two UAs request the use of the same appearance number,
hash dialog identifiers and compare with the lowest hash winning) hash dialog identifiers and compare with the lowest hash winning)
would need to be defined and implemented. would need to be defined and implemented.
To best meet REQ-9, the appearance number for an incoming INVITE To best meet REQ-9, the appearance number for an incoming INVITE
needs to be contained in the INVITE, in addition to being delivered needs to be contained in the INVITE, in addition to being delivered
in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or
lost, a UA in the group might receive an incoming INVITE but might lost, a UA in the group might receive an incoming INVITE but might
not know which appearance number to render during alerting. not know which appearance number to render during alerting.
This specification defines an extension parameter for the Alert-Info This specification defines an extension parameter, which is
header field in RFC 3261 to carry the appearance number: normatively defined in Section 7, for the Alert-Info header field in
RFC 3261 to carry the appearance number:
Alert-Info: <urn:alert:service:normal>;appearance=1 Alert-Info: <urn:alert:service:normal>;appearance=1
The following list describes the operation of the shared appearance The following list describes the operation of the shared appearance
feature. feature.
1. A UA is configured with the AOR of a shared appearance group. It 1. A UA is configured with the AOR of a shared appearance group. It
registers against the AOR, then attempts a dialog state registers against the AOR, then attempts a dialog state
subscription to the AOR. If the subscription fails, loops back subscription to the AOR. If the subscription fails, loops back
to itself, or returns an error, it knows there is no State Agent, to itself, or returns an error, it knows there is no State Agent,
skipping to change at page 11, line 33 skipping to change at page 11, line 34
This section normatively describes the shared appearance feature This section normatively describes the shared appearance feature
extensions. The following definitions are used throughout this extensions. The following definitions are used throughout this
document: document:
Appearance number: An appearance number is a positive integer Appearance number: An appearance number is a positive integer
associated with one or more dialogs of an AOR. Appearance numbers associated with one or more dialogs of an AOR. Appearance numbers
are managed by an Appearance Agent and displayed and rendered to the are managed by an Appearance Agent and displayed and rendered to the
user by UAs that support this specification. When an appearance user by UAs that support this specification. When an appearance
number is assigned or requested, generally the assigned number is the number is assigned or requested, generally the assigned number is the
smallest positive integer that is not currently assigned as an smallest positive integer that is not currently assigned as an
appearance number to a dialog for this AOR. appearance number to a dialog for this AOR. This specification does
not define an upper limit on appearance numbers; however, using
appearance numbers that are not easily represented using common
integer representations is likely to cause failures.
Seizing: An appearance can be reserved prior to a call being placed Seizing: An appearance can be reserved prior to a call being placed
by seizing the appearance. An appearance can be seized by by seizing the appearance. An appearance can be seized by
communicating an artificial state of "trying" prior to actually communicating an artificial state of "trying" prior to actually
initiating a dialog (i.e. sending the INVITE), in order to appear as initiating a dialog (i.e. sending the INVITE), in order to appear as
if it was already initiating a dialog. if it was already initiating a dialog.
Selecting(or Not-Seizing): An appearance is merely selected (i.e., Selecting(or Not-Seizing): An appearance is merely selected (i.e.,
not seized) if there is no such communication of artificial state of not seized) if there is no such communication of artificial state of
"trying" prior to initiating a dialog: i.e., the state is "trying" prior to initiating a dialog: i.e., the state is
skipping to change at page 14, line 41 skipping to change at page 14, line 44
the Appearance Agent that the UA supports this specification. the Appearance Agent that the UA supports this specification.
Upon initialization, the UA MUST subscribe to the dialog event Upon initialization, the UA MUST subscribe to the dialog event
package of the AOR and refresh the subscription per the SIP Events package of the AOR and refresh the subscription per the SIP Events
Framework. If the SUBSCRIBE request fails, then no Appearance Agent Framework. If the SUBSCRIBE request fails, then no Appearance Agent
may be present and this feature is not active for this AOR. The UA may be present and this feature is not active for this AOR. The UA
MAY periodically retry the subscription to see if conditions have MAY periodically retry the subscription to see if conditions have
changed at intervals no shorter than 4 hours. changed at intervals no shorter than 4 hours.
Four hours was chosen to limit the subscription test to 6 per day Four hours was chosen to limit the subscription test to 6 per day
per UA. Increading this interval would reduce this failure per UA. Increasing this interval would reduce this failure
traffic but take longer for a newly activated Appearance Agent to traffic but take longer for a newly activated Appearance Agent to
be discovered. be discovered.
UAs can also use the presence of the 'shared' Event header field UAs can also use the presence of the 'shared' Event header field
parameter in NOTIFYs to discover the presence of an Appearance Agent parameter in NOTIFYs to discover the presence of an Appearance Agent
for the AOR. for the AOR.
User Agents which implement the shared appearances feature and call User Agents which implement the shared appearances feature and call
pickup, joining and bridging MUST support sending an INVITE with pickup, joining and bridging MUST support sending an INVITE with
Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to
skipping to change at page 15, line 16 skipping to change at page 15, line 19
All User Agents which implement the shared appearances feature and All User Agents which implement the shared appearances feature and
support INVITE MUST support receiving an INVITE with a Replaces support INVITE MUST support receiving an INVITE with a Replaces
[RFC3891] or a Join [RFC3911] header field. [RFC3891] or a Join [RFC3911] header field.
When publishing or notifying dialog package information, a UA MUST When publishing or notifying dialog package information, a UA MUST
include all dialog identification available at the time of include all dialog identification available at the time of
publication, with the exception that a UA may omit information if it publication, with the exception that a UA may omit information if it
wishes to prevent other UAs from joining or picking up a call. wishes to prevent other UAs from joining or picking up a call.
Dialog identification includes local and remote target URIs, call-id, Dialog identification includes local and remote target URIs, call-id,
to-tag, and from-tag. When calls are placed on hold, the to-tag, and from-tag. When placing calls on hold, use the
"+sip.rendering=no" feature tag MUST be included in dialog package "+sip.rendering=no" feature tag to indicate this in dialog package
notifications. notifications. Using the full SDP session description instead forces
the endpoint to do a lot of extra parsing, unnecessarily complicating
the code and inviting errors.
The accurate rendering of the idle/active/alerting/hold state of The accurate rendering of the idle/active/alerting/hold state of
other UAs in the group is an important part of the shared other UAs in the group is an important part of the shared
appearance feature. appearance feature.
In the following cases, before sending the INVITE, A UA MUST send a If the call is an emergency call, a UA MUST never wait for a
dialog package PUBLISH request and wait for a 2xx response before confirmed seizure before sending an INVITE. Instead, the emergency
proceeding: call MUST proceed without waiting for the PUBLISH transaction.
Otherwise, in the following cases, before sending the INVITE, a UA
MUST send a dialog package PUBLISH request and wait for a 2xx
response before proceeding:
1. When the user seizes a particular appearance number for an 1. When the user seizes a particular appearance number for an
outgoing call (e.g. seizing the appearance and going "off-hook", outgoing call (e.g. seizing the appearance and going "off-hook",
if the UA's user interface uses this metaphor). if the UA's user interface uses this metaphor).
2. When the user has requested that an appearance number not be used 2. When the user has requested that an appearance number not be used
for an outgoing call (i.e. during a consultation call, a 'service for an outgoing call (i.e. during a consultation call, a 'service
media' call such as for music on hold media' call such as for music on hold
[I-D.worley-service-example] or for a call not considered part of [I-D.worley-service-example] or for a call not considered part of
the shared appearance group). the shared appearance group).
3. When the user has selected to join (or bridge) an existing call. 3. When the user has selected to join (or bridge) an existing call.
4. When the user has selected to replace (or take) an existing call. 4. When the user has selected to replace (or take) an existing call.
An exception is an emergency call, when a UA MUST never wait for a
confirmed seizure before sending an INVITE. Instead, the emergency
call MUST proceed without waiting for the PUBLISH transaction.
Note that when a UA seizes an appearance prior to establishment of a Note that when a UA seizes an appearance prior to establishment of a
dialog (#1 and #2 in above list), not all dialog information will be dialog (#1 and #2 in above list), not all dialog information will be
available. In particular, when a UA publishes an attempt to seize an available. In particular, when a UA publishes an attempt to seize an
appearance prior to knowing the destination URI, minimal or no dialog appearance prior to knowing the destination URI, minimal or no dialog
information may be available. For example, in some cases, only the information may be available. For example, in some cases, only the
local target URI for the call will be known and no dialog local target URI for the call will be known and no dialog
information. If the From tag and Call-ID were not present in the information. If the From tag and Call-ID were not present in the
initial PUBLISH, a new PUBLISH MUST be sent as soon as this initial PUBLISH, a new PUBLISH MUST be sent as soon as this
information is available. information is available.
skipping to change at page 16, line 30 skipping to change at page 16, line 35
desired and intended appearance number operations. Once a dialog desired and intended appearance number operations. Once a dialog
transitions from early to confirmed, this role is over, and hence transitions from early to confirmed, this role is over, and hence
no publication refreshes are needed. no publication refreshes are needed.
Appearance numbers are a shorthand label for active and pending Appearance numbers are a shorthand label for active and pending
dialogs related to an AOR. Many of the features and services built dialogs related to an AOR. Many of the features and services built
using this extension rely on the correct rendering of this using this extension rely on the correct rendering of this
information to the human user. In addition, the group nature of the information to the human user. In addition, the group nature of the
feature means that the rendering must be similar between different feature means that the rendering must be similar between different
vendors and different models. Failure to do so will greatly reduce vendors and different models. Failure to do so will greatly reduce
the value and usefulness of these protocol extensions. The the value and usefulness of these protocol extensions. In a
appearances number for each active and pending dialog SHOULD be correctly designed user interface for this feature, the appearances
explicitly (i.e. by appearance number) or implicitly (using a user number for each active and pending dialog is explicitly (i.e. by
interface metaphor that makes the numbering and ordering clear to the appearance number) or implicitly (using a user interface metaphor
user) rendered to the user. The far end identity of each dialog that makes the numbering and ordering clear to the user) rendered to
(e.g. the remote party identity) MUST NOT be rendered in place of the the user. The far end identity of each dialog (e.g. the remote party
appearance number. The state of each appearance SHOULD also be identity) is not a useful replacement for the appearance number. The
rendered (idle, active, busy, joined, etc.). UAs can tell that a set state of each appearance is also be rendered (idle, active, busy,
of dialogs are joined (bridged or mixed) together by the presence of joined, etc.). UAs can tell that a set of dialogs are joined
one or more <joined-dialog> elements containing other SIP dialog (bridged or mixed) together by the presence of one or more <joined-
identifiers. Appearance numbers of dialogs can be learned by dialog dialog> elements containing other SIP dialog identifiers. Appearance
package notifications containing the <appearance> element from the numbers of dialogs can be learned by dialog package notifications
Appearance Agent or from the 'appearance' Alert-Info parameter in an containing the <appearance> element from the Appearance Agent or from
incoming INVITE. Should they conflict, the dialog package the 'appearance' Alert-Info parameter in an incoming INVITE. Should
notification takes precedence. they conflict, the dialog package notification takes precedence.
A UA that does not need to seize a particular appearance number (or A UA that does not need to seize a particular appearance number (or
doesn't care) would just send an INVITE as normal to place an doesn't care) would just send an INVITE as normal to place an
outbound call. outbound call.
A user may select an appearance number but then abandon placing a A user may select an appearance number but then abandon placing a
call (go back on hook). In this case, the UA MUST free up the call (go back on hook). In this case, the UA frees up the appearance
appearance number by removing the event state with a PUBLISH as number by removing the event state with a PUBLISH as described in
described in [RFC3903]. [RFC3903]. A failure to do this will require extra unnecessary
operations by the Appearance Agent, and also tie up appearance
numbers which could otherwise be used by other UAs in the appearance
group.
A UA SHOULD register against the AOR only if it is likely the UA will A UA SHOULD register against the AOR only if it is likely the UA will
be answering incoming calls. If the UA is mainly going to be be answering incoming calls. If the UA is mainly going to be
monitoring the status of the shared appearance group calls and monitoring the status of the shared appearance group calls and
picking or joining calls, the UA SHOULD only subscribe to the AOR and picking or joining calls, the UA SHOULD only subscribe to the AOR and
not register against the AOR. not register against the AOR. If a monitoring UA registers rather
than just subscribing generates large amounts of unnecessary network
traffic.
All subscribed UAs will receive dialog package NOTIFYs of trying All subscribed UAs will receive dialog package NOTIFYs of trying
state for incoming INVITEs. state for incoming INVITEs.
A UA MUST NOT insert an 'appearance' parameter into an Alert-Info A UA MUST NOT insert an 'appearance' parameter into an Alert-Info
header field in an INVITE or other request. header field in an INVITE or other request.
The Appearance Agent is solely responsible for doing this. The Appearance Agent is solely responsible for doing this.
5.3.1. Appearance Numbers and Call Context 5.3.1. Appearance Numbers and Call Context
skipping to change at page 18, line 52 skipping to change at page 19, line 12
There are two possible scenarios using the terminology of RFC 5589: There are two possible scenarios using the terminology of RFC 5589:
Alice is the transferee in any type of transfer (receives the REFER) Alice is the transferee in any type of transfer (receives the REFER)
or the transfer target in an attended transfer (receives the INVITE or the transfer target in an attended transfer (receives the INVITE
with Replaces). with Replaces).
If Alice is the transferee, the triggered INVITE from the REFER is If Alice is the transferee, the triggered INVITE from the REFER is
treated as a consultation call. Alice SHOULD publish requesting that treated as a consultation call. Alice SHOULD publish requesting that
the Appearance Agent not assign an appearance number for this INVITE. the Appearance Agent not assign an appearance number for this INVITE.
When the transfer completes, Alice SHOULD publish again to move the When the transfer completes, Alice SHOULD publish again to move the
appearance number from the dialog with Carol to the dialog with appearance number from the dialog with Carol to the dialog with
David. Note that this publication MUST be sent prior to sending the David. If a PUBLISH is sent to move the appearance number, the
BYE to Carol to avoid a race condition where the Appearance Agent publication MUST be sent prior to sending the BYE to Carol to avoid a
reassigns the appearance number after seeing the BYE. race condition where the Appearance Agent reassigns the appearance
number after seeing the BYE.
If Alice is the target, the incoming INVITE will contain a Replaces If Alice is the target, the incoming INVITE will contain a Replaces
header field. As a result, the Appearance Agent will have reused the header field. As a result, the Appearance Agent will have reused the
appearance number of the dialog with Carol, and this appearance appearance number of the dialog with Carol, and this appearance
number will continue to be used after the dialog with Carol has been number will continue to be used after the dialog with Carol has been
terminated. terminated.
5.4. Appearance Agent 5.4. Appearance Agent
An Appearance Agent defined in this specification MUST implement a An Appearance Agent defined in this specification MUST implement a
dialog package state agent for the UAs registered against the AOR. dialog package state agent for the UAs registered against the AOR.
The Appearance Agent MUST support the appearance dialog package The Appearance Agent MUST support the appearance dialog package
extensions defined in Section 5.2 and use the 'shared' Event header extensions defined in Section 5.2 and use the 'shared' Event header
field parameter. The Appearance Agent MUST support publications and field parameter. The Appearance Agent MUST support publications and
subscriptions for this event package. subscriptions for this event package.
The Appearance Agent MUST have a way of discovering the state of all The Appearance Agent MUST have a way of discovering the state of all
dialogs associated with the AOR. If this information is not dialogs associated with the AOR. If this information is not
available from a call stateful proxy or Back-to-Back User Agent available from a call stateful proxy or Back-to-Back User Agent
(B2BUA), the Appearance Agent MAY use the registration event package (B2BUA), the Appearance Agent can use the registration event package
[RFC3680] to learn of UAs associated with the AOR and MAY subscribe [RFC3680] to learn of UAs associated with the AOR and subscribe to
to their dialog event state. Also, an Appearance Agent MAY subscribe their dialog event state. An Appearance Agent can also subscribe to
to a UAs dialog event state in order to reconstruct state. As a a UAs dialog event state in order to reconstruct state. As a result,
result, the registrar MUST support the registration event package. the registrar MUST support the registration event package. Dialog
Dialog package notifications are recommended by RFC 4235 to "only package notifications are recommended by RFC 4235 to "only contain
contain information on the dialogs whose state or participation information on the dialogs whose state or participation information
information has changed." This specification extends RFC 4235 as has changed." This specification extends RFC 4235 as follows. The
follows. The Appearance Agent SHOULD send dialog event state Appearance Agent SHOULD send dialog event state notifications
notifications whenever the following events happen to UAs in the AOR whenever the following events happen to UAs in the AOR group:
group:
1. A call is received, placed, answered, or terminated. 1. A call is received, placed, answered, or terminated.
2. A call is placed on or off hold. 2. A call is placed on or off hold.
3. A call is joined or replaced. 3. A call is joined or replaced.
4. An appearance number is reserved or released. 4. An appearance number is reserved or released.
The Appearance Agent MUST allocate an appearance number for all The Appearance Agent MUST allocate an appearance number for all
incoming calls and send immediate notifications to the UAs subscribed incoming calls and send immediate notifications to the UAs subscribed
to the shared group AOR. A new appearance number is allocated except to the shared group AOR. A new appearance number is allocated except
for an incoming INVITE with a Join or Replaces header field. For for an incoming INVITE with a Join or Replaces header field. For
skipping to change at page 20, line 30 skipping to change at page 20, line 39
Note that if the appearance group has appearance-unaware UAs Note that if the appearance group has appearance-unaware UAs
making calls, the Appearance Agent will still allocate appearance making calls, the Appearance Agent will still allocate appearance
numbers for INVITEs sent by those UAs. numbers for INVITEs sent by those UAs.
An Appearance Agent receiving a PUBLISH with an appearance number An Appearance Agent receiving a PUBLISH with an appearance number
checks to make sure the publication is valid. An appearance number checks to make sure the publication is valid. An appearance number
can be assigned to only one dialog unless there is a <joined-dialog> can be assigned to only one dialog unless there is a <joined-dialog>
or <replaced-dialog> element indicating that the dialog will be/has or <replaced-dialog> element indicating that the dialog will be/has
been replaced or joined. A 400 (Bad Request) response is returned if been replaced or joined. A 400 (Bad Request) response is returned if
the chosen appearance number is invalid, and an immediate NOTIFY the chosen appearance number is invalid, and an immediate NOTIFY
should be sent to the UA containing full dialog event state. SHOULD be sent to the UA containing full dialog event state.
An Appearance Agent receiving a PUBLISH without an appearance number An Appearance Agent receiving a PUBLISH without an appearance number
but with the 'shared' Event header field parameter present interprets but with the 'shared' Event header field parameter present interprets
this as a request by the UA to not assign an appearance number. If this as a request by the UA to not assign an appearance number. If
the Appearance Agent policy does not allow this, a 400 (Bad Request) the Appearance Agent policy does not allow this, a 400 (Bad Request)
response is returned. If policy does allow this, a 200 OK response response is returned. If policy does allow this, a 200 OK response
is returned and no appearance number is allocated. An Appearance is returned and no appearance number is allocated. An Appearance
Agent does not have to share this dialog information (i.e. send a Agent does not have to share this dialog information (i.e. send a
NOTIFY) with other UAs in the group as the information will not be NOTIFY) with other UAs in the group as the information will not be
rendered by the other UAs. rendered by the other UAs.
skipping to change at page 23, line 11 skipping to change at page 23, line 11
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
7. Alert-Info Appearance Parameter Definition 7. Alert-Info Appearance Parameter Definition
This specification extends RFC 3261 [RFC3261] to add an 'appearance' This specification extends RFC 3261 [RFC3261] to add an 'appearance'
parameter to the Alert-Info header field, and to also allow proxies parameter to the Alert-Info header field, and to also allow proxies
to modify or delete the Alert-Info header field. to modify or delete the Alert-Info header field.
The changes to RFC 3261 ABNF are: The changes to RFC 3261 ABNF [RFC5234] are:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI alert-param = LAQUOT absoluteURI RAQUOT *( SEMI
(generic-param / appearance-param) ) (generic-param / appearance-param) )
appearance-param = "appearance" EQUAL 1*DIGIT appearance-param = "appearance" EQUAL 1*DIGIT
A proxy inserting an 'appearance' Alert-Info parameter follows normal A proxy inserting an 'appearance' Alert-Info parameter follows normal
Alert-Info policies. To indicate the appearance number for this Alert-Info policies. To indicate the appearance number for this
dialog, the proxy adds the Alert-Info header field with the dialog, the proxy adds the Alert-Info header field with the
'appearance' parameter to the INVITE. If an Alert-Info is already 'appearance' parameter to the INVITE. If an Alert-Info is already
present, the proxy adds the 'appearance' parameter to the Alert-Info present, the proxy adds the 'appearance' parameter to the Alert-Info
header field. If an appearance number parameter is already present header field. If an appearance number parameter is already present
(associated with another AOR or by mistake), the value is rewritten (associated with another AOR or by mistake), the value is rewritten
adding the new appearance number. There MUST NOT be more than one adding the new appearance number. There MUST NOT be more than one
appearance parameter in an Alert-Info header field. appearance parameter in an Alert-Info header field.
If no special ringtone is desired, a normal ringtone should be If no special ringtone is desired, a normal ringtone SHOULD be
indicated using the urn:alert:service:normal in the Alert-Info, as indicated using the urn:alert:service:normal in the Alert-Info, as
per [I-D.ietf-salud-alert-info-urns]. The appearance number present per [I-D.ietf-salud-alert-info-urns]. The appearance number present
in an Alert-Info header field SHOULD be rendered by the UA to the in an Alert-Info header field SHOULD be rendered by the UA to the
user, following the guidelines in Section 5.3. If the INVITE is user, following the guidelines in Section 5.3. If the INVITE is
forwarded to another AOR, the appearance parameter in the Alert-Info forwarded to another AOR, the appearance parameter in the Alert-Info
SHOULD be removed before forwarding outside the group. SHOULD be removed before forwarding outside the group.
The determination as to what value to use in the appearance parameter The determination as to what value to use in the appearance parameter
can be done at the proxy that forks the incoming request to all the can be done at the proxy that forks the incoming request to all the
registered UAs. registered UAs.
skipping to change at page 24, line 35 skipping to change at page 24, line 35
Perfect interoperability across all UAs is clearly not possible, but Perfect interoperability across all UAs is clearly not possible, but
by careful design, interoperability up to the limits of each UA can by careful design, interoperability up to the limits of each UA can
be achieved. be achieved.
The following guidelines suggest how the appearance number should be The following guidelines suggest how the appearance number should be
handled in three typical user interface implementations. handled in three typical user interface implementations.
8.1.1. Single Appearance UAs 8.1.1. Single Appearance UAs
These devices are constrained by only having the capability of These devices are constrained by only having the capability of
displaying status indications for a single appearance. The UA should displaying status indications for a single appearance. The UA SHOULD
still send messages annotated with appearance number "1". Any call still send messages annotated with appearance number "1". Any call
indications for appearances other than for number "1" should be indications for appearances other than for number "1" SHOULD be
rejected with a 486 or 480 response. Note that this means that a rejected with a 486 or 480 response. Note that this means that a
single appearance UA cannot answer its own call to the shared AOR, single appearance UA cannot answer its own call to the shared AOR,
since this call would use a second appearance number. since this call would use a second appearance number.
8.1.2. Dual Appearance UAs 8.1.2. Dual Appearance UAs
These devices are essentially single appearance phones that implement These devices are essentially single appearance phones that implement
call waiting. They have a very simple user interface that allows call waiting. They have a very simple user interface that allows
them to switch between two appearances (toggle or flash hook) and them to switch between two appearances (toggle or flash hook) and
perhaps audible tones to indicate the status of the other appearance. perhaps audible tones to indicate the status of the other appearance.
skipping to change at page 46, line 5 skipping to change at page 46, line 5
11.7. Appearance Pickup 11.7. Appearance Pickup
In this scenario, Bob has an established dialog with Carol created In this scenario, Bob has an established dialog with Carol created
using the call flows of Figure 1 or Figure 2. Bob then places Carol using the call flows of Figure 1 or Figure 2. Bob then places Carol
on hold. Alice receives a notification of this and renders this on on hold. Alice receives a notification of this and renders this on
Alice's UI. Alice subsequently picks up the held call and has a Alice's UI. Alice subsequently picks up the held call and has a
established session with Carol. Finally, Carol hangs up. Alice must established session with Carol. Finally, Carol hangs up. Alice must
PUBLISH F32 to indicate that the INVITE F38 will be an attempt to PUBLISH F32 to indicate that the INVITE F38 will be an attempt to
pickup the dialog between Carol and Bob, and hence may use the same pickup the dialog between Carol and Bob, and hence may use the same
appearance number. appearance number. This example also shows Secure SIP (sips) being
used.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| |<------------------------------(hold) INVITE F22<| | |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | | |<- INVITE F23<| | | |
| | | | | | | | | |
|>F24 200 OK ->| | | | |>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>| | |>F25 200 OK ------------------------------------>|
skipping to change at page 47, line 32 skipping to change at page 47, line 33
| | |>F53 200 OK ->| | | | |>F53 200 OK ->| |
| | | | | | | | | |
| | | |>F54 NOTIFY ----->| | | | |>F54 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F55<| | | | |<----- 200 OK F55<|
Figure 7. Figure 7.
F28 Appearance ----> Alice F28 Appearance ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sips:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937 From: <sips:HelpDesk@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sips:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4 Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 12 NOTIFY CSeq: 12 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com Via: SIP/2.0/TLS appearanceagent.example.com
;branch=z9hG4bK1403 ;branch=z9hG4bK1403
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active;expires=1800 Subscription-State: active;expires=1800
Contact: <sip:appearanceagent.example.com> Contact: <sips:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator"> direction="initiator">
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>active</state> <state>active</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sips:bob@ua2.example.com">
<param pname="+sip.rendering" pval="no"/> <param pname="+sip.rendering" pval="no"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:carol@example.com</identity> <identity>sips:carol@example.com</identity>
<target uri="sip:carol@ua3.example.com" /> <target uri="sips:carol@ua3.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F32 Alice ----> Appearance Agent F32 Alice ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 PUBLISH sips:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:HelpDesk@example.com>;tag=44150CC6-A7B7919D From: <sips:HelpDesk@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=428765950880801 To: <sips:alice@example.com>;tag=428765950880801
CSeq: 11 PUBLISH CSeq: 11 PUBLISH
Call-ID: 87837Fkw87asfds Call-ID: 87837Fkw87asfds
Contact: <sip:alice@ua2.example.com> Contact: <sips:alice@ua2.example.com>
Event: dialog;shared Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="full" state="full"
entity="sip:HelpDesk@example.com"> entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6" call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" > local-tag="8C4183CB-BCEAB710" >
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog <sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
from-tag="15A3DE7C-9283203B" from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" /> to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sips:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<target uri="sip:carol@ua3.example.com" /> <target uri="sips:carol@ua3.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F38 Alice ----> Proxy F38 Alice ----> Proxy
INVITE sip:carol@example.com SIP/2.0 INVITE sips:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sip:HelpDesk@example.com>;tag=8C4183CB-BCEAB710 From: <sips:HelpDesk@example.com>;tag=8C4183CB-BCEAB710
To: <sip:carol@example.com:5075> To: <sips:carol@example.com:5075>
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6 Call-ID: 3d57cd17-47deb849-dca8b6c6
Contact: <sip:alice@ua1.example.com> Contact: <sips:alice@ua1.example.com>
<all-one-line> <all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line> </all-one-line>
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 223 Content-Length: 223
v=0 v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com o=- 1102980497 1102980497 IN IP4 ua1.example.com
skipping to change at page 66, line 25 skipping to change at page 66, line 25
be encrypted end-to-end using the standard mechanisms such as S/MIME be encrypted end-to-end using the standard mechanisms such as S/MIME
described in [RFC3261]. Alternatively, sending the NOTIFY and described in [RFC3261]. Alternatively, sending the NOTIFY and
PUBLISH requests over TLS also provides confidentiality, although on PUBLISH requests over TLS also provides confidentiality, although on
a hop-by-hop basis. All SUBSCRIBES and PUBLISHES between the UAs and a hop-by-hop basis. All SUBSCRIBES and PUBLISHES between the UAs and
the Appearance Agent MUST be authenticated. Without proper the Appearance Agent MUST be authenticated. Without proper
authentication and confidentiality, a third party could learn authentication and confidentiality, a third party could learn
information about dialogs associated with a AOR and could try to use information about dialogs associated with a AOR and could try to use
this information to hijack or manipulate those dialogs using SIP call this information to hijack or manipulate those dialogs using SIP call
control primitives. control primitives.
All INVITEs with Replaces or Join header fields MUST only be accepted This feature relies on standard SIP call control primitives such as
if the peer requesting dialog replacement or joining has been Replaces and Join. Proper access controls on their use MUST be used
properly authenticated using a standard SIP mechanism (such as Digest so that only members of the appearance group can use these
or S/MIME), and authorized to request a replacement. Otherwise, a mechanisms. All INVITEs with Replaces or Join header fields MUST
third party could disrupt or hijack existing dialogs in the only be accepted if the peer requesting dialog replacement or joining
appearance group. has been properly authenticated using a standard SIP mechanism (such
as Digest or S/MIME), and authorized to request a replacement.
Otherwise, a third party could disrupt or hijack existing dialogs in
the appearance group.
For an emergency call, a UA MUST NOT wait for a confirmed seizure of For an emergency call, a UA MUST NOT wait for a confirmed seizure of
an appearance before sending an INVITE. Waiting for confirmation an appearance before sending an INVITE. Waiting for confirmation
could inadvertently delay or block the emergency call, which by its could inadvertently delay or block the emergency call, which by its
nature needs to be placed as expeditiously as possible. Instead, a nature needs to be placed as expeditiously as possible. Instead, a
emergency call MUST proceed regardless of the status of the PUBLISH emergency call MUST proceed regardless of the status of the PUBLISH
transaction. transaction.
13. IANA Considerations 13. IANA Considerations
This section registers the SIP Event header field parameter 'shared', This section registers the SIP Event header field parameter 'shared',
the SIP Alert-Info header field parameter 'appearance' and the XML the SIP Alert-Info header field parameter 'appearance' and the XML
namespace extensions to the SIP Dialog Package. namespace extensions to the SIP Dialog Package.
13.1. SIP Event Header Field Parameter: shared 13.1. SIP Event Header Field Parameter: shared
This document defines the 'shared' header field parameter to the This document defines the 'shared' header field parameter to the
Event header field in the "SIP Header Field Parameters and Parameter Event header field in the "SIP Header Field Parameters and Parameter
Values" registry defined by [RFC3968] Values" registry defined by [RFC3968].
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------------- ------------------ ---------- --------- ---------------------------- ------------------ ---------- ---------
Event shared No [RFC-to-be] Event shared No [RFC-to-be]
13.2. SIP Alert-Info Header Field Parameter: appearance 13.2. SIP Alert-Info Header Field Parameter: appearance
This document defines the 'appearance' parameter to the Alert-Info This document defines the 'appearance' parameter to the Alert-Info
header in the SIP Parameters registry. header in the "SIP Header Field Parameters and Parameter Values"
registry defined by [RFC3968].
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------- --------------- --------- --------- ---------------------- --------------- --------- ---------
Alert-Info appearance No [RFC-to-be] Alert-Info appearance No [RFC-to-be]
13.3. URN Sub-Namespace Registration: sa-dialog-info 13.3. URN Sub-Namespace Registration: sa-dialog-info
This section registers a new XML namespace per the procedures This section registers a new XML namespace per the procedures
in [RFC3688]. in [RFC3688].
URI: urn:ietf:params:xml:ns:sa-dialog-info. URI: urn:ietf:params:xml:ns:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com> Alan Johnston <alan.b.johnston@gmail.com>
skipping to change at page 69, line 14 skipping to change at page 69, line 46
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[I-D.ietf-sipcore-rfc3265bis] [I-D.ietf-sipcore-rfc3265bis]
Roach, A., "SIP-Specific Event Notification", Roach, A., "SIP-Specific Event Notification",
draft-ietf-sipcore-rfc3265bis-09 (work in progress), draft-ietf-sipcore-rfc3265bis-09 (work in progress),
April 2012. April 2012.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
skipping to change at page 69, line 46 skipping to change at page 70, line 34
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[I-D.ietf-salud-alert-info-urns] [I-D.ietf-salud-alert-info-urns]
Liess, L., Jesske, R., Johnston, A., Worley, D., and P. Liess, L., Jesske, R., Johnston, A., Worley, D., and P.
Kyzivat, "Alert-Info URNs for the Session Initiation Kyzivat, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-ietf-salud-alert-info-urns-06 (work Protocol (SIP)", draft-ietf-salud-alert-info-urns-07 (work
in progress), April 2012. in progress), October 2012.
15.2. Informative References 15.2. Informative References
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008. Examples", BCP 144, RFC 5359, October 2008.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", (SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004. Package for Registrations", RFC 3680, March 2004.
[I-D.worley-service-example] [I-D.worley-service-example]
Worley, D., "Session Initiation Protocol Service Example Worley, D., "Session Initiation Protocol Service Example
-- Music on Hold", draft-worley-service-example-09 (work -- Music on Hold", draft-worley-service-example-10 (work
in progress), February 2012. in progress), August 2012.
Authors' Addresses Authors' Addresses
Alan Johnston (editor) Alan Johnston (editor)
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Mohsen Soroushnejad Mohsen Soroushnejad
 End of changes. 49 change blocks. 
108 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/