draft-ietf-bliss-shared-appearances-06.txt   draft-ietf-bliss-shared-appearances-07.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Intended status: Standards Track M. Soroushnejad Updates: 3261, 4235 M. Soroushnejad
Expires: January 13, 2011 V. Venkataramanan (if approved) V. Venkataramanan
Sylantro Systems Corp Intended status: Standards Track Sylantro Systems Corp
July 12, 2010 Expires: September 15, 2011 March 14, 2011
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-06 draft-ietf-bliss-shared-appearances-07
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 45 skipping to change at page 1, line 45
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 13, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . 12
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13 5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 13 5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 13
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 16 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 18 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 16
7. User Interface Considerations . . . . . . . . . . . . . . . . 20 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 17
7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 20 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 17
7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 20 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 19
7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 20 7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 21
7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 20 8. User Interface Considerations . . . . . . . . . . . . . . . . 22
7.1.4. Shared Appearance UAs with Variable Appearance 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 22
Number . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 22
7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 21 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 22
8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 22 8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 23
8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 22 8.1.4. Shared Appearance UAs with Variable Appearance
8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 22 Number . . . . . . . . . . . . . . . . . . . . . . . . 23
8.3. UAs Supporting Dialog Events but Not Shared Appearance . 23 8.1.5. Example User Interface Issues . . . . . . . . . . . . 23
9. Provisioning Considerations . . . . . . . . . . . . . . . . . 23 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 24
10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 23 9. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 24
10.1. Registration and Subscription . . . . . . . . . . . . . . 24 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 24
10.2. Appearance Selection for Incoming Call . . . . . . . . . 27 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 24
10.3. Outgoing Call without Appearance Seizure . . . . . . . . 31 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 25
10.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 34 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 25
10.5. Outgoing Call without using an Appearance Number . . . . 38 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 26
10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 40 11.1. Registration and Subscription . . . . . . . . . . . . . . 26
10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 41 11.2. Appearance Selection for Incoming Call . . . . . . . . . 30
10.8. Calls between UAs within the Group . . . . . . . . . . . 45 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 33
10.9. Consultation Hold with Appearances . . . . . . . . . . . 48 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 36
10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 50 11.5. Outgoing Call without using an Appearance Number . . . . 40
10.11. Appearance Allocation - Loss of Appearance . . . . . . . 53 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 42
10.12. Appearance Seizure Contention Race Condition . . . . . . 54 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 43
10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 55 11.8. Calls between UAs within the Group . . . . . . . . . . . 47
10.14. Appearance Pickup Race Condition Failure . . . . . . . . 57 11.9. Consultation Hold with Appearances . . . . . . . . . . . 50
10.15. Appearance Seizure Incoming/Outgoing Contention Race 11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 53
Condition . . . . . . . . . . . . . . . . . . . . . . . . 60 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 55
11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 61 11.12. Appearance Seizure Contention Race Condition . . . . . . 56
12. Security Considerations . . . . . . . . . . . . . . . . . . . 62 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 57
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 59
13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 62 11.15. Appearance Seizure Incoming/Outgoing Contention Race
13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 63 Condition . . . . . . . . . . . . . . . . . . . . . . . . 62
13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 63 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 63
15.1. Normative References . . . . . . . . . . . . . . . . . . 64 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 64
15.2. Informative References . . . . . . . . . . . . . . . . . 65 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
15.1. Normative References . . . . . . . . . . . . . . . . . . 65
15.2. Informative References . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
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 9, line 19 skipping to change at page 9, line 19
REQ-16 The mechanism should support a way for a UA to seize a REQ-16 The mechanism should support a way for a UA to seize a
particular appearance number and also send the request at the same particular appearance number and also send the request at the same
time. This is needed when an automatic ringdown feature (a telephone time. This is needed when an automatic ringdown feature (a telephone
configured to immediately dial a phone number when it goes off hook) configured to immediately dial a phone number when it goes off hook)
is combined with shared appearances - in this case, seizing the line is combined with shared appearances - in this case, seizing the line
is the same thing as dialing. is the same thing as dialing.
4.2. Implementation 4.2. Implementation
Many of the requirements for this service can be met using standard This section non-normatively discusses the implementation of the
SIP mechanisms such as: shared appearance feature. The normative description is in
Section 5. Many of the requirements for this service can be met
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 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.
skipping to change at page 10, line 15 skipping to change at page 10, line 17
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 for the Alert-Info
header field in RFC 3261 to carry the appearance number: 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 next section discusses the operations used to implement parts of The next section discusses the operations used to implement parts of
the shared appearance feature. An analysis of other mechanisms has the shared appearance feature.
been performed, with the mechanism described here best meeting the
requirements of Section 4.1.
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,
and hence no Appearance Agent and this feature is not and hence no Appearance Agent and this feature is not
implemented. implemented.
2. If the subscription receives a 200 OK, the UA knows there is a 2. If the subscription receives a 200 OK, the UA knows there is a
State Agent and that the feature is implemented. The UA then State Agent and that the feature is implemented. The UA then
follows the steps in this list. follows the steps in this list.
3. Information learned about the dialog state of other UAs in the 3. Information learned about the dialog state of other UAs in the
group is rendered to the user. group is rendered to the user.
4. Incoming calls are forked to all UAs in the group, and any may 4. Incoming calls are forked to all UAs in the group, and any may
answer. UAs receive the appearance number to use in rendering answer. UAs receive the appearance number to use in rendering
the incoming call in a NOTIFY from the Appearance Agent and in the incoming call in a NOTIFY from the Appearance Agent and in
the INVITE itself. The UA will also receive a notification if the INVITE itself. The UA will also receive a notification if
the call is answered by another UA in the group so this the call is answered by another UA in the group so this
information can be rendered to the user. information can be rendered to the user.
5. For outgoing calls, the operation depends on the implementation. 5. For outgoing calls, the operation depends on the implementation.
If the user seizes a particular appearance number for the call, If the user seizes a particular appearance number for the call,
the UA publishes this information and waits for a 200 OK before the UA publishes the 100 Trying state dialog information without
sending the INVITE. an appearance number and waits for a 200 OK before sending the
INVITE.
6. For outgoing calls, if the user does not seize a particular 6. For outgoing calls, if the user does not seize a particular
appearance or does not care, the INVITE can be sent immediately, appearance or does not care, the INVITE can be sent immediately,
and the appearance number learned as the call progresses from a and the appearance number learned as the call progresses from a
notification from the Appearance Agent. notification from the Appearance Agent.
7. For outgoing calls, if the user does not wish to seize an 7. For outgoing calls, if the user does not wish to seize an
appearance (such as during a consultation call or if a UA is appearance (such as during a consultation call or if a UA is
fetching 'service media' such as music on hold fetching 'service media' such as music on hold
[I-D.worley-service-example]), the UA also publishes this prior [I-D.worley-service-example]), the UA also publishes this prior
to sending the INVITE. to sending the INVITE.
8. Established calls within the group may be joined (bridged) or 8. Established calls within the group may be joined (bridged) or
taken (picked) by another UA. Information in the dialog package taken (picked) by another UA. Information in the dialog package
notifications can be used to construct Join or Replaces header notifications can be used to construct Join or Replaces header
fields. Since the same appearance number is used for these types fields. Since the same appearance number is used for these types
of operations, this information is published prior to sending the of operations, this information is published prior to sending the
INVITE Join or INVITE Replaces. INVITE Join or INVITE Replaces.
9. In some cases, the Appearance Agent may not have full access to 9. The Appearance Agent may not have full access to the complete
the complete dialog state of some or all of the UAs in the group. dialog state of some or all of the UAs in the group. If this is
If this is the case, the Appearance Agent will subscribe to the the case, the Appearance Agent will subscribe to the dialog state
dialog state of individual UAs in the group to obtain this of individual UAs in the group to obtain this information.
information. Normal notifications will be sent every time the Normal notifications will be sent every time the dialog state
dialog state changes, including calls placed, answered, placed on changes, including calls placed, answered, placed on and off
and off hold, and hangups. hold, and hangups.
5. Normative Description 5. Normative Description
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:
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
skipping to change at page 12, line 22 skipping to change at page 12, line 22
<joined-dialog>, and <replaced-dialog> which are sub-elements of the <joined-dialog>, and <replaced-dialog> which are sub-elements of the
<dialog> element. <dialog> element.
5.2.1. The <appearance> element 5.2.1. The <appearance> element
The <appearance> element is used to convey the appearance number. The <appearance> element is used to convey the appearance number.
The appearance number is a positive integer. When sent in a The appearance number is a positive integer. When sent in a
publication in state Trying to the Appearance Agent, it is used to publication in state Trying to the Appearance Agent, it is used to
request an appearance number. When sent by the Appearance Agent, it request an appearance number. When sent by the Appearance Agent, it
indicates that the appearance number is associated with a dialog. indicates that the appearance number is associated with a dialog.
The UA generating the to-tag and from-tag parameters treats them from
a local perspective. In other words, if the UA sent out a request
within the dialog, the to-tag parameter would match the remote tag,
and the from-tag parameter would match the local tag.
5.2.2. The <exclusive> element 5.2.2. The <exclusive> element
The <exclusive> element is a boolean used to indicate whether the UA The <exclusive> element is a boolean used to indicate whether the UA
will accept Join or Replaces INVITEs for this dialog. For example, will accept Join or Replaces INVITEs for this dialog. For example,
some shared appearance systems only allow call pickup when the call some shared appearance systems only allow call pickup when the call
is on hold. In this case, the <exclusive> element should be used to is on hold. In this case, the <exclusive> element should be used to
explicitly indicate this, rather than implicitly by the hold state. explicitly indicate this, rather than implicitly by the hold state.
It is important to note that this element is a hint. Although a UA It is important to note that this element is a hint. In order to
may set exclusive to true, the UA must still be ready to reject an prevent another UA from taking or joining a call, a UA can, in
INVITE Join relating to this dialog. Also, an INVITE Replaces might addition to setting the <exclusive> tag, not report full dialog
be sent to the non-shared appearance UA to take the call. For this information to the Appearance Agent. Not having the full dialog
reason, a UA MAY also not report full dialog identifier information information (Call-ID, remote-tag, and local-tag) prevents another UA
to the Appearance Agent for calls set to exclusive. If these dialog from constructing a Join or Replaces header field. Although a UA may
identifiers have already been shared with the Appearance Agent, the set exclusive to true, the UA must still be ready to reject an INVITE
UA could send an INVITE Replaces to change them and then not report Join relating to this dialog. If these dialog identifiers have
the new ones to the Appearance Agent. already been shared with the Appearance Agent, the UA could send an
INVITE Replaces to change them and then not report the new ones to
the Appearance Agent.
If the proxy knows which dialogs are marked exclusive, the proxy MAY If the proxy knows which dialogs are marked exclusive, the proxy MAY
enforce this exclusivity by rejecting INVITE Join and INVITE Replaces enforce this exclusivity by rejecting INVITE Join and INVITE Replaces
requests containing those dialog identifiers with a 403 Forbidden requests containing those dialog identifiers with a 403 Forbidden
response. response.
Note that exclusivity has nothing to do with appearance number Note that exclusivity has nothing to do with appearance number
selection or seizing - instead, it is about call control selection or seizing - instead, it is about call control
operations that can be performed on a dialog. operations that can be performed on a dialog.
skipping to change at page 13, line 30 skipping to change at page 13, line 34
dialog. For example, a UA in the group picking up a call on another dialog. For example, a UA in the group picking up a call on another
UA by sending an INVITE with Replaces would include this element for UA by sending an INVITE with Replaces would include this element for
the replacing dialog. Replaced dialogs will share the same the replacing dialog. Replaced dialogs will share the same
appearance number. appearance number.
5.3. Shared Appearance User Agents 5.3. Shared Appearance User Agents
User Agents that support the Shared Appearance feature MUST support User Agents that support the Shared Appearance feature MUST support
the dialog state package [RFC4235] with the shared appearance the dialog state package [RFC4235] with the shared appearance
extensions and the 'shared' dialog event package parameter defined in extensions and the 'shared' dialog event package parameter defined in
Section 11. Section 13.
User Agents MUST support the dialog package extensions in Section 5.2 User Agents MUST support the dialog package extensions in Section 5.2
along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and
PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the
dialog event package SHOULD include the 'shared' Event header field dialog event package MUST include the 'shared' Event header field
parameter. parameter.
The presence of the 'shared' Event package parameter tells the The presence of the 'shared' Event package parameter tells the
Appearance Agent that this UA supports this specification. Appearance Agent that this UA supports this specification.
Upon initialization, the UA SHOULD 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, loops back to itself, Framework. If the SUBSCRIBE request fails, then no Appearance Agent
then no Appearance Agent is present and this feature is not active may be present and this feature is not active for this AOR. The UA
for this AOR. The UA MAY periodically retry the subscription to see MAY periodically retry the subscription to see if conditions have
if conditions have changed. changed at intervals no shorter than 4 hours.
User Agents which implement call pickup, joining and bridging MUST User Agents which implement call pickup, joining and bridging MUST
support sending an INVITE with Replaces [RFC3891] or Join [RFC3911]. support sending an INVITE with Replaces [RFC3891] or Join [RFC3911].
All User Agents supporting INVITE MUST support receiving an INVITE The User Agent Client needs to include the to-tag and from-tag
with a Replaces [RFC3891] or a Join [RFC3911] header field. information in the Replaces or Join header so that the correct dialog
will be matched by the User Agent Server per the rules in RFC 3891
and RFC 3911. All User Agents supporting INVITE MUST support
receiving an INVITE with a Replaces [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 calls are placed on hold, the
"+sip.rendering=no" feature tag MUST be included in dialog package "+sip.rendering=no" feature tag MUST be included in dialog package
notifications. notifications.
skipping to change at page 15, line 6 skipping to change at page 15, line 14
the initial PUBLISH, the UA MUST PUBLISH again after receiving the the initial PUBLISH, the UA MUST PUBLISH again after receiving the
100 Trying response. 100 Trying response.
The first publication will cause the Appearance Agent to reserve The first publication will cause the Appearance Agent to reserve
the appearance number for this UA. If the publication does not the appearance number for this UA. If the publication does not
have any dialog identifiers (e.g. Call-ID, or local tag) the have any dialog identifiers (e.g. Call-ID, or local tag) the
Appearance Agent cannot assign the appearance number to a Appearance Agent cannot assign the appearance number to a
particular dialog of the UA until the second publication which particular dialog of the UA until the second publication which
will contain some dialog identifiers. will contain some dialog identifiers.
This publication state SHOULD be refreshed during the early dialog This publication state is refreshed as described in [RFC3903] during
state or the Appearance Agent may reassign the appearance number. the early dialog state or the Appearance Agent may reassign the
Once the dialog has transitioned to the confirmed state, no appearance number. Once the dialog has transitioned to the confirmed
publication refreshes are necessary. state, no publication refreshes are necessary.
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. The
appearances number for each active and pending dialog SHOULD be appearances number for each active and pending dialog SHOULD be
explicitly or implicitly rendered to the user. The far end identity explicitly (i.e. by appearance number) or implicitly (using a user
of each dialog (e.g. the remote party identity) MUST NOT be rendered interface metaphor that makes the numbering and ordering clear to the
in place of the appearance number. The state of each appearance user) rendered to the user. The far end identity of each dialog
SHOULD also be rendered (idle, active, busy, joined, etc.). UAs can (e.g. the remote party identity) MUST NOT be rendered in place of the
tell that a set of dialogs are joined (bridged or mixed) together by appearance number. The state of each appearance SHOULD also be
the presence of one or more <joined-dialog> elements containing other rendered (idle, active, busy, joined, etc.). UAs can tell that a set
SIP dialog identifiers. Appearance numbers of dialogs can be learned of dialogs are joined (bridged or mixed) together by the presence of
by dialog package notifications containing the <appearance> element one or more <joined-dialog> elements containing other SIP dialog
from the Appearance Agent or from the 'appearance' Alert-Info identifiers. Appearance numbers of dialogs can be learned by dialog
parameter in an incoming INVITE. Should they conflict, the dialog package notifications containing the <appearance> element from the
package notification takes precedence. Appearance Agent or from the 'appearance' Alert-Info parameter in an
incoming INVITE. Should 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 SHOULD free up the call (go back on hook). In this case, the UA SHOULD free up the
appearance number by removing the event state with a PUBLISH as appearance number by removing the event state with a PUBLISH as
described in [RFC3903]. described in [RFC3903].
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
monitoring the status of the shared appearance group calls and
picking or joining calls, the UA SHOULD only subscribe to the AOR and
not register against the AOR.
All subscribed UAs will receive dialog package NOTIFYs of Trying
state for incoming INVITEs.
5.3.1. Appearance Numbers and Call Context
There are cases where two separate dialogs at a UA (non-mixed) share
the same 'context'. That is, they relate to each other and should
not be treated the same as any other two dialogs within the group.
One example of this is a 'consultation call' where a user puts an
existing dialog on hold, then calls another user, before switching
back to the original dialog. Another case, described below, occurs
during transfer operations, where for a transient period, a UA is
invovled in dialogs with two other UAs, but the dialogs are related,
and should not be treated as independent dialogs. These cases are
best handled by having these dialogs that share a context with an
existing dialog not have an an appearance number assigned to them.
A UA wanting to place a call but not have an appearance number A UA wanting to place a call but not have an appearance number
assigned publishes before sending the INVITE without an 'appearance' assigned publishes before sending the INVITE without an 'appearance'
element but with the 'shared' event package parameter present. If element but with the 'shared' event package parameter present. If
the Appearance Agent policy does not allow calls without an assigned the Appearance Agent policy does not allow calls without an assigned
appearance number, a 409 Conflict response will be received, and the appearance number, a 400 response with the reason phrase "Appearance
UA will republish either selecting/seizing an appearance number or Number Conflict" will be received, and the UA will republish either
send the INVITE without publishing, in which case the Appearance selecting/seizing an appearance number or send the INVITE without
Agent will assign one. publishing, in which case the Appearance Agent will assign one.
Note that if an Appearance Agent rejects calls without an Note that if an Appearance Agent rejects calls without an
appearance number, certain operations such as consultation calls appearance number, certain operations such as consultation calls,
and music on hold may be impacted. transfer, and music on hold may be impacted.
5.3.2. Appearance Numbers and Call Control
When an INVITE is generated to attempt to bridge or take a call (i.e. When an INVITE is generated to attempt to bridge or take a call (i.e.
contains Join or Replaces with a dialog identifier of another dialog contains Join or Replaces with a dialog identifier of another dialog
in the shared appearance group), the appearance number of the joined in the shared appearance group), the appearance number of the joined
or replaced call SHOULD be published. The publication MUST contain or replaced call SHOULD be published. The publication MUST contain
the appearance number of the dialog to be joined or replaced and the the appearance number of the dialog to be joined or replaced and the
dialog identifier in the 'joined-dialog' or 'replaced-dialog' dialog identifier in the 'joined-dialog' or 'replaced-dialog'
elements. elements.
Note that this information is provided to the Appearance Agent so Note that this information is provided to the Appearance Agent so
that it can provide proper appearance assignment behavior. If the that it can provide proper appearance assignment behavior. If the
INVITE Join or Replaces was sent without publishing first, the INVITE Join or Replaces was sent without publishing first, the
Appearance Agent might assign a new appearance number to this Appearance Agent might assign a new appearance number to this
INVITE, which would be a mistake. With Join, the publication has INVITE, which would be a mistake. With Join, the publication has
the 'joined-dialog' element to prevent the Appearance Agent from the 'joined-dialog' element to prevent the Appearance Agent from
generating a 409 Conflict response due to the reuse of an generating a 400 Appearance Number Conflict response due to the
appearance number. For Replaces, the purpose of the 'replaced- reuse of an appearance number. For Replaces, the purpose of the
dialog' is to prevent a race condition where the BYE could cause 'replaced-dialog' is to prevent a race condition where the BYE
the appearance number to be released when it should stay with the could cause the appearance number to be released when it should
replacing dialog. stay with the replacing dialog.
A UA SHOULD register against the AOR only if it is likely the UA will 5.3.3. Appearance Numbers and Transfer
be answering incoming calls. If the UA is mainly going to be
monitoring the status of the shared appearance group calls and
picking or joining calls, the UA SHOULD only subscribe to the AOR and
not register against the AOR.
All subscribed UAs will received NOTIFYs of Trying state for During a transfer operation, it is important that the appearance
incoming INVITEs. number not change during the operation. Consider the example of
Alice, a member of an appearance group, who is talking to Carol, who
is outside the appearance group. Carol transfers Alice to David, who
is also outside the appearance group. For example, if Alice is using
appearance 3 for the session with Carol, the resulting session with
David should also use appearance number 3. Otherwise, an appearance
number change can cause a "jump" on the UI and confusion to the user.
There are two possible scenarios using the terminology of RFC 5589:
Alice is the transferee in any type of transfer (receives the REFER)
or the transfer target in an attended transfer (receives the INVITE
with Replaces).
If Alice is the transferee, the triggered INVITE from the REFER
should be treated as a consultation call, and should not use a new
appearance number. When the transfer completes, the appearance
number associated with the dialog with Carol is moved to the dialog
associated with David.
If Alice is the target, the incoming INVITE should not have a new
appearance number assigned. Instead, it should reuse the appearance
number associated with the dialog being replaced. If the Appearance
Agent does assign a different appearance number, when the transfer
completes, Alice should release that appearance number and use the
original appearance number associated with the dialog with Carol.
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. The Appearance Agent MUST support extensions defined in Section 5.2. The Appearance Agent MUST support
publications and subscriptions for this event package. publications and 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 B2BUA, the Appearance Agent available from a call stateful proxy or B2BUA, the Appearance Agent
MAY use the registration event package [RFC3680] to learn of UAs MAY use the registration event package [RFC3680] to learn of UAs
associated with the AOR and MAY subscribe to their dialog event associated with the AOR and MAY subscribe to their dialog event
state. Also, an Appearance Agent MAY subscribe to a UAs dialog event state. Also, an Appearance Agent MAY subscribe to a UAs dialog event
state in order to reconstruct state. As a result, the registrar MUST state in order to reconstruct state. As a result, the registrar MUST
support the registration event package. The Appearance Agent SHOULD support the registration event package. Dialog package notifications
send dialog event state notifications whenever the following events are recommended by RFC 4235 to "only contain information on the
happen to UAs in the AOR group: dialogs whose state or participation information has changed." This
specification extends RFC 4235 as follows. The Appearance Agent
SHOULD send dialog event state notifications whenever the following
events happen to UAs in the AOR 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. The Appearance Agent MUST be able to to the shared group AOR. A new appearance number is allocated except
communicate with the forking proxy to learn about incoming calls and for an incoming INVITE with a Join or Replaces header field. For
also to pass the appearance number to the proxy to insert in the this case, the appearance number should match the appearance number
Alert-Info header field. of the dialog being joined or replaced. The Appearance Agent MUST be
able to communicate with the forking proxy to learn about incoming
calls and also to pass the appearance number to the proxy to insert
in the Alert-Info header field.
Note that UAs need to be able to handle incoming INVITEs without Note that UAs need to be able to handle incoming INVITEs without
an appearance number assigned. This could be caused by a failure an appearance number assigned. This could be caused by a failure
of the Appearance Agent or other error condition. Although the of the Appearance Agent or other error condition. Although the
proper rendering of the INVITE may not be possible, this is better proper rendering of the INVITE may not be possible, this is better
than ignoring or failing the INVITE. than ignoring or failing the INVITE.
An Appearance Agent SHOULD assign an appearance number to an outgoing An Appearance Agent SHOULD assign an appearance number to an outgoing
dialog if a PUBLISH has not been received selecting/seizing a dialog if a PUBLISH has not been received selecting/seizing a
particular appearance number. particular appearance number.
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 409 Conflict response is returned if the been replaced or joined. A 400 response with the reason phrase
chosen appearance number is invalid, and an immediate NOTIFY should "Appearance Number Conflict" is returned if the chosen appearance
be sent to the UA containing full dialog event state. number is invalid, and an immediate NOTIFY 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 package parameter present interprets this but with the 'shared' event package parameter present interprets this
as a request by the UA to not assign an appearance number. If the as a request by the UA to not assign an appearance number. If the
Appearance Agent policy does not allow this, a 409 Conflict response Appearance Agent policy does not allow this, a 400 Appearance Number
is returned. If policy does allow this, a 200 OK response is Conflict response is returned. If policy does allow this, a 200 OK
returned and no appearance number is allocated. An Appearance Agent response is returned and no appearance number is allocated. An
does not have to share this dialog information with other UAs in the Appearance Agent does not have to share this dialog information (i.e.
group as the information will not be rendered by the other UAs. send a NOTIFY) with other UAs in the group as the information will
not be rendered by the other UAs.
The Appearance Agent allocates an appearance number to a dialog from The Appearance Agent allocates an apperance number to a dialog from
the time the appearance is requested via a PUBLISH or from the the time the appearance is requested via a PUBLISH or from the
receipt of an INVITE, to the time when the last dialog associated receipt of an INVITE, to the time when the last dialog associated
with the appearance is terminated, including all dialogs which are with the appearance is terminated, including all dialogs which are
joined or replaced. During the early dialog state, the Appearance joined or replaced. During the early dialog state, the Appearance
Agent controls the rate of dialog state publication using the Expires Agent controls the rate of dialog state publication using the Expires
header field in 200 OK responses to PUBLISH requests. An interval of header field in 200 OK responses to PUBLISH requests. An interval of
3 minutes is RECOMMENDED. After the dialog associated with the 3 minutes is RECOMMENDED. After the dialog associated with the
publication has been confirmed, the expiration of the publication publication has been confirmed, the expiration of the publication
state has no effect on the appearance allocation. If the publication state has no effect on the appearance allocation. If the publication
contains no dialog state information, the Appearance Agent MUST contains no dialog state information, the Appearance Agent MUST
reserve the appearance number for the UA but can not assign the reserve the appearance number for the UA but can not assign the
appearance to any particular dialog of the UA. When the publication appearance to any particular dialog of the UA. When the publication
state is updated with any dialog information, the appearance number state is updated with any dialog information, the appearance number
can then be assigned to the particular dialog. A UA which has been can then be assigned to the particular dialog. A UA which has been
allocated an appearance number using a PUBLISH MAY free up the allocated an appearance number using a PUBLISH MAY free up the
appearance number by removing the event state with a PUBLISH as appearance number by removing the event state with a PUBLISH as
described in [RFC3903]. described in [RFC3903].
During dynamic situations, such as during a call pickup or join
action, the Appearance Agent MAY choose to implement rate limiting to
reduce the amount of notification traffic. For example, an
Appearance Agent may choose not to generate immediate NOTIFYs upon
receipt of PUBLISHes. Instead, a single NOTIFY can convey the
effects of a number of PUBLISHes, thus reducing the NOTIFY traffic
within the group.
If an INVITE is sent by a member of the group using the shared AOR or If an INVITE is sent by a member of the group using the shared AOR or
sent to the shared AOR and no appearance number is available, the sent to the shared AOR and no appearance number is available, the
proxy MAY reject the INVITE with a 403 Forbidden response code. proxy MAY reject the INVITE with a 403 Forbidden response code.
Appearance numbers are only used for dialogs in which one UA Appearance numbers are only used for dialogs in which one UA
associated with the group AOR is a participant. If an incoming associated with the group AOR is a participant. If an incoming
INVITE to the group AOR is forwarded to another AOR, the appearance INVITE to the group AOR is forwarded to another AOR, the appearance
number is immediately freed up and can be assigned to another dialog. number is immediately freed up and can be assigned to another dialog.
6. XML Schema Definition 6. XML Schema Definition
skipping to change at page 20, line 5 skipping to change at page 21, line 5
<xs:simpleType type="xs:integer"> <xs:simpleType type="xs:integer">
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
<xs:element name="exclusive" minOccurs="0" maxOccurs="1"> <xs:element name="exclusive" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:boolean"> <xs:simpleType type="xs:boolean">
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
7. User Interface Considerations 7. Alert-Info Appearance Parameter Definition
This specification extends RFC 3261 [RFC3261] to add an 'appearance'
parameter to the Alert-Info header field, and to also allow proxies
to modify or delete the Alert-Info header field.
The changes to RFC 3261 ABNF are:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI
(generic-param / appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT
A proxy inserting an 'appearance' Alert-Info parameter follows normal
policies Alert-Info policies. If an Alert-Info is already present,
the proxy either removes the Alert-Info if it is not trusted, or adds
the 'appearance' parameter to the Alert-Info header field. If an
appearance number parameter is already present (associated with
another AOR or by mistake), the value is rewritten adding the new
appearance number. There MUST NOT be more than one appearance
parameter in an Alert-Info header field.
If no special ringtone is desired, a normal ringtone should be
indicated using the urn:alert:service:normal in the Alert-Info, as
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
user, following the guidelines in Section 5.3. If the INVITE is
forwarded to another AOR, the appearance parameter in the Alert-Info
SHOULD be removed before forwarding outside the group.
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
registered UAs.
There are a variety of ways the proxy can use to determine what
value it should use to populate this parameter. For example, the
proxy could fetch this information by initiating a SUBSCRIBE
request with Expires: 0 to the Appearance Agent for the AOR to
fetch the list of lines that are in use. Alternatively, it could
act like a UA that is a part of the appearance group and SUBSCRIBE
to the State-Agent like any other UA. This would ensure that the
active dialog information is available without having to poll on a
need basis. It could keep track of the list of active calls for
the appearance AOR based on how many unique INVITE requests it has
forked to or received from the appearance AOR. Another approach
would be for the Proxy to first send the incoming INVITE to the
Appearance Agent which would redirect to the appearance group URI
and escape the proper Alert-Info header field for the Proxy to
recurse and distribute to the other UAs in the group.
The Appearance Agent needs to know about all incoming requests to
the AOR in order to seize the appearance number. One way in which
this could be done is for the Appearance Agent to register against
the AOR with a higher q value. This will result in the INVITE
being sent to the Appearance Agent first, then being offered to
the UAs in the group.
8. User Interface Considerations
The "appearance number" allocated to a call is an important concept The "appearance number" allocated to a call is an important concept
that enables calls to be handled by multiple devices with that enables calls to be handled by multiple devices with
heterogeneous user interfaces in a manner that still allows users to heterogeneous user interfaces in a manner that still allows users to
see a consistent model. Careful treatment of the appearance number see a consistent model. Careful treatment of the appearance number
is essential to meet the expectations of the users. Also, rendering is essential to meet the expectations of the users. Also, rendering
the correct call/appearance state to users is also important. the correct call/appearance state to users is also important.
7.1. Appearance Number Rendering 8.1. Appearance Number Rendering
Since different UAs have different user interface capabilities, it is Since different UAs have different user interface capabilities, it is
usual to find that some UAs have restrictions that others do not. usual to find that some UAs have restrictions that others do not.
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.
7.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. Despite this, displaying status indications for a single appearance. Despite this,
it is important that devices of this type do not ignore the it is important that devices of this type do not ignore the
appearance number. The UA should still send messages annotated with appearance number. The UA should still send messages annotated with
an appropriate appearance number (i.e. "0"). Any call indications an appropriate appearance number (i.e. "0"). Any call indications
for appearances other than for number "0" should be rejected with a for appearances other than for number "0" should be rejected with a
486 or 480 response. 486 or 480 response.
7.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.
Only appearance numbers "0" and "1" will be used by these UAs.
7.1.3. Shared Appearance UAs with Fixed Appearance Number 8.1.3. Shared Appearance UAs with Fixed Appearance Number
This UA is the typical 'business-class' hard-phone. A number of This UA is the typical 'business-class' hard-phone. A number of
appearances are typically configured statically and labeled on appearances are typically configured statically and labeled on
buttons, and calls may be managed using these configured appearances. buttons, and calls may be managed using these configured appearances.
Any calls outside this range should be ignored, and not mapped to a Any calls outside this range should be rejected, and not mapped to a
free button. Users of these devices often seize specific appearance free button. Users of these devices often seize specific appearance
numbers for outgoing calls, and the UA will need to seize the numbers for outgoing calls, and the UA will need to seize the
appearance number and wait for confirmation from the Appearance Agent appearance number and wait for confirmation from the Appearance Agent
before proceeding with calls. before proceeding with calls.
7.1.4. Shared Appearance UAs with Variable Appearance Number 8.1.4. Shared Appearance UAs with Variable Appearance Number
This UA is typically a soft-phone or graphically rich user interface This UA is typically a soft-phone or graphically rich user interface
hard-phone. In these cases, even the idea of an appearance index may hard-phone. In these cases, even the idea of an appearance index may
seem unnecessary. However, for these phones to be able to interwork seem unnecessary. However, for these phones to be able to interwork
successfully with other phone types, it is important that they still successfully with other phone types, it is important that they still
use the appearance index to govern the order of appearance of calls use the appearance index to govern the order of appearance of calls
in progress. No specific guidance on presentation is given except in progress. No specific guidance on presentation is given except
that the order should be consistent. These devices can typically that the order should be consistent. These devices can typically
make calls without waiting for confirmation from the Appearance Agent make calls without waiting for confirmation from the Appearance Agent
on the appearance number. on the appearance number.
8.1.5. Example User Interface Issues
The problems faced by each style of user interface are readily seen The problems faced by each style of user interface are readily seen
in this example: in this example:
1. A call arrives at the shared appearance group, and is assigned an 1. A call arrives at the shared appearance group, and is assigned an
appearance number of 0. All UAs should be able to render to the appearance number of 0. All UAs should be able to render to the
user the arrival of this call. user the arrival of this call.
2. Another call arrives at the shared appearance group, and is 2. Another call arrives at the shared appearance group, and is
assigned an appearance number of 1. The single appearance UA assigned an appearance number of 1. The single appearance UA
should not present this call to the user. Other user agents should not present this call to the user. Other user agents
should have no problems presenting this call distinctly from the should have no problems presenting this call distinctly from the
skipping to change at page 21, line 41 skipping to change at page 24, line 5
Both shared appearance UAs should clearly show that appearance Both shared appearance UAs should clearly show that appearance
number 0 is now free, but that there is still a call on number 0 is now free, but that there is still a call on
appearance number 1. appearance number 1.
4. A third call arrives, and is assigned the appearance number of 0. 4. A third call arrives, and is assigned the appearance number of 0.
All UAs should be able to render the arrival of this new call to All UAs should be able to render the arrival of this new call to
the user. Multiple appearance UAs should continue to indicate the user. Multiple appearance UAs should continue to indicate
the presence of the second call, and should also ensure that the the presence of the second call, and should also ensure that the
presentation order is related to the appearance number and not presentation order is related to the appearance number and not
the order of call arrival. the order of call arrival.
7.2. Call State Rendering 8.2. Call State Rendering
UAs that implement the shared appearance feature typically have a UAs that implement the shared appearance feature typically have a
user interface that provides the state of other appearances in the user interface that provides the state of other appearances in the
group. As dialog state NOTIFYs from the Appearance Agent are group. As dialog state NOTIFYs from the Appearance Agent are
processed, this information can be rendered. Even the simplest user processed, this information can be rendered. Even the simplest user
interface typically has three states: idle, active, and hold. The interface typically has three states: idle, active, and hold. The
idle state, usually indicated by lamp off, is indicated for an idle state, usually indicated by lamp off, is indicated for an
appearance when the appearance number is not associated with any appearance when the appearance number is not associated with any
dialogs, as reported by the Appearance Agent. The active state, dialogs, as reported by the Appearance Agent. The active state,
usually indicated by a lamp on, is indicated by an appearance number usually indicated by a lamp on, is indicated by an appearance number
being associated with at least one dialog, as reported by the being associated with at least one dialog, as reported by the
Appearance Agent. The hold state, often indicated by a blinking Appearance Agent. The hold state, often indicated by a blinking
lamp, means the call state from the perspective of the UA in the lamp, means the call state from the perspective of the UA in the
shared appearance group is hold. This can be determined by the shared appearance group is hold. This can be determined by the
presence of the "sip+rendering=no" feature tag [RFC3840] with the presence of the "sip+rendering=no" feature tag [RFC3840] with the
local target URI. Note that the hold state of the remote target URI local target URI. Note that the hold state of the remote target URI
is not relevant to this display. For joined dialogs, the state is is not relevant to this display. For joined dialogs, the state is
rendered as hold only if all local target URIs are indicated with the rendered as hold only if all local target URIs are indicated with the
"sip+rendering=no" feature tag. "sip+rendering=no" feature tag.
8. Interop with non-Shared Appearance UAs 9. Interop with non-Shared Appearance UAs
It is desirable to allow a basic UA that does not directly support It is desirable to allow a basic UA that does not directly support
shared appearance to be part of a shared appearance group. To shared appearance to be part of a shared appearance group. To
support this the Proxy must collaborate with the Appearance Agent. support this the Proxy must collaborate with the Appearance Agent.
This is not required in the basic shared appearance architecture, This is not required in the basic shared appearance architecture,
consequently shared appearance interop with non-shared appearance UAs consequently shared appearance interop with non-shared appearance UAs
will not be available in all shared appearance deployments. will not be available in all shared appearance deployments.
First, a UA which does not support dialog events or the shared First, a UA which does not support dialog events or the shared
appearance feature will be discussed. Then, a UA which does support appearance feature will be discussed. Then, a UA which does support
dialog events but not the shared appearance feature will be dialog events but not the shared appearance feature will be
discussed. discussed.
8.1. Appearance Assignment 9.1. Appearance Assignment
A UA that has no knowledge of appearances must will only have A UA that has no knowledge of appearances must will only have
appearance numbers for outgoing calls if assigned by the Appearance appearance numbers for outgoing calls if assigned by the Appearance
Agent. If the non-shared appearance UA does not support Join or Agent. If the non-shared appearance UA does not support Join or
Replaces, all dialogs could be marked "exclusive" to indicate that Replaces, all dialogs could be marked "exclusive" to indicate that
these options are not available. these options are not available.
8.2. Appearance Release 9.2. Appearance Release
In all cases the Appearance Agent must be aware of dialog lifetime to In all cases the Appearance Agent must be aware of dialog lifetime to
release appearances back into the group. release appearances back into the group.
It is also desirable that any dialog state changes (such as hold, It is also desirable that any dialog state changes (such as hold,
etc) be made available to other UAs in the group through the Dialog etc) be made available to other UAs in the group through the Dialog
Event Package. If the Appearance Agent includes a proxy which Event Package. If the Appearance Agent includes a proxy which
Record-Routes for dialogs from the non-shared appearance aware UA, Record-Routes for dialogs from the non-shared appearance aware UA,
the Appearance Agent will know about the state of dialogs including the Appearance Agent will know about the state of dialogs including
hold, etc. This information could be determined from inspection of hold, etc. This information could be determined from inspection of
INVITE and re-INVITE messages and added to the dialog information non-end-to-end-encrypted INVITE and re-INVITE messages and added to
conveyed to other UAs. the dialog information conveyed to other UAs.
8.3. UAs Supporting Dialog Events but Not Shared Appearance 9.3. UAs Supporting Dialog Events but Not Shared Appearance
Interoperability with UAs which support dialog events but not the Interoperability with UAs which support dialog events but not the
shared appearance feature is more straightforward. As before, all shared appearance feature is more straightforward. As before, all
appearance number assignment must be done by the Appearance Agent. appearance number assignment must be done by the Appearance Agent.
The Appearance Agent can include appearance information in NOTIFYs - The Appearance Agent can include appearance information in NOTIFYs -
this UA will simply ignore this extra information. This type of UA this UA will simply ignore this extra information. This type of UA
will ignore appearance number limitations and may attempt to Join or will ignore appearance number limitations and may attempt to Join or
Replace dialogs marked exclusive. As a result, the Proxy or UAs may Replace dialogs marked exclusive. As a result, the Proxy or UAs need
need to reject such requests. to reject such requests or the dialogs will get joined or taken.
9. Provisioning Considerations 10. Provisioning Considerations
UAs can automatically discover if this feature is active for an AOR UAs can automatically discover if this feature is active for an AOR
by sending a SUBSCRIBE to the AOR, so no provisioning for this is by looking for the 'shared' Event header parameter in a response to a
dialog package SUBSCRIBE to the AOR, so no provisioning for this is
needed. needed.
The registrar will need to be provisioned to accept either first or The registrar will need to be provisioned to accept either first or
third party registrations for the shared AOR. First party third party registrations for the shared AOR. First party
registration means the To and From URIs in the REGISTER request are registration means the To and From URIs in the REGISTER request are
the shared AOR URI. Third party registration means the To URI is the the shared AOR URI. Third party registration means the To URI is the
shared AOR URI and the From URI is a different AOR, perhaps that of shared AOR URI and the From URI is a different AOR, perhaps that of
the individual user. Either the credentials of the shared AOR or the the individual user. Either the credentials of the shared AOR or the
user MUST be accepted by the registrar and the Appearance Agent, user MUST be accepted by the registrar and the Appearance Agent,
depending on the authorization policy in place for the domain. depending on the authorization policy in place for the domain.
skipping to change at page 23, line 44 skipping to change at page 26, line 6
In some cases, UAs in the shared appearance group might have a UI In some cases, UAs in the shared appearance group might have a UI
limitation on the number of appearances that can be rendered. limitation on the number of appearances that can be rendered.
Typically this will be hard phones with buttons/lamps instead of more Typically this will be hard phones with buttons/lamps instead of more
flexible UIs. In this case, it can be useful for the Appearance flexible UIs. In this case, it can be useful for the Appearance
Agent to know this maximum number. This can allow the Appearance Agent to know this maximum number. This can allow the Appearance
Agent to apply policy when this limit is reached, e.g. deny a call. Agent to apply policy when this limit is reached, e.g. deny a call.
However, this mechanism does not provide any way to discover this by However, this mechanism does not provide any way to discover this by
protocol means. protocol means.
10. Example Message Flows 11. Example Message Flows
The next section shows call flow and message examples. The flows and The next section shows call flow and message examples. The flows and
descriptions are non-normative. Note that in these examples, all descriptions are non-normative. Note that in these examples, all
INVITEs sent by a UA in the group will be From the shared AOR INVITEs sent by a UA in the group will be From the shared AOR
(sip:HelpDesk@example.com in this case), and all INVITES sent to the (sip:HelpDesk@example.com in this case), and all INVITES sent to the
group will have a Request-URI of the shared AOR. Any other requests group will have a Request-URI of the shared AOR. Any other requests
would not apply to this feature and would be handled using normal SIP would not apply to this feature and would be handled using normal SIP
mechanisms. mechanisms.
Note that the first twelve examples assume the Appearance Agent is Note that the first twelve examples assume the Appearance Agent is
aware of dialog state events. Example 10.13 shows the case where aware of dialog state events. The example in Section 11.13 shows the
this is not the case and as a result the Appearance Agent initiates a case where this is not the case and as a result the Appearance Agent
subscription to users of the shared AOR. Any of the other call flow initiates a subscription to users of the shared AOR. Any of the
examples could have shown this mode of operation as it is equally other call flow examples could have shown this mode of operation as
valid. it is equally valid.
10.1. Registration and Subscription 11.1. Registration and Subscription
Bob and Alice are in an appearance group identified by the shared Bob and Alice are in an appearance group identified by the shared
appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact
sip:bob@ua2.example.com. Alice REGISTERs with contact sip:bob@ua2.example.com. Alice REGISTERs with contact
sip:alice@ua1.example.com. sip:alice@ua1.example.com.
User Agents for Alice and Bob subscribe to the dialog package for the User Agents for Alice and Bob subscribe to the dialog package for the
appearance AOR and publish dialog state to the Appearance Agent. appearance AOR and publish dialog state to the Appearance Agent.
Message exchanges between the Registrar, Appearance Agent, Alice, and Message exchanges between the Registrar, Appearance Agent, Alice, and
Bob are shown below. The call flow examples below do not show the Bob are shown below. The call flow examples below do not show the
authentication of subscriptions, publications, and notifications. It authentication of subscriptions, publications, and notifications. It
should be noted that for security purposes, all subscriptions must be should be noted that for security purposes, all subscriptions must be
authorized before the same is accepted. authorized before the SUBSCRIBE is accepted.
Also note that registrations and subscriptions must all be refreshed Also note that registrations and subscriptions must all be refreshed
by Alice at intervals determined by the expiration intervals returned by Alice at intervals determined by the expiration intervals returned
by the Registrar or Appearance Agent. by the Registrar or Appearance Agent.
Registrar Appearance Agent Alice Bob Registrar Appearance Agent Alice Bob
| | | | | | | |
| | | | | | | |
|<--------------------------- REGISTER F1<| | |<--------------------------- REGISTER F1<| |
| | | | | | | |
skipping to change at page 25, line 34 skipping to change at page 27, line 44
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb Call-ID: d3281184-518783de-cc23d6bb
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Max-Forwards: 70 Max-Forwards: 70
Expires: 3600 Expires: 3600
Content-Length: 0 Content-Length: 0
F2 Registrar ----> Alice F2 Registrar ----> Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb Call-ID: d3281184-518783de-cc23d6bb
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:HelpDesk@example.com>;tag=1664573879820199 To: <sip:HelpDesk@example.com>;tag=1664573879820199
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>;expires=3600
Expires: 3600
Content-Length: 0 Content-Length: 0
F3 to F6: Alice also subscribes to the events associated with the F3 to F6: Alice also subscribes to the events associated with the
Appearance AOR. Appearance Agent notifies Alice of the status. Appearance AOR. Appearance Agent notifies Alice of the status.
F3 Alice ----> Appearance Agent F3 Alice ----> Appearance Agent
SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:HelpDesk@example.com> To: <sip:HelpDesk@example.com>
CSeq: 91 SUBSCRIBE CSeq: 91 SUBSCRIBE
skipping to change at page 26, line 39 skipping to change at page 28, line 46
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=1636248422222257 From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
CSeq: 232 NOTIFY CSeq: 232 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
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 Subscription-State: active;expires=3000
Contact: <appearanceagent.example.com> Contact: <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"
version="40" version="40"
state="full" state="full"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
</dialog-info> </dialog-info>
F6 Alice ----> Appearance Agent F6 Alice ----> Appearance Agent
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
From: <sip:HelpDesk@example.com>;tag=1636248422222257 From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
CSeq: 232 NOTIFY CSeq: 232 NOTIFY
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Event: dialog;shared
Content-Length: 0 Content-Length: 0
F7 Bob ----> Registrar F7 Bob ----> Registrar
REGISTER sip:registrar.example.com SIP/2.0 REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131 From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com> To: <sip:HelpDesk@example.com>
CSeq: 72 REGISTER CSeq: 72 REGISTER
Call-ID: 139490230230249348 Call-ID: 139490230230249348
skipping to change at page 27, line 41 skipping to change at page 30, line 5
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131 From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>;tag=fkwlwqi1 To: <sip:HelpDesk@example.com>;tag=fkwlwqi1
CSeq: 72 REGISTER CSeq: 72 REGISTER
Call-ID: 139490230230249348 Call-ID: 139490230230249348
Contact: <sip:alice@ua1.example.com>;expires=3200 Contact: <sip:alice@ua1.example.com>;expires=3200
Contact: <sip:bob@ua2.example.com>;expires=3600 Contact: <sip:bob@ua2.example.com>;expires=3600
Content-Length: 0 Content-Length: 0
10.2. Appearance Selection for Incoming Call 11.2. Appearance Selection for Incoming Call
In the call flow below Bob and Alice are in an appearance group. In the call flow below Bob and Alice are in an appearance group.
Carol places a call to the appearance group AOR. The Appearance Carol places a call to the appearance group AOR. The Appearance
Agent sends NOTIFYs to Alice and Bob telling them what appearance the Agent sends NOTIFYs to Alice and Bob telling them what appearance the
call is using. Both Alice and Bob's devices are alerted of the call is using. Both Alice and Bob's devices are alerted of the
incoming call. Bob answers the call. incoming call. Bob answers the call.
Note that it is possible that both Alice and Bob answer the call and Note that it is possible that both Alice and Bob answer the call and
send 200 OK responses to Carol. It is up to Carol to resolve this send 200 OK responses to Carol. It is up to Carol to resolve this
situation. Typically, Carol will send ACKs to both 200 OKs but send situation. Typically, Carol will send ACKs to both 200 OKs but send
skipping to change at page 29, line 33 skipping to change at page 31, line 39
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937 From: <sip:HelpDesk@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sip: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;branch=z9hG4bK1403 Via: SIP/2.0/UDP appearanceagent.example.com;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 Subscription-State: active;expires=2800
Contact: <appearanceagent.example.com> Contact: <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="13" version="13"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c" <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
skipping to change at page 30, line 40 skipping to change at page 32, line 45
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
F21 Appearance Agent ----> Alice F21 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937 From: <sip:HelpDesk@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sip:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4 Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 12 NOTIFY CSeq: 13 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j
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 Subscription-State: active;expires=2500
Contact: <appearanceagent.example.com> Contact: <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="13" version="13"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c" <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
skipping to change at page 31, line 24 skipping to change at page 33, line 30
<state>confirmed</state> <state>confirmed</state>
<local> <local>
<target>sip:bob@ua2.example.com</target> <target>sip:bob@ua2.example.com</target>
</local> </local>
<remote> <remote>
<identity>sip:carol@ua.example.com</identity> <identity>sip:carol@ua.example.com</identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.3. Outgoing Call without Appearance Seizure 11.3. Outgoing Call without Appearance Seizure
In this scenario, Bob's UA places a call without first selecting/ In this scenario, Bob's UA places a call without first selecting/
seizing an appearance number. After Bob sends the INVITE, the seizing an appearance number. After Bob sends the INVITE, the
appearance assigns an appearance number for it and notifies both appearance assigns an appearance number for it and notifies both
Alice and Bob. Alice and Bob.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | | | | | | | |
| |<------------------------------------- INVITE F1<| | |<------------------------------------- INVITE F1<|
skipping to change at page 33, line 19 skipping to change at page 35, line 25
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62
From: <sip:HelpDesk@example.com>;tag=1636248422222257 From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
CSeq: 233 NOTIFY CSeq: 233 NOTIFY
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 Subscription-State: active;expires=2200
Contact: <appearanceagent.example.com> Contact: <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="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
skipping to change at page 34, line 8 skipping to change at page 36, line 14
NOTIFY sip:bob@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=497585728578386 From: <sip:HelpDesk@example.com>;tag=497585728578386
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK1711759878512309 ;branch=z9hG4bK1711759878512309
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 Subscription-State: active;expires=2000
Contact: <sip:appearanceagent.example.com> Contact: <sip: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="27" version="78"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="02538339hfgdf3ce597f9e3egkl3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator"> local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.4. Outgoing Call with Appearance Seizure 11.4. Outgoing Call with Appearance Seizure
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) selecting/seizing an appearance number before sending state (trying) selecting/seizing an appearance number before sending
the INVITE. After receiving the 200 OK from the Appearance Agent the INVITE. After receiving the 200 OK from the Appearance Agent
confirming the appearance number, Bob's UA sends the INVITE to Carol confirming the appearance number, Bob's UA sends the INVITE to Carol
and establishes a session. For brevity, details of some of the and establishes a session. For brevity, details of some of the
messages are not included in the message flows. messages are not included in the message flows.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
skipping to change at page 36, line 20 skipping to change at page 38, line 26
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@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="6" version="6"
state="partial" state="full"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
skipping to change at page 37, line 35 skipping to change at page 39, line 41
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@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="6" version="6"
state="partial" state="full"
entity="sip:HelpDesk@example.com"> entity="sip: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"
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>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
skipping to change at page 38, line 4 skipping to change at page 40, line 11
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<identity uri="sip:carol@example.com"> <identity uri="sip:carol@example.com">
</identity> </identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.5. Outgoing Call without using an Appearance Number 11.5. Outgoing Call without using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' dialog event parameter. appearance element but does have the 'shared' dialog event parameter.
As a result, the Appearance Agent knows the UA does not wish to use As a result, the Appearance Agent knows the UA does not wish to use
an appearance number for this call. If the Appearance Agent does not an appearance number for this call. If the Appearance Agent does not
wish to allow this, it would reject the PUBLISH with a 409 Conflict wish to allow this, it would reject the PUBLISH with a 409 Conflict
response and the UA would know to re-PUBLISH selecting/seizing an response and the UA would know to re-PUBLISH selecting/seizing an
appearance number. appearance number.
skipping to change at page 39, line 42 skipping to change at page 41, line 49
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@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="6" version="6"
state="partial" state="full"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="id3d4f9c83" direction="initiator">
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
Note that F7 would be the same as the previous example. Note that F7 would be the same as the previous example.
10.6. Appearance Release 11.6. Appearance Release
Bob and Carol are in a dialog, created, for example as in Section Bob and Carol are in a dialog, created, for example as in
10.3. Carol sends a BYE to Bob to terminate the dialog and the Section 11.3. Carol sends a BYE to Bob to terminate the dialog and
Appearance Agent de-allocates the appearance number used, sending the Appearance Agent de-allocates the appearance number used, sending
notifications out to the UAs in the shared group. notifications out to the UAs in the shared group.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
|>F22 BYE ---->| | | | |>F22 BYE ---->| | | |
| |>F23 BYE --------------------------------------->| | |>F23 BYE --------------------------------------->|
| | | | | | | | | |
skipping to change at page 40, line 50 skipping to change at page 43, line 8
NOTIFY sip:bob@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=497585728578386 From: <sip:HelpDesk@example.com>;tag=497585728578386
To: <sip:bob@example.com> To: <sip:bob@example.com>
Call-ID: a7d559db-d6d7dcad-311c9e3a Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK759878512309 ;branch=z9hG4bK759878512309
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 Subscription-State: active;expires=1800
Contact: <sip:appearanceagent.example.com> Contact: <sip: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="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
skipping to change at page 41, line 26 skipping to change at page 43, line 33
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>terminated</state> <state>terminated</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.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.
skipping to change at page 43, line 24 skipping to change at page 45, line 32
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937 From: <sip:HelpDesk@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sip: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/UDP 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 Subscription-State: active;expires=1800
Contact: <sip:appearanceagent.example.com> Contact: <sip: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="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
skipping to change at page 44, line 26 skipping to change at page 46, line 33
Contact: <sip:alice@ua2.example.com> Contact: <sip: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="partial" state="full"
entity="sip:HelpDesk@example.com"> entity="sip: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" />
skipping to change at page 45, line 30 skipping to change at page 47, line 37
o=- 1102980497 1102980497 IN IP4 ua1.example.com o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA s=IP SIP UA
c=IN IP4 ua1.example.com c=IN IP4 ua1.example.com
t=0 0 t=0 0
a=sendrecv a=sendrecv
m=audio 2238 RTP/AVP 0 8 101 m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
10.8. Calls between UAs within the Group 11.8. Calls between UAs within the Group
In this scenario, Bob calls Alice who is also in the Appearance In this scenario, Bob calls Alice who is also in the Appearance
group. Only one appearance number is used for this dialog. This group. Only one appearance number is used for this dialog. This
example also shows the use of the 'exclusive' tag to indicate that example also shows the use of the 'exclusive' tag to indicate that
other UAs in the group can not join or take this dialog. other UAs in the group can not join or take this dialog.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| |<-------------------- INVITE (to Alice's UA) F1<| | |<-------------------- INVITE (to Alice's UA) F1<|
| | | | | | | | | |
skipping to change at page 47, line 6 skipping to change at page 49, line 14
NOTIFY sip:bob@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=497585728578386 From: <sip:HelpDesk@example.com>;tag=497585728578386
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK1711759878512309 ;branch=z9hG4bK1711759878512309
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 Subscription-State: active;expires=1500
Contact: <sip:appearanceagent.example.com> Contact: <sip: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="sip:HelpDesk@example.com">
<dialog id="3xdsd4f9c83" <dialog id="3xdsd4f9c83"
skipping to change at page 47, line 44 skipping to change at page 50, line 4
<dialog id="4839589" <dialog id="4839589"
call-id="b3cbd0-ad2c5775e-5df9f8d5" call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B" local-tag="3153DE7C-928203B"
remote-tag="34322kdfr234f" remote-tag="34322kdfr234f"
direction="responder"> direction="responder">
<sa:exclusive>true</sa:exclusive> <sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<state>confirmed</state> <state>confirmed</state>
<local> <local>
<target uri="sip:alice@ua1.example.com" /> <target uri="sip:alice@ua1.example.com" />
</local> </local>
<remote> <remote>
<identity>sip:HelpDesk@example.com</identity> <identity>sip:HelpDesk@example.com</identity>
<target uri="sip:bob@ua2.example.com" /> <target uri="sip:bob@ua2.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.9. Consultation Hold with Appearances 11.9. Consultation Hold with Appearances
In this scenario, Bob has a call with Carol. Bob makes a In this scenario, Bob has a call with Carol. Bob makes a
consultation call to Alice by putting Carol on hold and calling consultation call to Alice by putting Carol on hold and calling
Alice. Bob chooses not to have an appearance number for the call to Alice. Bob chooses not to have an appearance number for the call to
Alice since he is treating it as part of the call to Carol. He Alice since he is treating it as part of the call to Carol. He
indicates this in his PUBLISH F32 which contains the 'shared' Event indicates this in his PUBLISH F32 which contains the 'shared' Event
parameter but no <appearance> element. The PUBLISH is sent before parameter but no <appearance> element. The PUBLISH is sent before
the INVITE to Alice to ensure no appearance number is assigned by the the INVITE to Alice to ensure no appearance number is assigned by the
Appearance Agent. Finally, Bob hangs up with Alice and resumes the Appearance Agent. Finally, Bob hangs up with Alice and resumes the
call with Carol. Note that the Appearance Agent does not generate call with Carol. Dialog notifications of the consultation call are
notifications on the dialog state of the consultation call. not shown, as they are not used.
Note that if Carol hangs up while Bob is consulting with Alice, Bob Note that if Carol hangs up while Bob is consulting with Alice, Bob
can decide if he wants to reuse the appearance number used with Carol can decide if he wants to reuse the appearance number used with Carol
for the call with Alice. If not, Bob publishes the termination of for the call with Alice. If not, Bob publishes the termination of
the dialog with Carol and the Appearance Agent will re-allocate the the dialog with Carol and the Appearance Agent will re-allocate the
appearance. If he wants to keep the appearance, Bob will publish the appearance. If he wants to keep the appearance, Bob will publish the
termination of the dialog with Carol and also publish the appearance termination of the dialog with Carol and also publish the appearance
with the dialog with Alice. This will result in Bob keeping the with the dialog with Alice. This will result in Bob keeping the
appearance number until he reports the dialog with Alice terminated. appearance number until he reports the dialog with Alice terminated.
skipping to change at page 50, line 24 skipping to change at page 52, line 34
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@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="partial" state="full"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5" call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B" local-tag="3153DE7C-928203B"
direction="initiator"> direction="initiator">
<sa:exclusive>true</sa:exclusive> <sa:exclusive>true</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:HelpDesk@example.com</identity> <identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" /> <target uri="sip:alice@ua1.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.10. Joining or Bridging an Appearance 11.10. Joining or Bridging an Appearance
In this call flow, a call answered by Bob is joined by Alice or In this call flow, a call answered by Bob is joined by Alice or
"bridged". The Join header field is used by Alice to request this "bridged". The Join header field is used by Alice to request this
bridging. If Bob did not support media mixing, Bob could obtain bridging. If Bob did not support media mixing, Bob could obtain
conferencing resources as described in [RFC4579]. conferencing resources as described in [RFC4579].
Carol Forking Proxy Appearance Agent Alice Bob Carol Forking Proxy Appearance Agent Alice Bob
| | | | | | | | | |
|<=============Both way RTP established===========>| |<=============Both way RTP established===========>|
| | | | | | | | | |
| | |< PUBLISH F22| | | | |< PUBLISH F22| |
| | | | | | | | | |
| | |>F23 200 OK >| | | | |>F23 200 OK >| |
| | | | | | | | | |
| |<---- INVITE (w/ Join) F24<| | | |<---- INVITE (w/ Join) F24<| |
| | | | | | | | | |
| |>F25 INVITE (w/Join)---------------->| | |>F25 INVITE (w/Join)---------------->|
| | | | | | | | | |
| |<---- OK 200 Contact:Bob;isfocus F26<| | |<---- OK 200 Contact:Bob;isfocus F26<|
| | | | | | | | | |
| |< - - - - - >| | | | |< - - - - - >| | |
| | | | | | | | | |
| | |>F27 NOTIFY >| | | | |>F27 NOTIFY >| |
| | | | | | | | | |
| | |< 200 OK F28<| | | | |< 200 OK F28<| |
| | | | | | | | | |
| | |>F29 NOTIFY ---------->| | | |>F29 NOTIFY ---------->|
| | | | | | | | | |
| | |<F30 200 OK ----------<| | | |<F30 200 OK ----------<|
| | | | | | | | | |
| |>F31 200 OK Contact:B----->| | | |>F31 200 OK Contact:B----->| |
skipping to change at page 51, line 42 skipping to change at page 53, line 52
| |<-----INVITE Contact:Bob;isfocus F34<| | |<-----INVITE Contact:Bob;isfocus F34<|
|<-INVITE F35| | | | |<-INVITE F35| | | |
| | | | | | | | | |
|>F26 200 -->| | | | |>F26 200 -->| | | |
| |>F37 200 OK ------------------------>| | |>F37 200 OK ------------------------>|
| | | | | | | | | |
| |<--------------------------- ACK F38<| | |<--------------------------- ACK F38<|
|<--- ACK F39| | | | |<--- ACK F39| | | |
| | | |<==RTP==>| | | | |<==RTP==>|
|<=============Both way RTP established===========>| |<=============Both way RTP established===========>|
| | | | | | | | | |
| |< - - - - - >| | | | |< - - - - - >| | |
| | | | | | | | | |
| | |>F40 NOTIFY >| | | | |>F40 NOTIFY >| |
| | | | | | | | | |
| | |< 200 OK F41<| | | | |< 200 OK F41<| |
| | | | | | | | | |
| | |>F42 NOTIFY ---------->| | | |>F42 NOTIFY ---------->|
| | | | | | | | | |
| | |<F43 200 OK ----------<| | | |<F43 200 OK ----------<|
| | | | | | | | | |
skipping to change at page 52, line 26 skipping to change at page 54, line 35
Contact: <sip:alice@ua2.example.com> Contact: <sip: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="partial" state="full"
entity="sip:HelpDesk@example.com:5060"> entity="sip:HelpDesk@example.com:5060">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48" call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" > local-tag="605AD957-1F6305C2" >
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<sa:joined-dialog <sa:joined-dialog
call-id="14-1541707345" call-id="14-1541707345"
from-tag="44BAD75D-E3128D42" from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
skipping to change at page 53, line 29 skipping to change at page 55, line 37
o=- 1103061265 1103061265 IN IP4 ua1.example.com o=- 1103061265 1103061265 IN IP4 ua1.example.com
s=IP SIP UA s=IP SIP UA
c=IN IP4 ua1.example.com c=IN IP4 ua1.example.com
t=0 0 t=0 0
a=sendrecv a=sendrecv
m=audio 2236 RTP/AVP 0 8 101 m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
10.11. Appearance Allocation - Loss of Appearance 11.11. Appearance Allocation - Loss of Appearance
Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol,
then becomes unreachable. When he fails to refresh his publication then becomes unreachable. When he fails to refresh his publication
to the appearance agent, the Appearance Agent declares the dialog to the appearance agent, the Appearance Agent declares the dialog
terminated and frees up the appearance using NOTIFYs F14 and F16. terminated and frees up the appearance using NOTIFYs F14 and F16.
After retransmitting the NOTIFY to Bob (in not shown messages F17, After retransmitting the NOTIFY to Bob (in not shown messages F17,
F18, etc.), the subscription is terminated. F18, etc.), the subscription is terminated.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
skipping to change at page 54, line 42 skipping to change at page 56, line 42
| | | | | | | | | |
| | |<- NOTIFY F14<| | | | |<- NOTIFY F14<| |
| | | | | | | | | |
| | |>F15 200 OK ->| | | | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>| | | | |------ NOTIFY F16>|
| | | | | | | | | |
| | | NOTIFY is retransmitted | | | | NOTIFY is retransmitted |
Figure 11. Figure 11.
10.12. Appearance Seizure Contention Race Condition 11.12. Appearance Seizure Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the Bob and Alice both try to reserve appearance 2 by publishing at the
same time. The Appearance Agent allocates the appearance to Bob by same time. The Appearance Agent allocates the appearance to Bob by
sending a 200 OK and denies it to Alice by sending a 409 Conflict. sending a 200 OK and denies it to Alice by sending a 409 Conflict.
After the NOTIFY F5, Alice learns that Bob is using appearance 2. After the NOTIFY F5, Alice learns that Bob is using appearance 2.
Alice then attempts to reserve appearance 3 by publishing, which is Alice then attempts to reserve appearance 3 by publishing, which is
then accepted. then accepted.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
skipping to change at page 55, line 47 skipping to change at page 57, line 47
Dave | | |------ NOTIFY F18>| Dave | | |------ NOTIFY F18>|
| | | | | | | | | |
| | | |<F19 200 OK -----<| | | | |<F19 200 OK -----<|
| |<-- INVITE F20<| | | | |<-- INVITE F20<| | |
| | | | | | | | | |
| |>F21 100 ----->| | | | |>F21 100 ----->| | |
|<- INVITE F22<| | | | |<- INVITE F22<| | | |
Figure 12. Figure 12.
10.13. Appearance Agent Subscription to UAs 11.13. Appearance Agent Subscription to UAs
In this scenario, the Appearance Agent does not have any way of In this scenario, the Appearance Agent does not have any way of
knowing Bob's dialog state information, except through Bob. This knowing Bob's dialog state information, except through Bob. This
could be because the Appearance Agent is not part of a B2BUA, or could be because the Appearance Agent is not part of a B2BUA, or
perhaps Bob is remotely registering. When Bob registers, the perhaps Bob is remotely registering. When Bob registers, the
Appearance Agent receives a registration event package notification Appearance Agent receives a registration event package notification
from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's
dialog event state using Event:dialog in the SUBSCRIBE. Whenever dialog event state using Event:dialog in the SUBSCRIBE. Whenever
Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent
who then notifies the other other UAs in the group. who then notifies the other other UAs in the group.
skipping to change at page 57, line 35 skipping to change at page 59, line 35
| | |<- NOTIFY F36<| | | | |<- NOTIFY F36<| |
| | | | | | | | | |
| | |>F37 200 OK ->| | | | |>F37 200 OK ->| |
| | | |------ NOTIFY F38>| | | | |------ NOTIFY F38>|
| | | | | | | | | |
| | | |<F39 200 OK -----<| | | | |<F39 200 OK -----<|
| | | | | | | | | |
Figure 13. Figure 13.
10.14. Appearance Pickup Race Condition Failure 11.14. Appearance Pickup Race Condition Failure
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 attempts to pick up the call but Carol hangs up Alice's UI. Alice attempts to pick up the call but Carol hangs up
before the pickup can complete. Alice cancels the pickup attempt before the pickup can complete. Alice cancels the pickup attempt
with the PUBLISH F48. Note that the call flow for a failed Join with the PUBLISH F48. Note that the call flow for a failed Join
would be almost identical. would be almost identical.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
skipping to change at page 59, line 28 skipping to change at page 61, line 28
Contact: <sip:alice@ua2.example.com> Contact: <sip: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="partial" state="full"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48" call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" > local-tag="605AD957-1F6305C2" >
<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="14-1541707345" call-id="14-1541707345"
from-tag="44BAD75D-E3128D42" from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
skipping to change at page 60, line 5 skipping to change at page 62, line 5
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sip:alice@ua1.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<target uri="sip:carol@ua3.example.com" /> <target uri="sip:carol@ua3.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition
Alice tries to seize appearance 2 at the same time appearance 2 is Alice tries to seize appearance 2 at the same time appearance 2 is
allocated to an incoming call. The Appearance Agent resolves the allocated to an incoming call. The Appearance Agent resolves the
conflict by sending a 409 Conflict to Alice. After the NOTIFY F6, conflict by sending a 409 Conflict to Alice. After the NOTIFY F6,
Alice learns that the incoming call is using appearance 2. Alice Alice learns that the incoming call is using appearance 2. Alice
republishes for appearance 3, which is accepted. Note that this republishes for appearance 3, which is accepted. Note that this
example shows the INVITE being received before the NOTIFY from the example shows the INVITE being received before the NOTIFY from the
Appearance Agent. Appearance Agent.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
skipping to change at page 61, line 5 skipping to change at page 63, line 5
Dave | | |------ NOTIFY F14>| Dave | | |------ NOTIFY F14>|
| | | | | | | | | |
| | | |<F15 200 OK -----<| | | | |<F15 200 OK -----<|
| |<-- INVITE F16<| | | | |<-- INVITE F16<| | |
| | | | | | | | | |
| |>F17 100 ----->| | | | |>F17 100 ----->| | |
|<- INVITE F18<| | | | |<- INVITE F18<| | | |
Figure 15. Figure 15.
11. Incoming Appearance Assignment
A proxy inserting an 'appearance' Alert-Info parameter follows normal
policies Alert-Info policies. If an Alert-Info is already present,
the proxy either removes the Alert-Info if it is not trusted, or adds
the 'appearance' parameter to the Alert-Info header field. If an
appearance number parameter is already present (associated with
another AOR or by mistake), the value is rewritten adding the new
appearance number. There MUST NOT be more than one appearance
parameter in an Alert-Info header field.
If no special ringtone is desired, a normal ringtone should be
indicated using the urn:alert:service:normal in the Alert-Info, as
per [I-D.liess-dispatch-alert-info-urns]. The appearance number
present 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
forwarded to another AOR, the appearance parameter in the Alert-Info
SHOULD be removed before forwarding outside the group.
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
registered UAs.
There are a variety of ways the proxy can use to determine what
value it should use to populate this parameter. For example, the
proxy could fetch this information by initiating a SUBSCRIBE
request with Expires: 0 to the Appearance Agent for the AOR to
fetch the list of lines that are in use. Alternatively, it could
act like a UA that is a part of the appearance group and SUBSCRIBE
to the State-Agent like any other UA. This would ensure that the
active dialog information is available without having to poll on a
need basis. It could keep track of the list of active calls for
the appearance AOR based on how many unique INVITE requests it has
forked to or received from the appearance AOR. Another approach
would be for the Proxy to first send the incoming INVITE to the
Appearance Agent which would redirect to the appearance group URI
and escape the proper Alert-Info header field for the Proxy to
recurse and distribute to the other UAs in the group.
The Appearance Agent needs to know about all incoming requests to
the AOR in order to seize the appearance number. One way in which
this could be done is for the Appearance Agent to register against
the AOR with a higher q value. This will result in the INVITE
being sent to the Appearance Agent first, then being offered to
the UAs in the group.
The changes to RFC 3261 ABNF are:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT
12. Security Considerations 12. Security Considerations
Since multiple line appearance features are implemented using Since multiple line appearance features are implemented using
semantics provided by [RFC3261], Event Package for Dialog State as semantics provided by [RFC3261], Event Package for Dialog State as
define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
[RFC3903], security considerations in these documents apply to this [RFC3903], security considerations in these documents apply to this
draft as well. draft as well.
Specifically, since dialog state information and the dialog NOTIFY or PUBLISH message bodies that provide the dialog state
identifiers are supplied by UA's in an appearance group to other information and the dialog identifiers MAY be encrypted end-to-end
members, the same is prone to "call hijacks". For example, a rogue using the standard mechanisms. All SUBSCRIBES between the UA's and
UA could snoop for these identifiers and send an INVITE with Replaces the Appearance Agent MUST be authenticated.
header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in [RFC3261]. before it
is accepted. NOTIFY or PUBLISH message bodies that provide the
dialog state information and the dialog identifiers MAY be encrypted
end-to-end using the standard mechanics. All SUBSCRIBES between the
UA's and the Appearance Agent MUST be authenticated.
13. IANA Considerations 13. IANA Considerations
This section registers the SIP event package parameter 'shared', the This section registers the SIP event package parameter 'shared', the
SIP Alert-Info header field parameter "appearance" and the XML 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 Package Parameter: shared 13.1. SIP Event Package Parameter: shared
This specification defines a new event parameter 'shared' for the This specification defines a new event parameter 'shared' for the
skipping to change at page 64, line 51 skipping to change at page 65, line 51
[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.
[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-01 (work in progress), draft-ietf-sipcore-rfc3265bis-02 (work in progress),
February 2010. August 2010.
[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.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004. September 2004.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation Initiated Dialog Event Package for the Session Initiation
skipping to change at page 65, line 27 skipping to change at page 66, line 27
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004. (SIP) "Join" Header", RFC 3911, October 2004.
[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.liess-dispatch-alert-info-urns] [I-D.ietf-salud-alert-info-urns]
Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and
A. Siddiqui, "Alert-Info URNs for the Session Initiation A. Siddiqui, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-liess-dispatch-alert-info-urns-02 Protocol (SIP)", draft-ietf-salud-alert-info-urns-00 (work
(work in progress), July 2010. in progress), December 2010.
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-05 (work -- Music on Hold", draft-worley-service-example-06 (work
in progress), July 2010. in progress), December 2010.
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. 103 change blocks. 
284 lines changed or deleted 344 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/