draft-ietf-bliss-shared-appearances-00.txt   draft-ietf-bliss-shared-appearances-01.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Expires: March 28, 2009 M. Soroushnejad Expires: May 6, 2009 M. Soroushnejad
V. Venkataramanan V. Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
P. Pepper November 2, 2008
Citel Technologies
A. Kumar
Yahoo Inc.
September 24, 2008
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-00 draft-ietf-bliss-shared-appearances-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 28, 2009. This Internet-Draft will expire on May 6, 2009.
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 (SA) of an Protocol (SIP), it is referred to as Shared Appearances (SA) of an
Address of Record (AOR) since SIP does not have the concept of lines. Address of Record (AOR) since SIP does not have the concept of lines.
This feature is commonly offered in the IP Centrex services and IP- This feature is commonly offered in IP Centrex services and IP-PBX
PBX offerings and is likely to be implemented on SIP IP telephones offerings and is likely to be implemented on SIP IP telephones and
and SIP feature servers used in a business environment. This SIP feature servers used in a business environment. This document
document lists requirements and compares implementation options for lists requirements and compares implementation options for this
this feature. Extensions to the SIP dialog event package are feature. Extensions to the SIP dialog event package are proposed.
proposed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5
3.2. BLA Call Group . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Normative Description . . . . . . . . . . . . . . . . . . . . 7 5. Normative Description . . . . . . . . . . . . . . . . . . . . 7
5.1. Implementation . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Implementation . . . . . . . . . . . . . . . . . . . . . 8
5.2. SA Dialog Package Extensions . . . . . . . . . . . . . . . 10 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 10
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 11 5.2.1. The <appearance> element . . . . . . . . . . . . . . . 10
5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 11 5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 11
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 11 5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 11
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 11
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 11 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 11
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . . 13 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 14
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 14 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16
7. User Interface Considerations . . . . . . . . . . . . . . . . 15 7. User Interface Considerations . . . . . . . . . . . . . . . . 17
7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 15 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18
7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 16 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18
7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 16 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18
7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 16 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 18
7.1.4. Shared Appearance UAs with Variable Appearance 7.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 16 Number . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Call State Rendering . . . . . . . . . . . . . . . . . . . 17 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19
8. Interop with non-SA UAs . . . . . . . . . . . . . . . . . . . 17 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20
8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 18 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20
8.2. Appearance Release . . . . . . . . . . . . . . . . . . . . 18 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20
8.3. UAs Supporting Dialog Events but Not SA . . . . . . . . . 18 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21
9. Provisioning Considerations . . . . . . . . . . . . . . . . . 19 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21
10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 19 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21
10.1. Registration and Subscription . . . . . . . . . . . . . . 19 10.1. Registration and Subscription . . . . . . . . . . . . . . 21
10.2. Appearance Selection for Outgoing Call . . . . . . . . . . 22 10.2. Appearance Selection for Incoming Call . . . . . . . . . 24
10.3. Taking an Appearance . . . . . . . . . . . . . . . . . . . 26 10.3. Outgoing Call with Without Appearance Pre-Selection . . . 28
10.4. Appearance Selection for Incoming Call . . . . . . . . . . 33 10.4. Outgoing Call with Appearance Selection . . . . . . . . . 33
10.5. Appearance Publication . . . . . . . . . . . . . . . . . . 37 10.5. Outgoing Call without using an Appearance Number . . . . 37
10.6. Joining an Appearance . . . . . . . . . . . . . . . . . . 39 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 39
10.7. Appearance Allocation - Loss of Subscription with UA . . . 42 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 40
10.8. Appearance Selection Contention Race Condition . . . . . . 43 10.8. Calls between UAs within the Group . . . . . . . . . . . 44
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 10.9. Consultation Hold with Appearances . . . . . . . . . . . 47
11.1. SIP Event Package Parameter: sa . . . . . . . . . . . . . 44 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 52
11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . . 44 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 55
11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 45 10.12. Appearance Selection Contention Race Condition . . . . . 56
12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 45 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
13. Appendix B - Implementation Options Discussion . . . . . . . . 46 11.1. SIP Event Package Parameter: shared . . . . . . . . . . . 58
13.1. Appearance Implementation Options . . . . . . . . . . . . 46 11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 58
13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 46 11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 59
13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 47 12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 59
13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 50 13. Appendix B - Implementation Options Discussion . . . . . . . . 60
13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 52 13.1. Appearance Implementation Options . . . . . . . . . . . . 60
13.2.1. Comparison of Appearance Selection Methods . . . . . . 53 13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 60
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 61
15. Security Considerations . . . . . . . . . . . . . . . . . . . 54 13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 64
16. Informative References . . . . . . . . . . . . . . . . . . . . 55 13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 13.2.1. Comparison of Appearance Selection Methods . . . . . . 67
Intellectual Property and Copyright Statements . . . . . . . . . . 57 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
15. Security Considerations . . . . . . . . . . . . . . . . . . . 69
16. Informative References . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . . . . 72
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 [RFC3265], PUBLISH REFER [RFC3515], SUBSCRIBE/NOTIFY primitives [RFC3265], PUBLISH
[RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911], header [RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911], header
skipping to change at page 4, line 41 skipping to change at page 4, line 41
the use of URI parameters, feature tags, and dialog package the use of URI parameters, feature tags, and dialog package
extensions along with the strengths and weaknesses of the various extensions along with the strengths and weaknesses of the various
approaches. approaches.
A call flow for Single Line Extension was formerly included in the A call flow for Single Line Extension was formerly included in the
SIP Service Examples [I-D.ietf-sipping-service-examples]. However, SIP Service Examples [I-D.ietf-sipping-service-examples]. However,
the attempt to implement using standard SIP primitives ultimately the attempt to implement using standard SIP primitives ultimately
failed, leading to its removal from that document. This document failed, leading to its removal from that document. This document
defines SIP extensions to implement this service. defines SIP extensions to implement this service.
In traditional telephony, the line is physical. A common scenario is In traditional telephony, the line is physical. A common scenario in
for a number of business telephones to share a single or a small telephony is for a number of business telephones to share a single or
number of Address of Record (AOR) URIs. The sharing of this AOR a small number of lines. The sharing or appearance of these lines
between multiple UAs is what gives this feature its name. In between a number of phones is what gives this feature its. A common
scenario in SIP is for a number of business telephones to share a
single or a small number of Address of Record (AOR) URIs. In
addition, an AOR can have multiple appearances on a single UA in addition, an AOR can have multiple appearances on a single UA in
terms of the user interface. The appearance number relates to the terms of the user interface. The appearance number relates to the
user interface for the telephone - typically each appearance or an user interface for the telephone - typically each appearance or an
AOR has a visual display (lamp that can change color or blink) and a AOR has a visual display (lamp that can change color or blink) and a
button (used to select the appearance). The telephony concept of button (used to select the appearance). The telephony concept of
line aappearance is still relevant to SIP due to the user interface line appearance is still relevant to SIP due to the user interface
considerations. It is important to keep the appearance number considerations. It is important to keep the appearance number
construct because: construct because:
1. Human users are used to the concept and will expect it in 1. Human users are used to the concept and will expect it in
replacement systems (e.g. an overhead page announcement says "Joe replacement systems (e.g. an overhead page announcement says "Joe
pickup line 3"). pickup line 3").
2. It is a useful structure for user interface representation. 2. It is a useful structure for user interface representation.
In this document, we will use the term "appearance" rather than "line In this document, we will use the term "appearance" rather than "line
appearance" since SIP does not have the concept of lines. Note that appearance" since SIP does not have the concept of lines. Note that
skipping to change at page 5, line 36 skipping to change at page 5, line 38
3. Usage Scenarios 3. Usage Scenarios
The following examples are common applications of the Shared The following examples are common applications of the Shared
Appearances feature and are mentioned here as informative use cases. Appearances feature and are mentioned here as informative use cases.
All these example usages can be supported by the Shared Appearances All these example usages can be supported by the Shared Appearances
feature described in this document. The differences relate to the feature described in this document. The differences relate to the
user interface considerations of the device. user interface considerations of the device.
3.1. Executive/Assistant Arrangement 3.1. Executive/Assistant Arrangement
The appearances on the executive's UA may also appear on the The appearances on the executive's UA also appear on the assistant's
assistant's UA. The assistant may answer incoming calls to the UA. The assistant may answer incoming calls to the executive and
executive and then place the call on hold for the executive to pick then place the call on hold for the executive to pick up. The
up. The assistant can always see the state of all calls on the assistant can always see the state of all calls on the executive's
executive's UA. UA. An assistant can make outgoing calls using the identity of
either the executive or their own.
3.2. BLA Call Group 3.2. Call Group
Users with similar business needs or tasks can be assigned to Users with similar business needs or tasks can be assigned to
specific groups and share the line appearances of each other on each specific groups and share the line appearances of each other on each
others SIP telephony devices. For example, an IT department staff of others SIP telephony devices. For example, an IT department staff of
five might answer a help line which has three appearances on each five might answer a help line which has three appearances on each
phone in the IT work area. A call answered on one phone can be put phone in the IT work area. A call answered on one phone can be put
on hold and picked up on another phone. A shout or an IM to another on hold and picked up on another phone. A shout or an IM to another
staff member can result in them taking over a call on a particular staff member can result in them taking over a call on a particular
appearance. Another phone can request to be added to an appearance appearance. Another phone can request to be added to an appearance
resulting in a conference call. resulting in a conference call.
skipping to change at page 7, line 26 skipping to change at page 7, line 29
REQ-12 The mechanism must not allow UAs outside the group to select REQ-12 The mechanism must not allow UAs outside the group to select
or manipulate appearance numbers. or manipulate appearance numbers.
REQ-13 For privacy reasons, there must be a mechanism so that REQ-13 For privacy reasons, there must be a mechanism so that
appearance information is not leaked outside the group of UAs. (e.g. appearance information is not leaked outside the group of UAs. (e.g.
"So who do you have on line 1?") "So who do you have on line 1?")
REQ-14 The mechanism must support a way for UAs to request REQ-14 The mechanism must support a way for UAs to request
exclusivity on a line appearance. Exclusivity means that the UA exclusivity on a line appearance. Exclusivity means that the UA
requesting it desires to have a private conversation with the requesting it desires to have a private conversation with the
external party and other UAs must not be allowed to barge-in. external party and other UAs must not be allowed to be joined or
Exclusivity may be requested at the start of an incoming or outgoing taken. Exclusivity may be requested at the start of an incoming or
session or during the session. An exclusivity request may be outgoing session or during the session. An exclusivity request may
accepted or rejected by the entity providing the SA service. be accepted or rejected by the entity providing the shared appearance
Therefore, the mechanism must provide a way of communicating the service. Therefore, the mechanism must provide a way of
result back to the requester UA. communicating the result back to the requester UA.
REQ-15 The mechanism should support a way for a UA to select a REQ-15 The mechanism should support a way for a UA to select a
particular appearance number for outgoing requests prior to sending particular appearance number for outgoing requests prior to sending
the actual request. This is often called seizure. the actual request. This is often called seizure.
REQ-16 The mechanism should support a way for a UA to select a REQ-16 The mechanism should support a way for a UA to select 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 a ringdown feature is combined with shared time. This is needed when a ringdown feature is combined with shared
appearances - in this case, seizing the line is the same thing as appearances - in this case, seizing the line is the same thing as
dialing. dialing.
OPEN ISSUE: This requirement is no longer supported by the proposed
solution. Is this OK?
5. Normative Description 5. Normative Description
This section normatively describes the SA feature extensions. This section normatively describes the shared appearance feature
extensions. For a discussion of various approaches to implement this
feature, see Appendix B.
5.1. Implementation 5.1. Implementation
Many of the requirements for this service can be met using standard Many of the requirements for this service can be met using standard
SIP mechanisms such as: 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.
skipping to change at page 8, line 22 skipping to change at page 8, line 29
- The use of a State Agent for the Dialog Package meets REQ-5. - The use of a State Agent for the Dialog Package meets REQ-5.
REQ-6 suggests the need for an entity which manages the appearance REQ-6 suggests the need for an entity which manages the appearance
resource. Just as conferencing systems commonly have a single point resource. Just as conferencing systems commonly have a single point
of control, known as a focus, a Shared Appearance group has a single of control, known as a focus, a Shared Appearance group has a single
point of control of the appearance shared resource. This is defined point of control of the appearance shared resource. This is defined
as an Appearance Agent for a group. While an Appearance Agent can be as an Appearance Agent for a group. While an Appearance Agent can be
part of a centralized server, it could also be co-resident in a part of a centralized server, it could also be co-resident in a
member User Agent who has taken on this functionality for a group. member User Agent who has taken on this functionality for a group.
The Appearance Agent learns the group state either by subscribing to The Appearance Agent learns the group state either dialog state
the dialog state of each member UA individually or by dialog state
publications from members. publications from members.
While the appearance resource could be managed co-operatively by a While the appearance resource could be managed co-operatively by a
group of UAs without any central control, this is not discussed in group of UAs without any central control, this is not discussed in
this draft, but instead is left as a research project for future this draft, but instead is left as a research project for future
standardization. It is also possible that the Appearance Agent logic standardization. It is also possible that the Appearance Agent logic
could be distributed in all UAs in the group. For example, rules could be distributed in all UAs in the group. For example, rules
that govern assigning appearance numbers for incoming requests (e.g. that govern assigning appearance numbers for incoming requests (e.g.
lowest available appearance number) and rules for contention handling lowest available appearance number) and rules for contention handling
(e.g. when two UAs request the use of the same appearance number, (e.g. when two UAs request the use of the same appearance number,
hash dialog identifiers and compare with the lowest hash winning) hash dialog identifiers and compare with the lowest hash winning)
would need to be defined and implemented. would need to be defined and implemented.
REQs 6-13 can be implemented using a number of approaches, as
discussed in the following sections.
Figure 1 illustrates the SIP components involved in supporting these Figure 1 illustrates the SIP components involved in supporting these
common requirements of the Shared Appearance using standard SIP common requirements of the Shared Appearance using standard SIP
messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH. messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
+----------------------------+ +----+ +----------------------------+ +----+
| | | | | | | |
| Appearance Agent | | UA | | Appearance Agent | | UA |
| | | | | | | |
+----------------------------+ +----+ +----------------------------+ +----+
^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE | ^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE |
skipping to change at page 9, line 37 skipping to change at page 9, line 37
| | ^ ^ ^ ^ | | | | ^ ^ ^ ^ | |
| | | | | | | | | | | | | | | |
| +----+ | | | | | | +----+ | | | | |
| | | +--------------------------------------+ | | | | +--------------------------------------+ |
| +----+-------------------------------------------+ | +----+-------------------------------------------+
| | 8) INVITE | | 8) INVITE
+--------------+ sip:alice@example.com +--------------+ sip:alice@example.com
5-7) SUBSCRIBE and/or PUBLISH 5-7) SUBSCRIBE and/or PUBLISH
(Event:dialog) (Event:dialog)
OPEN ISSUE: This figure still shows the use of the registration event
package by the Appearance Agent - do we still need this?
Figure 1. Figure 1.
The next section discusses normal SIP operations used to implement The next section discusses normal SIP operations used to implement
parts of the shared appearance feature. parts of the shared appearance feature.
1. The Appearance Agent SUBSCRIBES to the registration event package 1. The Appearance Agent SUBSCRIBEs to the registration event package
as outlined in [RFC3680] for contacts registered to the group as outlined in [RFC3680] for contacts registered to the group
AOR. Thus, it has knowledge of all User Agents registered AOR. Thus, it has knowledge of all User Agents registered
against the AOR at any point of time. against the AOR at any point of time.
2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and, 2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and,
after authentication, register against the same AOR (e.g., after authentication, register against the same AOR (e.g.,
sip:alice@example.com). sip:alice@example.com).
3. Each registration is stored in the Location Service. 3. Each registration is stored in the Location Service.
4. The registrar notifies the Appearance Agent of successful 4. The registrar notifies the Appearance Agent of successful
registration at each UA. registration at each UA.
5. UAs PUBLISH their dialog state to the State Agent in the 5. UAs PUBLISH their dialog state to the State Agent in the
Appearance Agent. Appearance Agent.
6. The UAs SUBSCRIBE to the Appearance Agent for the state of all 6. The UAs SUBSCRIBE to the Appearance Agent for the state of all
dialogs as defined in [RFC3265] . The Request-URI of the dialogs as defined in [RFC3265] . The Request-URI of the
SUBSCRIBE could be either the AOR of the group, the Contact URI SUBSCRIBE could be either the AOR of the group or a provisioned
information it received in the incoming subscription from the URI.
Appearance Agent, or a provisioned URI.
7. The UAs PUBLISH their dialog information to the Appearance Agent 7. The UAs PUBLISH their dialog information to the Appearance Agent
every time their dialog state changes (i.e. receive an INVITE, every time their dialog state changes (i.e. send an INVITE, enter
enter alerting state, answer a call, terminate a call, generate alerting state, answer a call, terminate a call, etc.), pickups
an INVITE, etc.) or joins a call, or seizes/selects an appearance.
8. Forking Proxy forks an incoming INVITE for the AOR address to the 8. The Forking Proxy forks an incoming INVITE for the AOR address to
registered user agents. the registered user agents.
The User Agents in the group could SUBSCRIBE to each other and NOTIFY
dialog state events, but in a large group the User Agents have to
manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
Agent in the Appearance Agent helps in managing large groups better.
Further, the State Agent can filter dialog state events and NOTIFY
User Agents of the dialog state events which are required for the
application or feature. The State Agent can also SUBSCRIBE to dialog
state events with filters to reduce the number of NOTIFY messages
exchanged between the State Agent and the user agents in the group.
This allows a group of N UAs to each only establish a pair of dialog
state subscriptions (one in each direction) to learn the dialog state
of all other group members. This results in 2N total subscriptions
for the entire group. A full mesh of subscriptions without a state
agent would result in N(N-1) total subscriptions.
The Appearance Agent can select the appearance number for an incoming The Appearance Agent can select the appearance number for an incoming
call call
OPEN ISSUE: Do we want to define another mode of operation in which OPEN ISSUE: Do we want to define another mode of operation in
UAs only PUBLISH to seize a line appearance? This assumes the which UAs only PUBLISH to seize an appearance? This assumes the
Appearance Agent already knows about all dialogs related to the AOR Appearance Agent already knows about all dialogs related to the
and could publish that information to the UAs in the SA group. This AOR and could publish that information to the UAs in the shared
approach would simply UA operation and cleanly resolve some race appearance group. This approach would simply UA operation and
conditions. Should we define this mode in a separate draft? reduce the number of SIP messages sent and received. If a
different SIP option tag was defined for this server mode, an
Appearance Agent could indicate support for this feature by
including it in a Supported in NOTIFYs. The UA could also include
the option tag in a Require header field in the initial PUBLISH.
A 200 OK response to the PUBLISH would confirm that the UA does
not need to PUBLISH any more state for the dialog.
5.2. SA Dialog Package Extensions 5.2. Shared Appearance Dialog Package Extensions
This specification defines three new elements as extensions to the This specification defines four new elements as extensions to the SIP
SIP Dialog Event package [RFC3265] . The schema is defined in Dialog Event package [RFC3265]. The schema is defined in Section 6.
Section 7. The elements are <appearance>, <exclusive>;, and <joined- The elements are <appearance>, <exclusive>, <joined-dialog>, and
dialog>. All three elements are sub-elements of the <dialog> <replaced-dialog> which are sub-elements of the <dialog> element.
element.
5.2.1. The <appearance> element 5.2.1. The <appearance> element
The <appearance> element is used convey the appearance number. The The <appearance> element is used convey the appearance number. The
appearance number is a non-negative integer. When sent in a appearance number is a non-negative integer. When sent in a
notification in state Trying to the Appearance Agent, it is used to notification 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.
5.2.2. The <exclusive> element 5.2.2. The <exclusive> element
The <exclusive> element is a boolean used 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 SA systems only allow call pickup when the call is on hold. In some shared appearance systems only allow call pickup when the call
this case, the <exclusive> element should be used to explicitly is on hold. In this case, the <exclusive> element should be used to
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. Although a UA
may set exclusive to true, the UA must still be ready to reject an may set exclusive to true, the UA must still be ready to reject an
INVITE Join relating to this dialog. Also, an INVITE Replaces might INVITE Join relating to this dialog. Also, an INVITE Replaces might
be sent to the non-SA UA to take the call. For this reason, a UA MAY be sent to the non-shared appearance UA to take the call. For this
also not report full dialog identifier information to the Appearance reason, a UA MAY also not report full dialog identifier information
Agent for calls set to exclusive. If these dialog identifiers have to the Appearance Agent for calls set to exclusive. If these dialog
already been shared with the Appearance Agent, the UA could send an identifiers have already been shared with the Appearance Agent, the
INVITE Replaces to change them and then not report the new ones to UA could send an INVITE Replaces to change them and then not report
the Appearance Agent. 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 Replace 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.
5.2.3. The <joined-dialog> element 5.2.3. The <joined-dialog> element
The <joined-dialog> element is used convey dialog identifiers of any The <joined-dialog> element is used convey dialog identifiers of any
other dialogs which are joined (mixed or bridged) with the dialog. other dialogs which are joined (mixed or bridged) with the dialog.
Only the UA which is performing the actual media mixing should Only the UA which is performing the actual media mixing should
include this element in notifications to the Appearance Agent. Note include this element in notifications to the Appearance Agent. Note
that this element should still be used even when the Join header that this element should still be used even when the Join header
field was not used to join the dialogs. For example, two separate field was not used to join the dialogs. For example, two separate
dialogs on a UA could be joined without any SIP call control dialogs on a UA could be joined without any SIP call control
operations. The UA would report this using this header field. operations. Joined dialogs will share the same appearance number.
5.2.4. The <replaced-dialog> element
The <replaced-dialog> element is used convey dialog identifiers of
any other dialogs which will be or have been replaced with this
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
the replacing dialog. Replaced dialogs will share the same
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 SA extensions and the the dialog state package [RFC4235] with the shared appearance
"sa" dialog event package parameter defined in this draft. extensions and the 'shared' dialog event package parameter defined in
this draft.
User Agents MUST use the extended package in conjunction with PUBLISH User Agents MUST use the dialog package extensions in Section 5.2
[RFC3903] to send local status to the Appearance Agent, and in along with the PUBLISH [RFC3903] method to send local status to the
conjunction with SUBSCRIBE and NOTIFY [RFC3265] to learn the status Appearance Agent, and SUBSCRIBE [RFC3265] to the Appearance Agent to
or other User Agents. The publication URI is either a provisioned learn the status of other User Agents in the group. SUBSCRIBE
value or the username 'appearance-agent'. For example, a UA in the requests MUST include the 'shared' Event package parameter.
domain of example.com would publish dialog state to
sip:appearance-agent@example.com
OPEN ISSUE: Do we need to specify a publish URI or should it be only The presence of the 'shared' Event package parameter in the
by provisioning? Should a UA be able to publish to its own URI for SUBSCRIBE tells the Appearance Agent that this UA supports this
this? specification.
PUBLISH requests SHOULD include the 'shared' Event package parameter,
except when specified otherwise. The publication URI is either a
provisioned value or the default username 'appearance-agent'. For
example, a UA in the domain of example.com would publish dialog state
to sip:appearance-agent@example.com.
OPEN ISSUE: Should a UA be able to publish to the group AOR?
User Agents SHOULD support sending and receiving an INVITE with a User Agents SHOULD support sending and receiving an INVITE with a
Replaces [RFC3891] header to allow the Call Pickup operation. User Replaces [RFC3891] header to allow the Call Pickup operation. User
Agents MUST support sending an INVITE a Join [RFC3911] header to Agents MUST support sending an INVITE a Join [RFC3911] header to
initiate bridging. User Agents MUST support receiving an INVITE with initiate bridging. User Agents MUST support receiving an INVITE with
a Join header, though they are not obligated to support bridging of a Join header, though they are not obligated to support bridging of
calls, either through policy, preference, or implementation calls, either through policy, preference, or implementation
limitations such as bandwidth or hardware constraints. limitations such as bandwidth or hardware constraints.
When publishing dialog package information, a UA MUST include all When publishing dialog package information, a UA MUST include all
dialog identification available at the time of publication, with the dialog identification available at the time of publication, with the
exception that a UA may omit information if it wishes to prevent exception that a UA may omit information if it wishes to prevent
other UAs from joining or picking up a call. Dialog identification other UAs from joining or picking up a call. Dialog identification
includes local and remote target URIs, call-id, to-tag, and from-tag. includes local and remote target URIs, call-id, to-tag, and from-tag.
When calls are placed on hold, the "+sip.rendering=no" feature tag When calls are placed on hold, the "+sip.rendering=no" feature tag
MUST be included in dialog package notifications. MUST be included in dialog package notifications.
There are two exceptions to the requirement for seizing an appearance The accurate rendering of the idle/active/alerting/hold state of
before sending an INVITE. One is an emergency call, which should other UAs in the group is an important part of the shared
proceed regardless of the status of PUBLISH transaction. This appearance feature.
requirement applies to both clients and servers implementing this
feature. The other is when the INVITE is an attempt to bridge or A UA SHOULD render the appearance number to the user or display
take a call (i.e. contains Join or Replaces with a dialog identifier appearance status information to the user in a way that preserves the
of another member of the SA group). In this case, the INVITE Join or appearance order.
Replaces should be sent without selecting an appearance. After the
INVITE succeeds, the PUBLISH MUST be sent, reusing the appearance A UA SHOULD send dialog package PUBLISH requests for the following
number of the dialog that has been bridged or taken. events:
1. When going selecting an appearance number (i.e. going "off-hook"
if the UA's user interface uses this metaphor),
2. When sending an outgoing INVITE,
3. When receiving a 18x response,
4. When sending or receiving a 2xx response to an INVITE,
5. When sending or receiving a BYE
A UA SHOULD NOT send dialog package PUBLISH requests when receiving
an incoming INVITE or when sending a 18x response.
A large group of UAs publishing in these conditions when an INVITE
has forked will generate significant dialog package PUBLISH and
NOTIFY traffic that actually conveys no new information to other
UAs in the group.
UAs can tell that a set of dialogs are joined (bridged or mixed) UAs can tell that a set of dialogs are joined (bridged or mixed)
together by the presence of one or more <joined-dialog> elements together by the presence of one or more <joined-dialog> elements
containing other SIP dialog identifiers. containing other SIP dialog identifiers.
Prior to placing an outbound call, UAs may select or "seize" an Prior to placing an outbound call, UAs may select or "seize" an
appearance number by sending a PUBLISH to the Appearance Agent with appearance number by sending a PUBLISH to the Appearance Agent
an <appearance> identifying the appearance number selected. In identifying the appearance number selected in an <appearance>
traditional telephony terms, this corresponds to "going off hook" element. In traditional telephony terms, this corresponds to "going
with an analog telephone. Note that when a UA selects an appearance off hook" with an analog telephone. Note that when a UA selects an
prior to establishment of a dialog, not all dialog information will appearance prior to establishment of a dialog, not all dialog
be available. In particular, when a UA publishes an attempt to information will be available. In particular, when a UA publishes an
select an appearance prior to knowing the destination very minimal attempt to select an appearance prior to knowing the destination very
dialog information may be available. minimal dialog information may be available. For example, a minimal
set might be just the local target URI for the call. Only after
receiving the 200 OK to the PUBLISH SHOULD the INVITE be sent. If no
dialog identification information was present in the initial PUBLISH,
the UA MUST PUBLISH again after receiving the 100 Trying.
For an emergency call, a UA MUST never wait for a confirmed seizure
before sending an INVITE. Instead, the emergency call MUST proceed
regardless of the status of PUBLISH transaction. This requirement
applies to both clients and servers implementing this feature.
A UA that does not need to select a particular appearance number (or A UA that does not need to select 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. The Appearance Agent would select an available outbound call. The UA placing the call SHOULD PUBLISH after
appearance and notify all subscribed UAs of the selection. The UA receiving a 1xx response to the INVITE. If the appearance number is
placing the call then publishes the use of this appearance number. not known, the 'appearance' element is not included in the
publication and the 'shared' event package parameter SHOULD NOT be
included. Once the appearance number is known, it should be included
in all publications for this dialog and the 'shared' event package
parameter included in the PUBLISH.
If an INVITE is sent and no appearance number is available, the proxy The publication without the 'shared' event package parameter looks
would reject the INVITE with a suitable response code and perhaps a identical to a publication from a UA which does not understand the
header field indication. shared appearance feature. In both these cases, the Appearance
Agent will assign an appearance number for this dialog.
A UA wanting to place a call but not have an appearance number
assigned publishes before sending the INVITE without an 'appearance'
element but with the 'shared' event package parameter present. If
the Appearance Agent policy does not allow calls without an assigned
appearance number, a 409 Conflict response will be received, and the
UA will republish either selecting an appearance number or without
one, in which case the Appearance Agent will assign one.
The publication with 'shared' event package parameter allows the
Appearance Agent to determine that no appearance number should be
allocated.
OPEN ISSUE: The only use case we have for this is consultation
hold. Are there other use cases? Is that use case important
enough or should we remove this mechanism?
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
in the shared appearance group), the appearance number of the joined
or replaced call SHOULD be used. In this case, the PUBLISH MUST be
sent prior to sending the INVITE. The publication MUST contain the
appearance number of the dialog to be joined or replaced and the
dialog identifier in the 'joined-dialog' or 'replaced-dialog'
elements. The INVITE is sent after the receipt of a 200 OK to the
PUBLISH.
For inbound calls which contain a reference to an appearance number For inbound calls which contain a reference to an appearance number
in the INVITE, a UA MUST PUBLISH the use of an appearance number in the INVITE, a UA MUST PUBLISH the use of an appearance number
after it responds with a 2xx to establish a dialog. A UA SHOULD NOT after it responds with a 2xx to establish a dialog.
PUBLISH the use of an appearance number for incoming requests which
are in the early state or which are rejected with 4xx, 5xx or 6xx
responses, as this would create excessive traffic when a large number
of UAs are sharing an appearance.
The dialog state package defined in [RFC4235] defines the set of
messages that MAY be provided by a UA to publish state information of
dialogs.
A UA should only register against the AOR if it is likely the UA will A UA SHOULD register against the AOR only if it is likely the UA will
be answering incoming calls. If the UA is mainly going to be be answering incoming calls. If the UA is mainly going to be
monitoring the status of the SA group calls and picking or joining monitoring the status of the shared appearance group calls and
calls, the UA SHOULD only subscribe to the Appearance Agent and not picking or joining calls, the UA SHOULD only subscribe to the
register against the AOR. Appearance Agent and not register against the AOR.
All subscribed UAs will received NOTIFYs of Trying state for
incoming INVITEs.
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 dialog package XML element dialog id (NOT the SIP dialog
identifier consisting of the Call-ID, To tag, and From tag) is used
for partial update processing. RFC 4235 only requires the dialog id
be unique for the UA, not unique across all UAs associated with the
same AOR. As a result, is possible that two UAs in a SA group might
choose the same XML element dialog id for different dialogs. If this
is the case, the Appearance Agent, acting as the dialog package event
state compositor may need to produce different notification documents
for the UAs that have conflicting dialog package XML element dialog
ids.
The Appearance Agent MUST support the appearance dialog package The Appearance Agent MUST support the appearance dialog package
extensions defined in this specification. extensions defined in Section 5.2. The Appearance Agent MUST support
publications and subscriptions for this event package.
Even in trivial deployments of two shared appearance enabled user The Appearance Agent MUST have a way of discovering the dialog
agents, race conditions can exist when both user agents attempt to identifiers of incoming INVITEs. The Appearance Agent MUST allocate
utilize an appearance simultaneously (i.e. when the NOTIFY messages, an appearance number for all incoming calls and send immediate
that each user agent sends to the other, are active within the notifications to the UAs subscribed to the shared group AOR. An
network during an overlapping time period). The Appearance Agent can Appearance Agent MAY assign an appearance number to an INVITE if a
use any policy deemed necessary to resolve races and ensure no two PUBLISH is not received for the dialog within a reasonable period of
user agents are not allocated the same appearance number at the same time. If the appearance group has non-shared appearance UAs, the
time. Appearance Agent MUST allocate appearance numbers for INVITEs sent by
those UAs.
Appearance Agents are responsible for resolving conflicts in the Note that in general, the Appearance Agent makes appearance
appearance resource. If a UA requests the use of an appearance allocation decisions based on publications rather than on INVITEs.
number that is in use by another UA, the Appearance Agent will
respond based on the presence of the selection attribute in the
<appearance> element as described in the previous section.
In the case where a UA is bridging two calls, the Appearance Agent An Appearance Agent receiving a PUBLISH with an appearance number
may receive dialog package PUBLISHes that contain multiple dialogs checks to make sure the publication is valid. An appearance number
with the same appearance number. This is valid and does not can be assigned to only one dialog unless there is a 'joined-dialog'
represent appearance number contention. or 'replaced-dialog' element indicating that the dialog will be/has
been replaced or joined. A 409 Conflict response is returned if the
chosen appearance number is invalid, and an immediate NOTIFY should
be sent to the UA.
A critical aspect for reliable operation of this feature is the An Appearance Agent receiving a PUBLISH without an appearance number
ability for all user agents in the BLA group to recover from network and without the 'shared' event package parameter checks to see if the
failures caused at a single UA. For example, one of the user agents dialog already has an appearance number assigned to it. If it does,
in the BLA group may have answered an incoming call, notified the it replies with 200 OK and updates the dialog information. If it
dialog state to other members and then experienced a network outage. does not, the Appearance Agent assigns an available appearance
The calling UA could have detected the same (using RTP or some other number, returns a 200 OK and NOTIFYs the other UAs in the group.
means) and could have hung up. However, none of the other user
agents in the BLA group would get notification of this change in Note that this case could be a shared appearance unaware UA or a
dialog state and their BLA appearances could stay out of sync for a UA that does not care what appearance number is used for the
long time; depending on when the network is restored, or when the dialog.
Appearance Agent attempts to refresh its dialog-state subscription
with the failed UA. To recover from such a failure, UAs MUST PUBLISH An Appearance Agent receiving a PUBLISH without an appearance number
with a shorter expiration (expiration interval not smaller than 300 but with the 'shared' event package parameter present interprets this
seconds is RECOMMENDED) following the notification of a "confirmed" as a request by the UA to not assign an appearance number. If the
dialog or when a Appearance Agent honors a "trying" for call Appearance Agent policy does not allow this, a 409 Conflict response
origination, with the user agents that notified it of this is returned. If policy does allow this, a 200 OK response is
information. returned and no appearance number is allocated.
The Appearance Agent controls the rate of dialog state publication
using the Expires header field in 200 OK responses to PUBLISH
requests. The Appearance Agent MAY vary the expiration interval
depending on the type of publication, or, an Appearance Agent MAY
just use the same interval for all publications. For publications of
trying, alerting, or connected state, an interval of 3 minutes is
RECOMMENDED.
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 and no appearance number is available, the proxy
MAY reject the INVITE with a 403 Forbidden response code.
6. XML Schema Definition 6. XML Schema Definition
The 'appearance' and 'exclusive' elements are defined within a new The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive'
XML namespace URI. This namespace is elements are defined within a new XML namespace URI. This namespace
"urn:ietf:params:xml:ns:sa-dialog-info". The schema for these is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these
elements is: elements is:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info-info" targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info-info"
xmlns="urn:ietf:params:xml:ns:sa-dialog-info" xmlns="urn:ietf:params:xml:ns:sa-dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<xs:element name="joined-dialog" minOccurs="0" maxOccurs="unbounded"> <xs:element name="joined-dialog" minOccurs="0" maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:attribute name="call-id" type="xs:string" <xs:attribute name="call-id" type="xs:string"
use="mandatory"/> use="mandatory"/>
<xs:attribute name="local-tag" type="xs:string" <xs:attribute name="local-tag" type="xs:string"
use="mandatory"/> use="mandatory"/>
<xs:attribute name="remote-tag" type="xs:string" <xs:attribute name="remote-tag" type="xs:string"
use="mandatory"/> use="mandatory"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="replaced-dialog" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="mandatory"/>
<xs:attribute name="local-tag" type="xs:string"
use="mandatory"/>
<xs:attribute name="remote-tag" type="xs:string"
use="mandatory"/>
</xs:complexType>
</xs:element>
<xs:element name="appearance" minOccurs="0" maxOccurs="1"> <xs:element name="appearance" minOccurs="0" maxOccurs="1">
<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>
skipping to change at page 17, line 5 skipping to change at page 19, line 16
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. Thought should also be given to that the order should be consistent. Thought should also be given to
how an appearance number that has no call associated with it should how an appearance number that has no call associated with it should
be rendered to the user. These devices can typically make calls be rendered to the user. These devices can typically make calls
without waiting for confirmation from the Appearance Agent on the without waiting for confirmation from the Appearance Agent on the
appearance number. appearance number.
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 SA group, and is assigned an appearance 1. A call arrives at the shared appearance group, and is assigned an
number of 0. All UAs should be able to render to the user the appearance number of 0. All UAs should be able to render to the
arrival of this call. user the arrival of this call.
2. Another call arrives at the SA group, and is assigned an 2. Another call arrives at the shared appearance group, and is
appearance number of 1. The single appearance UA should not assigned an appearance number of 1. The single appearance UA
present this call to the user. Other user agents should have no should not present this call to the user. Other user agents
problems presenting this call distinctly from the first call. should have no problems presenting this call distinctly from the
first call.
3. The first call clears, releasing appearance number "0". The 3. The first call clears, releasing appearance number "0". The
single appearance UA should now be indicating no calls since it single appearance UA should now be indicating no calls since it
is unable to manage calls other than on the first appearance. is unable to manage calls other than on the first appearance.
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 appearnce UAs should continue to indicate the the user. Multiple appearnce UAs should continue to indicate the
presence of the second call, and should also ensure that 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 7.2. Call State Rendering
UAs that implement the SA feature typically have a user interface UAs that implement the shared appearance feature typically have a
that provides the state of other appearances in the group. As dialog user interface that provides the state of other appearances in the
state NOTIFYs from the Appearance Agent are processed, this group. As dialog state NOTIFYs from the Appearance Agent are
information can be rendered. Even the simplest user interface processed, this information can be rendered. Even the simplest user
typically has three states: idle, active, and hold. The idle state, interface typically has three states: idle, active, and hold. The
usually indicated by lamp off, is indicated for an appearance when idle state, usually indicated by lamp off, is indicated for an
the appearance number is not associated with any dialogs, as reported appearance when the appearance number is not associated with any
by the Appearance Agent. The active state, usually indicated by a dialogs, as reported by the Appearance Agent. The active state,
lamp on, is indicated by an appearance number being associated with usually indicated by a lamp on, is indicated by an appearance number
at least one dialog, as reported by the Appearance Agent. The hold being associated with at least one dialog, as reported by the
state, often indicated by a blinking lamp, means the call state from Appearance Agent. The hold state, often indicated by a blinking
the perspective of the UA in the SA group is hold. This can be lamp, means the call state from the perspective of the UA in the
determined by the presence of the "sip+rendering=no" feature tag shared appearance group is hold. This can be determined by the
[RFC3840] with the local target URI. Note that the hold state of the presence of the "sip+rendering=no" feature tag [RFC3840] with the
remote target URI is not relevant to this display. For joined local target URI. Note that the hold state of the remote target URI
dialogs, the state is rendered as hold only if all local target URIs is not relevant to this display. For joined dialogs, the state is
are indicated with the "sip+rendering=no" feature tag. rendered as hold only if all local target URIs are indicated with the
"sip+rendering=no" feature tag.
8. Interop with non-SA UAs 8. Interop with non-Shared Appearance UAs
It is desirable to allow a basic UA that does not directly support SA EDITOR'S NOTE: This section needs to be reviewed in light of recent
to be part of a SA group. To support this the Proxy must collaborate changes in the specification.
with the Appearance Agent. This is not required in the basic SA
architecture, consequently SA interop with non-SA UAs will not be
available in all SA deployments.
First, a UA which does not support dialog events or the SA feature It is desirable to allow a basic UA that does not directly support
will be discussed. Then, a UA which does support dialog events but shared appearance to be part of a shared appearance group. To
not the SA feature will be discussed. support this the Proxy must collaborate with the Appearance Agent.
This is not required in the basic shared appearance architecture,
consequently shared appearance interop with non-shared appearance UAs
will not be available in all shared appearance deployments.
First, a UA which does not support dialog events or the shared
appearance feature will be discussed. Then, a UA which does support
dialog events but not the shared appearance feature will be
discussed.
8.1. Appearance Assignment 8.1. Appearance Assignment
A UA that has no knowledge of appearances must have appearance A UA that has no knowledge of appearances must have appearance
numbers assigned by the Appearance Agent for both incoming and numbers assigned by the Appearance Agent for both incoming and
outgoing calls. If the non-SA UA does not support Join or Replaces, outgoing calls. If the non-shared appearance UA does not support
all dialogs could be marked "exclusive" to indicate that these Join or Replaces, all dialogs could be marked "exclusive" to indicate
options are not available. that these options are not available.
OPEN ISSUE: How can an Appearance Agent know that a given UA does not
support the feature? Do we need a SIP option tag for this purpose?
Do we need to be able to correlate a registration with a
subscription?
8.2. Appearance Release 8.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-SA aware UA, the Appearance Record-Routes for dialogs from the non-shared appearance aware UA,
Agent will know about the state of dialogs including hold, etc. This the Appearance Agent will know about the state of dialogs including
information could be determined from inspection of INVITE and re- hold, etc. This information could be determined from inspection of
INVITE messages and added to the dialog information conveyed to other INVITE and re-INVITE messages and added to the dialog information
UAs. conveyed to other UAs.
8.3. UAs Supporting Dialog Events but Not SA 8.3. UAs Supporting Dialog Events but Not Shared Appearance
Interoperability with UAs which support dialog events but not the SA Interoperability with UAs which support dialog events but not the
feature is more straightforward. As before, all appearance number shared appearance feature is more straightforward. As before, all
assignment must be done by the Appearance Agent. This type of UA appearance number assignment must be done by the Appearance Agent.
will be detected by the Appearance Agent by the absence of the ma This type of UA will be detected by the Appearance Agent by the
event parameter in SUBSCRIBE or PUBLISH messages. The Appearance absence of the ma event parameter in SUBSCRIBE or PUBLISH messages.
Agent can include appearance information in NOTIFYs - this UA will The Appearance Agent can include appearance information in NOTIFYs -
simply ignore this extra information. This type of UA will ignore this UA will simply ignore this extra information. This type of UA
appearance number limitations and may attempt to Join or Replace will ignore appearance number limitations and may attempt to Join or
dialogs marked exclusive. As a result, the Proxy or UAs may need to Replace dialogs marked exclusive. As a result, the Proxy or UAs may
reject such requests. need to reject such requests.
The need for close cooperation between the Proxy and the Appearance The need for close cooperation between the Proxy and the Appearance
Agent is not needed as the Appearance Agent will learn about all Agent is not needed as the Appearance Agent will learn about all
dialogs from the UA itself. dialogs from the UA itself.
9. Provisioning Considerations 9. Provisioning Considerations
TBD. TBD.
10. Example Message Flows 10. 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. descriptions are non-normative.
EDITOR'S NOTE: These flows need to be gone over closely to make sure
they reflect the latest protocol design.
10.1. Registration and Subscription 10.1. Registration and Subscription
Bob and Alice are in an appearance group identified by Alice's AOR. Bob and Alice are in an appearance group identified by Alice's AOR.
Bob REGISTERs using contact sip:bob@ua2.example.com. Furthermore, Bob REGISTERs using contact sip:bob@ua2.example.com. Alice REGISTERs
Bob REGISTERs his primary address with contact sip: with contact sip:alice@ua1.example.com.
bob@ua2.example.com. Alice REGISTERs with contact
sip:alice@ua1.example.com.
The Appearance Agent subscribes to dialog states of the SA AOR (i.e., User Agents for Alice and Bob subscribe to the dialog package for the
sip:alice@example.com) at the User Agents for Alice and Bob. Message appearance AOR and publish dialog state to the Appearance Agent.
exchange between the Registrar, Appearance Agent, Alice, and Bob are Message exchanges between the Registrar, Appearance Agent, Alice, and
shown below. The call flow examples below do not show challenging of Bob are shown below. The call flow examples below do not show the
subscriptions or notifications. It should be noted that for security authentication of subscriptions, publications, and notifications. It
purposes, all subscriptions must be authorized before the same is should be noted that for security purposes, all subscriptions must be
accepted. authorized before the same is accepted.
Also note that registrations and subscriptions must all be refreshed
by Alice at intervals determined by the expiration intervals returned
by the Registrar or Appearance Agent.
Registrar Appearance Agent Alice Registrar Appearance Agent Alice
| | | | | |
| | | | | |
|<--------------------------- REGISTER F1<| |<--------------------------- REGISTER F1<|
| | | | | |
|>F2 200 OK ----------------------------->| |>F2 200 OK ----------------------------->|
| | | | | |
| |<----- SUBSCRIBE F3<| | |<----- SUBSCRIBE F3<|
| | | | | |
| |>F4 202 Accepted -->| | |>F4 202 Accepted -->|
| | | | | |
| |>F5 NOTIFY -------->| | |>F5 NOTIFY -------->|
| | | | | |
| |<-------- OK 200 F6<| | |<-------- 200 OK F6<|
| | | | | |
Figure 2. Figure 2.
F1-F2: Alice registers AOR with contact: <sip:alice@ua1.example.com> F1-F2: Alice registers AOR with contact: <sip:alice@ua1.example.com>
F1 Alice ----> Registrar F1 Alice ----> Registrar
REGISTER sip:registrar.example.com SIP/2.0 REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:alice@example.com> To: <sip:alice@example.com>
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
User-Agent: ABC-UA/1.2.3
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=z9hG4bKfbf176ef7F1D5FA2
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
skipping to change at page 20, line 38 skipping to change at page 23, line 7
To: <sip:alice@example.com>;tag=1664573879820199 To: <sip:alice@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 also notifies Alice of the status. Appearance AOR. Appearance Agent also notifies Alice of the status.
F3 Alice ----> Appearance Agent F3 Alice ----> Appearance Agent
SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0 SUBSCRIBE sip:alice@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:sa@stateagent.example.com> To: <sip:alice@example.com>
CSeq: 1 SUBSCRIBE CSeq: 1 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Event: dialog Event: dialog;shared
User-Agent: ABC-UA/1.2.3
Accept: application/dialog-info+xml Accept: application/dialog-info+xml
Max-Forwards: 70 Max-Forwards: 70
Expires: 3700 Expires: 3700
Content-Length: 0 Content-Length: 0
F4 Appearance Agent ----> Alice F4 Appearance Agent ----> Alice
SIP/2.0 202 Accepted SIP/2.0 202 Accepted
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
CSeq: 1 SUBSCRIBE CSeq: 1 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:sa@stateagent.example.com>;tag=1636248422222257 To: <sip:alice@example.com>;tag=1636248422222257
Allow-Events: dialog Allow-Events: dialog
Expires: 3700 Expires: 3700
Contact: <sip:sa@stateagent.example.com> Contact: <sip:appearance-agent@stateagent.example.com>
Content-Length: 0 Content-Length: 0
F5 Appearance Agent ----> Alice F5 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:sa@stateagent.example.com>;tag=1636248422222257 From: <sip:alice@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@ua1.example.com Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
CSeq: 2 NOTIFY CSeq: 2 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog Event: dialog;shared
Subscription-State: active Subscription-State: active
Contact: <sip:sa@stateagent.example.com> Contact: <sip:appearance-agent@stateagent.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:alice@example.com"> entity="sip:alice@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 stateagent.example.com;branch=z9hG4bK1846984327225734 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734
From: <sip:sa@stateagent.example.com>;tag=1636248422222257 From: <sip:alice@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
CSeq: 2 NOTIFY CSeq: 2 NOTIFY
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Event: dialog Event: dialog;shared
User-Agent: ABC-UA/1.2.3
Content-Length: 0 Content-Length: 0
10.2. Appearance Selection for Outgoing Call 10.2. Appearance Selection for Incoming Call
In this scenario, Bob's UA sends out a dialog event NOTIFY with state In the call flow below Bob and Alice are in an appearance group.
(trying) selecting an appearance number. After receiving the NOTIFY Carol places a call to the appearance group AOR. The Appearance
from the Appearance Agent confirming the appearance number, Bob's UA Agent sends NOTIFYs to Alice and Bob telling them what appearance the
sends the INVITE to Carol and establishes a session. For brevity, call is using. Both Alice and Bob's devices are alerted of the
details of some of the messages are not included in the message incoming call. Bob answers the call. He then places Carol on hold.
flows. Alice picks up the held call and has a established session with
Carol. Finally, Carol terminates the session.
Note that it is possible that both Alice and Bob answer the call and
send 200 OK responses to Carol. Alice and Bob will also both publish
to the Appearance Agent indicating that the selected appearance is in
use by their respective dialogs. The Appearance Agent can detect
this since the Call-ID and remote-tag will be the same in both
publications and should allow this for a period of time. It is up to
Carol to resolve this situation. Typically, Carol will send ACKs to
both 200 OKs but send a BYE to terminate one of the dialogs. As a
result, either Alice or Bob will receive the BYE and publish that
their dialog is over. However, if Carol answers both Alice and Bob
and keeps both dialogs active, then the Appearance Agent will need to
resolve the situation by moving either Alice or Bob's dialog to a
different appearance.
OPEN ISSUE: What if Carol answers both calls and then performs
local mixing? In this case, Alice and Bob are effectively using
the same appearance and the Appearance Agent does not need to move
one of the dialogs. However, how does anyone know besides Carol
that this is happening?
All NOTIFY messages in the call flow below carry dialog events and
only dialog states are mentioned for simplicity. For brevity, the
details of some messages are not shown below.
Forking Appearance
Carol Proxy Agent Alice Bob
| | | | |
|>F1 INVITE >| | | |
| |< - - - - - >| | |
| | |>F2 NOTIFY ----------->|
| | | | |
| | |<F3 200 OK -----------<|
| | | | |
| | |>F4 NOTIFY ->| |
| | | | |
| | |<-200 OK F5-<| |
|<- 100 F6 -<| | | |
| |>F7 INVITE (appearance=1) ---------->|
| | | | |
| |>F8 INVITE (appearance=1) >| |
| | | | |
| |<-------------------- Ringing 180 F9<|
|< 180 F10 -<| | | |
| |<--------- 180 Ringing F11<| |
|< 180 F12 -<| | | |
| | | | |
| |<------------------------ 200 OK F13<|
|< 200 F14 -<| | | |
| | |<--------- PUBLISH F15<|
| | | | |
| | |>F16 200 OK ---------->|
| | | | |
| |>F17 CANCEL -------------->| |
| | | | |
| |<-------------- 200 OK F18<| |
| | | | |
| |<Request Cancelled 487 F19<| |
| | | | |
| |>F20 ACK ----------------->| |
|>F21 ACK -->| | | |
| |>F22 ACK --------------------------->|
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| | |>F23 NOTIFY >| |
| | | | |
| | |<- 200 F24 -<| |
| | | | |
| | |>F25 NOTIFY ---------->|
| | | | |
| | |<F26 200 OK ----------<|
| | | |
Figure 3.
F4 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:alice@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com
CSeq: 12 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact: <sip:appearance-agent@stateagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13"
state="partial"
entity="sip:alice@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345@example.com"
remote-tag="44BAD75D-E3128D42"
direction="recipient">
<sa:appearance>1</appearance>
<state>trying</state>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
F7 Proxy ----> Bob
INVITE sip:alice@ua3.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
To: <sip:alice@example.com>
CSeq: 106 INVITE
Call-ID: 14-1541707345@example.com
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <file://ring.pcm>;alert=normal;appearance=1
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F8 Proxy ----> Alice
INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281
From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
To: <sip:alice@example.com>
CSeq: 106 INVITE
Call-ID: 14-1541707345@example.com
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <file://ring.pcm>;alert=normal;appearance=1
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F15: Bob notifies the Appearance Agent with dialog state
payload indicating the dialog in confirmed state. Appearance
Agent notifies Alice of the status of the dialog at Bob.
F15 Bob ----> Appearance Agent
PUBLILSH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263
From: <sip:bob@example.com>;tag=558C18F7-DB9DF7BC
To: <sip:alice@example.com>;tag=1894685100249086
CSeq: 14 PUBLISH
Call-ID: 77-505889516@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13"
state="partial"
entity="sip:alice@example.com">
<dialog id="ida0f8dc17"
call-id="14-1541707345@example.com"
local-tag="44BAD75D-E3128D42"
remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c"
direction="recipient">
<sa:appearance>1</appearance>
<sa:exclusive>false</exclusive>
<state>confirmed</state>
<local>
<target uri="sip:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
10.3. Outgoing Call with Without Appearance Pre-Selection
In this scenario, Bob's UA places a call without first selecting an
appearance number. After sending the INVITE, Bob sends out a dialog
event PUBLISH with state (trying) but does not include an appearance
number or the 'shared' dialog event parameter. As a result, the
Appearance agent treats the publish as if it were sent by an shared
appearance-unaware UA and assigns an appearance number for it. The
NOTIFY from the appearance agent tells Bob what appearance number to
use. Bob also publishes on receipt of the 180 Ringing and 200 OK
responses. Note that NOTIFYs F16 and F25 do not tell Bob any new
information and could be suppressed by the Appearance Agent.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<|
| | | | | | | | | |
| | | |>F2 200 OK ------>| | |<------------------------------------- INVITE F1<|
| | | | | | | | | |
| | |<-- NOTIFY F3<| | | |>F2 100 Trying --------------------------------->|
|<-- INVITE F3<| | | |
| | | |<----- PUBLISH F4<|
| | | | | | | | | |
| | |>F4 200 OK -->| | | | | |>F5 200 OK ------>|
| | | |------- NOTIFY F5>| | | |<-- NOTIFY F6<| |
| | | | | | | | | |
| | | |<F6 200 OK ------<| | | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | | | | | | |
| | | |<F9 200 OK ------<|
|>F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | | | | | | |
| |<------------------------------------ INVITE F11<| | | | |<---- PUBLISH F12<|
| | | | | | | | | |
|<- INVITE F12<| | | | | | | |>F13 200 OK ----->|
| | |<- NOTIFY F14<| |
| | | | | | | | | |
|>F13 180 --->| | | | | | |>F15 200 OK ->| |
| |>F14 180 Ringing ------------------------------->| | | | |------ NOTIFY F16>|
|>F15 200 OK ->| | | |
| |>F16 200 OK ------------------------------------>|
| | | | | | | | | |
|<------------------------------------------------------ ACK F17<| | | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | | | | | | |
|<================= Both way RTP established ===================>| | | | |<---- PUBLISH F20<|
| | | | | | | | | |
| | | |<---- PUBLISH F18<| | | | |>F21 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F22<|
|<---- ACK F23<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | | | | | | |
| | | |>F19 200 OK ----->|
| | |<- NOTIFY F20<| |
| | |<- NOTIFY F24<| |
| | | | | | | | | |
| | |>F21 200 OK ->| | | | |>F25 200 OK ->| |
| | | |------ NOTIFY F22>| | | | |------ NOTIFY F26>|
| | | | | | | | | |
| | | |<F23 200 OK -----<| | | | |<F27 200 OK -----<|
| | | | | | | | | |
Figure 3. Figure 4.
F1 to F4: Bob uses the BLA appearance of Alice on his UA to place an outgoing call (e.g., he goes off-hook). Before sending the outgoing INVITE request, Bob notifies the sate agent that Alice line appearance is in (trying) state. Appearance Agent notifies Alice of the same event by forwarding the NOTIFY payload provided by Bob after appropriately changing the dialog id field in the XML payload to a unique value towards each of the entities it is forwarding to (Alice in this example). F1 Bob ----> Proxy
</t>
<figure><artwork><![CDATA[
F1 Bob ----> Appearance Agent INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: <sip:bob@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com>
CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com
Contact: <sip:bob@ua2.example.com>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA
c=IN IP4 ua2.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F4 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0 PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801 To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 7 PUBLISH CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog Event: dialog
User-Agent: XYZ-UA/4.5.6
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="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F2 Appearance Agent ----> Bob F5 Appearance Agent ----> Bob
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
CSeq: 7 PUBLISH CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 144-1289338424@example.com
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801 To: <sip:appearance-agent@example.com>;tag=428765950880801
Allow-Events: dialog Allow-Events: dialog
Contact: <sip:appearance-agent@stateagent.example.com> Contact: <sip:appearance-agent@stateagent.example.com>
Expires: 60
Content-Length: 0 Content-Length: 0
F3 Appearance Agent ----> Alice F8 Appearance Agent ----> Bob
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:alice@example.com>;tag=497585728578386 From: <sip:bob@example.com>;tag=497585728578386
To: <sip:alice@example.com>;tag=633618CF-B9C2EDA4 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog Event: dialog;shared
Subscription-State: active Subscription-State: active
Contact: <sip:sa@stateagent.example.com> Contact: <sip:appearance-agent@stateagent.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:alice@example.com"> entity="sip:alice@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" direction="initiator"> <dialog id="fa02538339df3ce597f9e3e3699e28fc" direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F4 Alice ----> Appearance Agent F9 Bob ----> Appearance Agent
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
From: <sip:bob@example.com>;tag=497585728578386
From: <sip:alice@example.com>;tag=497585728578386 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
To: <sip:alice@example.com>;tag=633618CF-B9C2EDA4
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
Contact: <sip:alice@ua1.example.com> Contact: <sip:bob@ua1.example.com>
Event: dialog Event: dialog;shared
User-Agent: ABC-UA/1.2.3
Content-Length: 0 Content-Length: 0
F5 and F6: The Appearance Agent sends a NOTIFY to Bob confirming appearance number. F20 Bob ----> Appearance Agent
F11 to F17: Bob places a call to Carol by sending the INVITE request
towards the Proxy. The INVITE (see F5 message below) includes a
P-Preferred-Identity header <xref target="RFC3325" /> to designate the identity to be
used as the calling party for this call (i.e., Alice instead of Bob).
F11 Bob ----> Proxy
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: <sip:bob@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com>
CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com
Contact: <sip:bob@ua2.example.com>
User-Agent: XYZ-UA/4.5.6
P-Preferred-Identity: <sip:alice@example.com>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA
c=IN IP4 ua2.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F18 to F21: Bob notifies the Appearance Agent of the status of the
dialog (i.e., confirmed). Appearance Agent notifies Alice of the
same.
F18 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0 PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=428765950880801 To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 9 NOTIFY CSeq: 9 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog Event: dialog;shared
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3342
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="8" version="8"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com" call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator"> direction="initiator">
<state>confirmed</state> <state>confirmed</state>
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<local> <local>
<target uri="sip:bob@example.com"> <target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:carol@example.com</identity> <identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com;user=phone" /> <target uri="sip:carol@example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.3. Taking an Appearance 10.4. Outgoing Call with Appearance Selection
In this scenario, Bob has an established dialog with Carol. Bob then In this scenario, Bob's UA sends out a dialog event PUBLISH with
places Carol on hold. Alice subsequently picks up the held call and state (trying) selecting an appearance number before sending the
has a established session with Carol. Finally, Carol hangs up. The INVITE. After receiving the 200 OK from the Appearance Agent
details of the notifications amongst the user agents and the confirming the appearance number, Bob's UA sends the INVITE to Carol
Appearance Agent in updating the status of the BLA group members are and establishes a session. For brevity, details of some of the
shown below. For brevity, details of some of the messages are not messages are not included in the message flows.
included in the message flows.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<|
| | | | | | | | | |
|<================= Both way RTP established ===================>| | | | |>F2 200 OK ------>|
| | | | |
| | | | |
| |<------------------------------(hold) INVITE F16<|
|<- INVITE F17<| | | |
| | | | |
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
|<------------------------------------------------------ ACK F20<|
| | | | | | | | | |
| | | |<----- NOTIFY F21<| | |<------------------------------------- INVITE F3<|
| | | | | | | | | |
| | | |>F22 200 OK ----->| | |>F4 100 Trying --------------------------------->|
| | |<- NOTIFY F23<| | |<-- INVITE F5<| | | |
| | |<-- NOTIFY F6<| |
| | | | | | | | | |
| | |>F24 200 OK ->| | | | |>F7 200 OK -->| |
| |<-- INVITE F25<| | | | | | |------- NOTIFY F8>|
|<- INVITE F26<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F27 200 OK ->| | | |
| |>F28 200 OK -->| | |
| | | | | | | | | |
|<-------------------- ACK F29<| | | | | | |<F9 200 OK ------<|
|>F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | | | | | | |
|<= Both way RTP established =>| | | | | | |<---- PUBLISH F12<|
| | | | | | | | | |
|>F30 BYE ---->| | | | | | | |>F13 200 OK ----->|
| |>F31 BYE --------------------------------------->| | | |<- NOTIFY F14<| |
| | | | | | | | | |
| |<------------------------------------ OK 200 F32<| | | |>F15 200 OK ->| |
|<- 200 OK F33<| | | | | | | |------ NOTIFY F16>|
| | | | | | | | | |
| | | |<----- NOTIFY F34<| | | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | | | | | | |
| | | |>F35 200 OK ----->| | | | |<---- PUBLISH F20<|
| | |<- NOTIFY F36<| |
| | | | | | | | | |
| | |>F37 200 OK ->| | | | | |>F21 200 OK ----->|
| | | | | | | | | |
| |<--------------------------------------- ACK F22<|
| | |>F38 NOTIFY ->| | |<---- ACK F23<| | | |
| | | | | | | | | |
| | |<- 200 OK F39<| | |<================= Both way RTP established ===================>|
| | | |>F40 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F41<| | | |<- NOTIFY F24<| |
|>F42 BYE ---->| | | |
| |>F43 BYE ----->| | |
| | | | | | | | | |
| |<-- 200 OK F44<| | | | | |>F25 200 OK ->| |
|<--200 OK F45<| | | | | | | |------ NOTIFY F26>|
| | |>F46 NOTIFY ->| |
| | | | | | | | | |
| | |<- 200 OK F47<| | | | | |<F27 200 OK -----<|
| | | |>F48 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- OK 200 F49<|
Figure 4. Figure 5.
F16 to F20: Bob places Carol on hold.
F22 to F24: Bob notifies Appearance Agent of the status of the dialog to F1 to F4: Bob uses the shared appearance appearance of Alice on his
indicate the held state. It indicates this by setting the sip.rendering UA to place an outgoing call (e.g., he goes off-hook). Before
parameter in the NOTIFY payload to (no). Appearance Agent notifies sending the outgoing INVITE request, Bob publishes to the state agent
Alice of the same. that Alice line appearance is in (trying) state. The Appearance
Agent notifies Alice of the same event by forwarding the NOTIFY
payload provided by Bob after appropriately changing the dialog id
field in the XML payload to a unique value towards each of the
entities it is forwarding to (Alice in this example). Note the
shortened expiration interval in F2 of 60 seconds. As long as Bob is
using the appearance number, he must refresh the publication every 60
seconds or loose the appearance.
F22 Bob ----> Appearance Agent F1 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0 PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6c78a6c5CA00520E Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=428765950880801 To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 10 NOTIFY CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog Event: dialog;shared
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3338
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="9" version="6"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83" direction="initiator">
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<state>confirmed</state>
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<state>trying</state>
<local> <local>
<target uri="sip:bob@example.com"> <target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="no"/>
</target> </target>
</local> </local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" />
</remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F26 to F34 : Alice picks up the held call by sending an INVITE with F2 Appearance Agent ----> Bob
Replaces: header (F26). Session is established between Alice and
Carol. The dialog between Carol and Bob is terminated.
F26 Alice ----> Proxy SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801
Allow-Events: dialog
Contact: <sip:appearance-agent@stateagent.example.com>
Expires: 60
Content-Length: 0
INVITE sip:carol@example.com SIP/2.0 F8 Appearance Agent ----> Bob
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sip:alice@example.com>;tag=8C4183CB-BCEAB710 NOTIFY sip:bob@ua1.example.com SIP/2.0
To: <sip:carol@example.com:5075> From: <sip:alice@example.com>;tag=497585728578386
CSeq: 1 INVITE To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
Contact: <sip:alice@ua1.example.com> CSeq: 7 NOTIFY
User-Agent: ABC-UA/1.2.3 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
P-Preferred-Identity: <sip:alice@example.com>
<all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line>
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/sdp Content-Type: application/dialog-info+xml
Content-Length: 223 Event: dialog;shared
Subscription-State: active
Contact: <sip:appearance-agent@stateagent.example.com>
Content-Length: ...
v=0 <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27"
state="partial"
entity="sip:alice@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" direction="initiator">
<sa:appearance>0</appearance>
<sa:exclusive>false</exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
o=- 1102980497 1102980497 IN IP4 ua1.example.com F9 Bob ----> Appearance Agent
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F34 to F41: Bob notifies the Appearance Agent of the termination of SIP/2.0 200 OK
dialog at his UA. Alice notifies the Appearance Agent of the Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
confirmed state of the dialog at her UA. From: <sip:alice@example.com>;tag=497585728578386
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
CSeq: 7 NOTIFY
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
Contact: <sip:bob@ua1.example.com>
Event: dialog;shared
Content-Length: 0
F34 Bob ----> Appearance Agent 10.5. Outgoing Call without using an Appearance Number
NOTIFY sip:sa@stateagent.example.com SIP/2.0 In this scenario, Bob's UA sends out a dialog event PUBLISH with
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' dialog event parameter.
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
wish to allow this, it would reject the PUBLISH with a 409 Conflict
response and the UA would know to re-PUBLISH selecting an appearance
number.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| |<------------------------------------- INVITE F3<|
| | | | |
| |>F4 100 Trying --------------------------------->|
|<-- INVITE F5<| | | |
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |<F9 200 OK ------<|
|>F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | |
| | | |<---- PUBLISH F12<|
| | | | |
| | | |>F13 200 OK ----->|
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| | | |<---- PUBLISH F20<|
| | | | |
| | | |>F21 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F22<|
|<---- ACK F23<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | |<- NOTIFY F24<| |
| | | | |
| | |>F25 200 OK ->| |
| | | |------ NOTIFY F26>|
| | | | |
| | | |<F27 200 OK -----<|
| | | | |
Figure 6.
F1 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: "State_Agent" <sip:alice@example.com>;tag=428765950880801 To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 11 NOTIFY CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog Event: dialog;shared
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3334
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="6"
state="partial" state="partial"
entity="sip:alice@example.com:5060"> entity="sip:alice@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83" direction="initiator">
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
10.6. Appearance Release
Bob and Carol are in a dialog, created in one of the previous two
call flows. Carol sends a BYE to Bob to terminate the dialog. Bob
publishes the termination of the dialog and the Appearance Agent de-
allocates the appearance number used.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
|>F28 BYE ---->| | | |
| |>F29 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ 200 OK F30<|
|<--200 OK F31<| | | |
| | | |<---- PUBLISH F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | |<- NOTIFY F34<| |
| | | | |
| | |>F35 200 OK ->| |
| | | |------ NOTIFY F36>|
| | | | |
| | | |<F37 200 OK -----<|
Figure 7.
F32 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 37 PUBLISH
Call-ID: 65144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="partial"
entity="sip:alice@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>0</appearance>
<state>terminated</state> <state>terminated</state>
<local> <local>
<target uri="sip:bob@example.comsip:bob@example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" />
</remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F38 Alice ----> Appearance Agent 10.7. Appearance Pickup
NOTIFY sip:sa@stateagent.example.com SIP/2.0 In this scenario, Bob has an established dialog with Carol created
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK93f44af3518A1572 using the call flows of Figure 2 or Figure 3. Bob then places Carol
From: <sip:alice@example.com>;tag=5861255C-14C04045 on hold. Alice receives a notification of this and renders this on
To: "State_Agent" <sip:alice@example.com>;tag=920163082722420 Alice's UI. Alice subsequently picks up the held call and has a
CSeq: 10 NOTIFY established session with Carol. Finally, Carol hangs up.
Call-ID: 143-1840952798@example.com
Contact: <sip:alice@ua1.example.com> Carol Proxy Alice Appearance Agent Bob
Event: dialog | | | | |
User-Agent: ABC-UA/1.2.3 |<================= Both way RTP established ===================>|
Subscription-State: active;expires=3315 | | | | |
| |<------------------------------(hold) INVITE F28<|
|<- INVITE F29<| | | |
| | | | |
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F32<|
|<---- ACK F33<| | | |
| | | |<---- PUBLISH F34<|
| | | | |
| | | |>F35 200 OK ----->|
| | |<- NOTIFY F36<| |
| | | | |
| | |>F37 200 OK ->| |
| | | |>F38 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F39<|
| | | | |
| | Alice decides to pick up the call |
| | | | |
| | |>F40 PUBLISH->| |
| | | | |
| | |<- 200 OK F41<| |
| | | | |
| | |<- NOTIFY F42<| |
| | | | |
| | |>F43 200 OK ->| |
| | | |>F44 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F45<|
| |<-- INVITE F46<| | |
|<- INVITE F47<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F48 200 OK ->| | | |
| |>F49 200 OK -->| | |
| | |>F50 PUBLISH->| |
| | | | |
| | |<- 200 OK F51<| |
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|
| | |<- NOTIFY F54<| |
| | | | |
| | |>F55 200 OK ->| |
| | | | |
| |<----- ACK F56<| | |
|<---- ACK F57<| | | |
| | | | |
|<= Both way RTP established =>| | |
| | | | |
|>F58 BYE ---->| | | |
| |>F59 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F60<|
|<- 200 OK F61<| | | |
| | | | |
| | | |<---- PUBLISH F62<|
| | | | |
| | | |>F63 200 OK ----->|
| | |<- NOTIFY F64<| |
| | | | |
| | |>F65 200 OK ->| |
| | | | |
| | | |>F66 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F67<|
Figure 8.
F28 to F33: Bob places Carol on hold.
F34 to F39: Bob notifies Appearance Agent of the status of the dialog to
indicate the held state. It indicates this by setting the sip.rendering
parameter in the NOTIFY payload to (no). Appearance Agent notifies
Alice of the same.
F34 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
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="9" version="10"
state="partial" state="partial"
entity="sip:alice@example.com:5060"> entity="sip:alice@example.com:5060">
<dialog id="id402f024e" <dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6@ua1.example.com" call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
local-tag="8C4183CB-BCEAB710" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator"> direction="initiator">
<state>confirmed</state>
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<state>active</state>
<local> <local>
<target uri="sip:alice@example.com"> <target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:carol@example.com</identity> <identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" /> <target uri="sip:carol@example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F42 to F59: Carol terminates the dialog with Alice. Alice notifies the F40 Alice ----> Appearance Agent
Appearance Agent of the dialog state (terminated). The Appearance Agent
notifies Bob of the same.
F46 Alice ----> Appearance Agent PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
NOTIFY sip:sa@stateagent.example.com SIP/2.0 From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa46c2f85F29F839C To: <sip:appearance-agent@example.com>;tag=428765950880801
From: <sip:alice@example.com>;tag=5861255C-14C04045 CSeq: 11 PUBLISH
To: "State_Agent" <sip:alice@example.com>;tag=920163082722420 Call-ID: 1289338424@example.com
CSeq: 11 NOTIFY Contact: <sip:alice@ua2.example.com>
Call-ID: 143-1840952798@example.com Event: dialog;shared
Contact: <sip:alice@ua1.example.com>
Event: dialog
User-Agent: ABC-UA/1.2.3
Subscription-State: active;expires=3311
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="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com:5060">
<dialog id="id402f024e" <dialog id="id3d4f9c83">
call-id="3d57cd17-47deb849-dca8b6c6@ua1.example.com"
local-tag="8C4183CB-BCEAB710"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<state>terminated</state>
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state>
<local> <local>
<target uri="sip:alice@example.com"> <target uri="sip:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" /> <target uri="sip:carol@example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.4. Appearance Selection for Incoming Call F46: Alice picks up the held call by sending an INVITE with
Replaces: header . Session is established between Alice and
Carol. The dialog between Carol and Bob is terminated.
In the call flow below Bob and Alice are in an appearance group F46 Bob ----> Proxy
identified by Alice's AOR. Carol places a call to Alice. Both Alice
and Bob's devices are alerted of the incoming call. Bob answers the
call. He then places Carol on hold. Alice picks up the held call
and has a established session with Carol. Finally, Carol terminates
the session. All NOTIFY messages in the call flow below carry dialog
events and only dialog states are mentioned for simplicity. For
brevity, the details of some messages are not shown below.
Forking Appearance INVITE sip:carol@example.com SIP/2.0
Carol Proxy Agent Alice Bob Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sip:alice@example.com>;tag=8C4183CB-BCEAB710
To: <sip:carol@example.com:5075>
CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com
Contact: <sip:alice@ua1.example.com>
<all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
10.8. Calls between UAs within the Group
In this scenario, Bob calls Alice who is also in the Appearance
group. He chooses to allocate an appearance.
Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|>F1 INVITE >| | | | | |<-------------------- INVITE (to Alice's UA) F1<|
| |< - - - - - >| | |
| | |>F2 NOTIFY ----------->|
| | | | | | | | | |
| | |<F3 200 OK -----------<| | | | |<----- PUBLISH F2<|
| | | | | | | | | |
| | |>F4 NOTIFY ->| | | | | |>F3 200 OK ------>|
| | | | | | | | | |
| | |<-200 OK F5-<| | | | |<-- NOTIFY F4<| |
| | | | | | | | | |
| |>F6 INVITE ------------------------->| | | |>F5 200 OK -->| |
| | | |>F6 NOTIFY ------>|
| | | | | | | | | |
| |>F7 INVITE --------------->| | | | | |<------ 200 OK F7<|
| |>F8 INVITE --->| | |
| | (appearance=1)| | |
| | | | | | | | | |
|<- 100 F8 -<| | | | | |<------ 180 F9<| | |
| | | | | | | | | |
| |<-------------------- Ringing 180 F9<| | |>F10 180 -------------------------------------->|
|< 180 F10 -<| | | |
| |<--------- 180 Ringing F11<| |
|< 180 F12 -<| | | |
| |<------------------------ 200 OK F13<|
|< 200 F14 -<| | | |
| | | | | | | | | |
| |>F14 CANCEL -------------->| | | | | |<---- PUBLISH F11<|
| | | | | | | | | |
| |<-------------- 200 OK F15<| | | | | |>F12 200 OK ----->|
| | |<- NOTIFY F13<| |
| | | | | | | | | |
| |<Request Cancelled 487 F16<| | | | |>F14 200 OK ->| |
| | | |>F15 NOTIFY ----->|
| | | | | | | | | |
| |>F17 ACK ----------------->| | | | | |<----- 200 OK F16<|
|>F18 ACK -->| | | |
| |>F19 ACK --------------------------->|
| | | | | | | | | |
|<=============Both way RTP established===========>|
| | | | | | | | | |
| | |<---------- NOTIFY F20<| | |<-- 200 OK F17<| | |
| | |>F18 PUBLISH->| |
| | | | | | | | | |
| | |>F21 200 OK ---------->| | | |<- 200 OK F19<| |
| | | | | | | | | |
| | |>F22 NOTIFY >| | | | |<- NOTIFY F20<| |
| | | | | | | | | |
| | |<- 200 F22 -<| | | | |>F21 200 OK ->| |
| | | |>F22 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F23<|
| | | | |
| |>F24 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F25<|
| | | | |
| |>F26 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| | | |<---- PUBLISH F27<|
| | | | |
| | | |>F28 200 OK ----->|
| | |<- NOTIFY F29<| |
| | | | |
| | |>F30 200 OK ->| |
| | | |>F31 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F32<|
| | | | | | | | | |
| | |-------- SUBSCRIBE F23>|
| | | |
| | |<F24 200 OK ----------<|
| | | |
| | |<---------- NOTIFY F25<|
| | | |
| | |>F26 200 OK ---------->|
| | | |
Figure 5.
F1 to F16: An incoming call from Carol to Alice is forked to
Bob and Alice. Both Alice and Bob indicate an incoming call
(e.g., ringing) from Carol. Bob answers the call and two-way
media is established between Carol and Bob.
F2 Proxy ----> Bob
INVITE sip:alice@ua3.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=94183CB-BCEAB7
To: <sip:alice@example.com>
CSeq: 106 INVITE
Call-ID: 47deb849-dca8b6c6-3d342
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <file://ring.pcm>;alert=normal;appearance=0
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F3 Proxy ----> Alice
INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281
From: <sip:carol@example.com>;tag=94183CB-BCEAB7
To: <sip:alice@example.com>
CSeq: 106 INVITE
Call-ID: 47deb849-dca8b6c6-3d342
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <file://ring.pcm>;alert=normal;appearance=0
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F17 - F20: Bob notifies the Appearance Agent with dialog state Figure 9.
payload indicating the dialog in confirmed state. Appearance
Agent notifies Alice of the status of the dialog at Bob.
F17 Bob ----> Appearance Agent F2 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0 PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:bob@example.com>;tag=558C18F7-DB9DF7BC From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=1894685100249086 To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 14 NOTIFY CSeq: 11 PUBLISH
Call-ID: 77-505889516@example.com Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog Event: dialog
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3427
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="13" version="10"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com:5060">
<dialog id="ida0f8dc17" <dialog id="id3d4f9c83"
call-id="14-1541707345@example.com" call-id="b3cbd0-ad2c5775e-5df9f8d5@ua2.example.com"
local-tag="44BAD75D-E3128D42" local-tag="3153DE7C-928203B"
remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" direction="initiator">
direction="recipient"> <sa:exclusive>true</exclusive>
<state>trying</state>
<sa:appearance>0</appearance>
<sa:exclusive>false</exclusive>
<state>confirmed</state>
<local> <local>
<target uri="sip:alice@example.com"> <target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:carol@ua.example.com</identity> <identity>sip:alice@example.com</identity>
<target uri="sip:alice@example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F19 Appearance Agent ----> Alice F6 Appearance Agent ----> Bob
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:alice@example.com>;tag=151702541050937 From: <sip:bob@example.com>;tag=497585728578386
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 12 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413 Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog Event: dialog;shared
Subscription-State: active Subscription-State: active
Contact: <sip:sa@stateagent.example.com> Contact: <sip:appearance-agent@stateagent.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="10"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com:5060">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c" <dialog id="3xdsd4f9c83"
call-id="14-1541707345@example.com" call-id="b3cbd0-ad2c5775e-5df9f8d5@ua2.example.com"
local-tag="44BAD75D-E3128D42" local-tag="3153DE7C-928203B"
remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" direction="initiator">
direction="recipient"> <sa:exclusive>true</exclusive>
<sa:appearance>0</appearance> <sa:appearance>1</appearance>
<sa:exclusive>false</exclusive> <state>trying</state>
<state>confirmed</state>
<local> <local>
<target uri="sip:alice@example.com"> <target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:carol@ua.example.com</identity> <identity>sip:alice@example.com</identity>
<target uri="sip:alice@example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.5. Appearance Publication 10.9. Consultation Hold with Appearances
This call flow shows the use of PUBLISH between the members of the In this scenario, Bob has a call with Carol. Bob makes a
appearance group and the Appearance Agent. 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 since he is treating it as part of the call to Carol. He
indicates this in his PUBLISH F34 which is sent before the INVITE to
Alice to ensure no appearance number is assigned by the Appearance
Agent. Finally, Bob hangs up with Alice and resumes the call with
Carol.
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
for the call with Alice. If not, Bob publishes the termination of
the dialog with Carol and the Appearance Agent will re-allocate the
appearance. If he wants to keep the appearance, Bob will publish the
termination of the dialog with Carol and also publish the appearance
with the dialog with Alice. This will result in Bob keeping the
appearance number until he reports the dialog with Alice terminated.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| | | |>F2 200 OK ------>| | |<------------------------------(hold) INVITE F28<|
|<- INVITE F29<| | | |
| | | | | | | | | |
| | |<-- NOTIFY F3<| | |>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | | | | | | |
| | |>F4 200 OK -->| | | |<--------------------------------------- ACK F32<|
|<---- ACK F33<| | | |
| | | |<---- PUBLISH F34<|
| | | | | | | | | |
| |<------------------------------------- INVITE F5<| | | | |>F35 200 OK ----->|
| | |<- NOTIFY F36<| |
| | | | | | | | | |
|<-- INVITE F6<| | | | | | |>F37 200 OK ->| |
| | | |>F38 NOTIFY ----->|
| | | | | | | | | |
|>F7 180 Ring >| | | | | | | |<----- 200 OK F39<|
| |>F8 180 Ringing -------------------------------->|
|>F9 200 OK -->| | | |
| |>F10 200 OK ------------------------------------>|
| | | | | | | | | |
|<------------------------------------------------------ ACK F11<| | | Bob makes a consultation call to Alice |
| | | | | | | | | |
|<================= Both way RTP established ===================>| | | | |<---- PUBLISH F40<|
| | | | | | | | | |
| | | |<---- PUBLISH F12<| | | | |>F41 200 OK ----->|
| | | | | | | | | |
| | | |>F13 200 OK ----->| | |<------------------------------------ INVITE F42<|
| | |<- NOTIFY F14<| |
| | | | | | | | | |
| | |>F15 200 OK ->| | | | |<- NOTIFY F43<| |
| | | | | | | | | |
| |<------------------------------(hold) INVITE F16<| | | |>F44 200 OK ->| |
|<- INVITE F17<| | | | | | | |>F45 NOTIFY ----->|
| | | | | | | | | |
|>F18 200 OK ->| | | | | | | |<----- 200 OK F46<|
| |>F19 200 OK ------------------------------------>| | |>F47 INVITE -->| | |
| | | | | | | | | |
|<------------------------------------------------------ ACK F20<| | |<-- 200 OK F48<| | |
| | |>F49 PUBLISH->| |
| | | | | | | | | |
| | | |<---- PUBLISH F21<| | | |<- 200 OK F50<| |
| | | | | | | | | |
| | | |>F22 200 OK ----->| | | |<- NOTIFY F51<| |
| | |<- NOTIFY F23<| |
| | | | | | | | | |
| | |>F24 200 OK ->| | | | |>F52 200 OK ->| |
| |<-- INVITE F25<| | | | | | |>F53 NOTIFY ----->|
|<- INVITE F26<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F27 200 OK ->| | | |
| |>F28 200 OK -->| | |
| | | | | | | | | |
|<-------------------- ACK F29<| | | | | | |<----- 200 OK F54<|
| | | | | | | | | |
|<= Both way RTP established =>| | | | |>F55 200 OK ------------------------------------>|
| | | | | | | | | |
|>F30 BYE ---->| | | | | |<--------------------------------------- ACK F56<|
| |>F31 BYE --------------------------------------->|
| | | | | | | | | |
| |<------------------------------------ OK 200 F32<| | |>F57 ACK ----->| | |
|<- 200 OK F33<| | | |
| | | | | | | | | |
| | | |<---- PUBLISH F34<| | | |<======= RTP established =======>|
| | | | | | | | | |
| | | |>F35 200 OK ----->| | | | |<---- PUBLISH F58<|
| | |<- NOTIFY F36<| |
| | | | | | | | | |
| | |>F37 200 OK ->| | | | | |>F59 200 OK ----->|
| | |<- NOTIFY F60<| |
| | | | | | | | | |
| | |>F38 PUBLISH >| | | | |>F61 200 OK ->| |
| | | |>F62 NOTIFY ----->|
| | | | | | | | | |
| | |<- 200 OK F39<| | | | | |<----- 200 OK F63<|
| | | |>F40 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F41<| | | Bob hangs up with Alice |
|>F42 BYE ---->| | | |
| |>F43 BYE ----->| | |
| | | | | | | | | |
| |<-- 200 OK F44<| | | | |<--------------------------------------- BYE F64<|
|<--200 OK F45<| | | |
| | |>F46 PUBLISH >| |
| | | | | | | | | |
| | |<- 200 OK F47<| | | | | |<---- PUBLISH F65<|
| | | |>F48 NOTIFY ----->| | | | | |
| | | |>F66 200 OK ----->|
| | |<- NOTIFY F67<| |
| | | | |
| | |>F68 200 OK ->| |
| | | |>F69 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F70<|
| |>F71 BYE ----->| | |
| | | | |
| |<-- 200 OK F72<| | |
| | |>F73 PUBLISH->| |
| | | | |
| | |<- 200 OK F74<| |
| | | | |
| | |<- NOTIFY F75<| |
| | | | |
| | |>F76 200 OK ->| |
| | | |>F77 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F78<|
| | | | |
| |>F79 200 OK ------------------------------------>|
| | | | |
| | | |<---- PUBLISH F80<|
| | | | |
| | | |>F81 200 OK ----->|
| | |<- NOTIFY F82<| |
| | | | |
| | |>F83 200 OK ->| |
| | | |>F84 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F85<|
| | | | |
| |<----------------------------(unhold) INVITE F86<|
|<- INVITE F87<| | | |
| | | | |
|>F88 200 OK ->| | | |
| |>F89 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F90<|
|<---- ACK F91<| | | |
| | | |<---- PUBLISH F92<|
| | | | |
| | | |>F93 200 OK ----->|
| | |<- NOTIFY F94<| |
| | | | |
| | |>F95 200 OK ->| |
| | | |>F96 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F97<|
| | | | |
|<================= Both way RTP established ===================>|
| | | | | | | | | |
| | | |<----- OK 200 F49<|
Figure 6. Figure 10.
10.6. Joining an Appearance F40 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="partial"
entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5@ua2.example.com"
local-tag="3153DE7C-928203B"
direction="initiator">
<sa:exclusive>true</exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity>sip:alice@example.com</identity>
<target uri="sip:alice@example.com" />
</remote>
</dialog>
</dialog-info>
F45 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:bob@example.com>;tag=497585728578386
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact: <sip:appearance-agent@stateagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="partial"
entity="sip:alice@example.com:5060">
<dialog id="3xdsd4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5@ua2.example.com"
local-tag="3153DE7C-928203B"
direction="initiator">
<sa:exclusive>true</exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity>sip:alice@example.com</identity>
<target uri="sip:alice@example.com" />
</remote>
</dialog>
</dialog-info>
10.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
| | | | | | | | | |
|>F1 INVITE >| | | | |<=============Both way RTP established===========>|
| |>F2 INVITE ------------------------->|
| | | | | | | | | |
| |>F3 INVITE --------------->| | | | |< PUBLISH F28| |
| | | | | | | | | |
|<-100Try F4<| | | | | | |>F29 200 OK >| |
| | | | | | | | | |
| |<-------------------- Ringing 180 F5<| | |<---- INVITE (w/ Join) F30<| |
|<180Ring F6<| | | |
| |<---------- Ringing 180 F7<| |
|<180Ring F8<| | | |
| |<------------------------- 200 OK F9<|
|<-200OK F10<| | | |
| | | | | | | | | |
| |>F11 CANCEL -------------->| | | |>F31 INVITE (w/Join)---------------->|
| | | | | | | | | |
| |<-------------- 200 OK F12<| | | | |>F32 NOTIFY >| |
| | | | | | | | | |
| |<Request Cancelled 487 F13<| | | | |< 200 OK F33<| |
| | | | | | | | | |
| |>F14 ACK ----------------->| | | | |>F34 NOTIFY ---------->|
|>F15 ACK -->| | | |
| |>F16 ACK --------------------------->|
| | | | | | | | | |
|<=============Both way RTP established===========>| | | |<F35 200 OK ----------<|
| | | | | | | | | |
| | |<---------- NOTIFY F17<| | |<---- OK 200 Contact:Bob;isfocus F36<|
| | | | | | | | | |
| | |>F18 200 OK ---------->| | | |<--------- PUBLISH F37<|
| | | | | | | | | |
| | |>F19 NOTIFY >| | | | |>F38 200 OK ---------->|
| | | | | | | | | |
| | |<- 200OK F20<| | | | |>F39 NOTIFY >| |
| | | | | | | | | |
| |<---- INVITE (w/ Join) F21<| | | | |< 200 OK F40<| |
| | | | | | | | | |
| |>F22 INVITE (w/Join)---------------->| | | |>F41 NOTIFY ---------->|
| | | | | | | | | |
| |<---- OK 200 Contact:Bob;isfocus F23<| | | |<F42 200 OK ----------<|
| | | | | | | | | |
| |>F24 200 OK Contact:Bob;isfocus----->| | |>F43 200 OK Contact:B----->| |
| | | | | | | | | |
| |<----------------- ACK F25<| | | | |< PUBLISH F44| |
| | | | | | | | | |
| |>ACK F26---------------------------->| | | |>F45 200 OK >| |
| | | | | | | | | |
| |<-----INVITE Contact:Bob;isfocus F27<| | | |>F46 NOTIFY >| |
|<-INVITE F28| | | |
|>F29 200 -->| | | |
| |>F30 200 OK ------------------------>|
| | | | | | | | | |
| |<--------------------------- ACK F31<| | | |< 200 OK F47<| |
|<--- ACK F32| | | | | | | | |
| | |>F48 NOTIFY ---------->|
| | | | |
| | |<F49 200 OK ----------<|
| | | | |
| |<----------------- ACK F50<| |
| | | | |
| |>ACK F51---------------------------->|
| | | | |
| |<-----INVITE Contact:Bob;isfocus F52<|
|<-INVITE F53| | | |
| | | | |
|>F54 200 -->| | | |
| |>F55 200 OK ------------------------>|
| | | | |
| |<--------------------------- ACK F56<|
|<--- ACK F57| | | |
| | | |<==RTP==>| | | | |<==RTP==>|
|<=============Both way RTP established===========>| |<=============Both way RTP established===========>|
| | | | |
| | |<--------- PUBLISH F58<|
| | | | |
| | |>F59 200 OK ---------->|
| | | | |
| | |>F60 NOTIFY >| |
| | | | |
| | |< 200 OK F61<| |
| | | | |
| | |>F62 NOTIFY ---------->|
| | | | |
| | |<F63 200 OK ----------<|
| | | | |
Figure 7. Figure 11.
F21 Alice ----> Proxy F28 Alice ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 11 PUBLISH
Call-ID: 1289338424@example.com
Contact: <sip:alice@ua2.example.com>
Event: dialog;shared
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="partial"
entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83">
<sa:appearance>0</appearance>
<sa:exclusive>false</exclusive>
<sa:joined-dialog
call-id="14-1541707345@example.com"
from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>trying</state>
<local>
<target uri="sip:alice@ua1.example.com">
</target>
</local>
<remote>
<target uri="sip:bob@example.com" />
</remote>
</dialog>
</dialog-info>
F20 Alice ----> Proxy
INVITE sip:bob@ua.example.com SIP/2.0 INVITE sip:bob@ua.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
From: <sip:alice@example.com>;tag=605AD957-1F6305C2 From: <sip:alice@example.com>;tag=605AD957-1F6305C2
To: <sip:bob@ua.example.com> To: <sip:bob@ua.example.com>
CSeq: 2 INVITE CSeq: 2 INVITE
Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
User-Agent: ABC-UA/1.2.3
P-Preferred-Identity: <sip:alice@example.com>
<all-one-line> <all-one-line>
Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5 Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5
-b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
</all-one-line> </all-one-line>
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 223 Content-Length: 223
v=0 v=0
o=- 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.7. Appearance Allocation - Loss of Subscription with UA 10.11. Appearance Allocation - Loss of Appearance
UA Appearance Agent UA1 UA2 Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol,
then becomes unreachable. When he fails to refresh his publication
to the appearance agent, the Appearance Agent declares the dialog
terminated and frees up the appearance using NOTIFYs R24 and F26.
After retransmitting the NOTIFY F26 to Bob, the subscription is
terminated.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| |<------------------------------------- INVITE F3<|
| | | | |
| |>F4 100 Trying --------------------------------->|
|<-- INVITE F5<| | | |
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |<F9 200 OK ------<|
|>F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | |
| | | | Bob goes offline
| | | | | | | |
| | F1: NOTIFY (trying) | | | | Appearance selection times out
| |<---------------| |
| | F2: 200 OK | |
| |--------------->| |
| | F3: NOTIFY (trying) |
| |----------------+--------------->|
| | F4: 200 OK | |
| |<---------------+----------------|
| F5: INVITE | | |
|<--------------------------------| |
| F6: 180 Ringing| | |
|-------------------------------->| |
| | | | | | | |
| | End | | | | |
| | | | | |<- NOTIFY F24<|
| | | | | | |
| | F7: SUBSCRIBE x 6 retries | | | |>F25 200 OK ->|
| |---------------> | | | | |------ NOTIFY F26>
| | | | | | |
| | F8: NOTIFY (terminated) | | | | NOTIFY is retransmitted
| |-------------------------------->|
| | F9: 200 OK |
| |<--------------------------------|
| | |
Figure 8.
The flow shown in this figure illustrates the failure of a user agent Figure 12.
after it has obtained an appearance number (F1-F2). Messages used to
refresh the subscription from Appearance Agent to UA1 are shown at
F7. When the Appearance Agent attempts to refresh its subscription
but receives no response. In this case, the Appearance Agent may
apply policy and free up the appearance number as it wishes. In this
case, after a delay, the Appearance Agent frees up the appearance
number and sends NOTIFY messages (F8) indicating the termination of
the dialog associated with the shared line.
10.8. Appearance Selection Contention Race Condition 10.12. Appearance Selection Contention Race Condition
UA Appearance Agent UA1 UA2 Bob and Alice both try to reserve appearance 2 by publishing at the
| | | | same time. The Appearance Agent allocates the appearance to Bob by
| | F1 NOTIFY (trying appearance=1) | sending a 200 OK and denies it to Alice by sending a 409 Conflict.
| |<---------------| | After the NOTIFY F24, Alice learns that Bob is using appearance 2.
| | F2 NOTIFY (trying appearance=1) | Alice republishes for appearance 3 which is accepted.
| |<---------------+----------------|
| | F3 200 OK | |
| |--------------->| |
| | F4 200 OK | |
| |----------------+--------------->|
| | F5 NOTIFY (trying appearance=1)|
| |--------------->| |
| | F6 200 OK | |
| |<---------------| |
| | F7 NOTIFY (trying) |
| |----------------+--------------->|
| | F8 200 OK | |
| |<---------------+----------------|
| F9 INVITE | | |
|<--------------------------------| |
| | F10 NOTIFY (trying appearance=2)|
| |<---------------+----------------|
| | F11 200 OK | |
| |----------------+--------------->|
| | F12 NOTIFY (trying appearance=2)|
| |----------------+--------------->|
| | F13 200 OK | |
| |<---------------+----------------|
| F14 INVITE | | |
|<-------------------------------------------------|
| | | |
Figure 9. Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | (appearance=2)
| | |>F2 PUBLISH ->| |
| | | (appearance=2) |
| | | | |
| | | |>F2 200 OK ------>|
| | |<---- F3 409 <| |
| | | | |
| | |<-- NOTIFY F4<| |
| | | | |
| | |>F5 200 OK -->| |
| | | |------- NOTIFY F6>|
| | | | |
| | | |<F7 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F8<|
| | | | |
| |>F9 100 Trying --------------------------------->|
|<- INVITE F10<| | | |
| | |>F11 PUBLISH->| |
| | | (appearance=3) |
| | | | |
| | |<--- F12 200 <| |
| | | | |
| | |<- NOTIFY F13<| |
| | | | |
| |>F14 200 OK ->| |
Dave | | |------ NOTIFY F15>|
| | | | |
| | | |<F16 200 OK -----<|
| |<----------------- INVITE F17<| |
| | | | |
| |>F18 100 Trying ------------->| |
|<- INVITE F19<| | | |
This figure illustrates two user agents, UA1 and UA2, attempting to Figure 13.
select the same appearance number (i.e. seize the same line number)
simultaneously. This type of race condition is often referred to in
telephony as a glare condition. Appearance Agent may use any desired
policy to decide which UA receives the appearance and which does not.
In this case UA1 obtains the appearance number, as indicated by the
NOTIFY from the Appearance Agent with the appearance number. UA2
learns that it did not obtain the appearance number since its NOTIFY
does not contain the appearance number from its NOTIFY.
11. IANA Considerations 11. IANA Considerations
This section registers the SIP Alert-Info header field parameter This section registers the SIP Alert-Info header field parameter
"appearance" and the XML namespace extensions to the SIP Dialog "appearance" and the XML namespace extensions to the SIP Dialog
Package. Package.
11.1. SIP Event Package Parameter: sa 11.1. SIP Event Package Parameter: shared
This specification also defines a new event parameter "sa" for the This specification also defines a new event parameter 'shared' for
Dialog Package. the Dialog Package. When used in a NOTIFY, it indicates that the
notifier supports the shared appearance feature. When used in a
PUBLISH, it indicates that the publisher has explicit appearance
information contained in the message body. If not present in a
PUBLISH, the Appearance Agent MAY assign an appearance number to any
new dialogs in the message body.
11.2. URN Sub-Namespace Registration: sa-dialog-info 11.2. URN Sub-Namespace Registration: sa-dialog-info
This section registers a new XML namespace per the procedures in This section registers a new XML namespace per the procedures in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:sa-dialog-info. URI: urn:ietf:params:xml:ns:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan@sipstation.com> Alan Johnston <alan@sipstation.com>
skipping to change at page 45, line 14 skipping to change at page 59, line 14
11.3. XML Schema Registration 11.3. XML Schema Registration
This section registers an XML schema per the procedures in [RFC3688]. This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schesa:sa-dialog-info. URI: urn:ietf:params:xml:schesa:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan@sipstation.com> Alan Johnston <alan@sipstation.com>
The XML for this schema can be found in Section 7. The XML for this schema can be found in <xref target='schema' />.
12. Appendix A - Incoming Appearance Assignment 12. Appendix A - Incoming Appearance Assignment
To best meet REQ-9, the appearance number for an incoming INVITE To best meet REQ-9, the appearance number for an incoming INVITE
should be contained in the INVITE itself. should be contained in the INVITE itself.
For the dialog package parameter approach, REQ-9 could be met in two For the dialog package parameter approach, REQ-9 could be met in two
ways. When an incoming request is received, the Appearance Agent ways. When an incoming request is received, the Appearance Agent
could send out a NOTIFY with state trying and include the appearance could send out a NOTIFY with state trying and include the appearance
number to be used for this request. Upon receipt of this NOTIFY, the number to be used for this request. Upon receipt of this NOTIFY, the
skipping to change at page 45, line 38 skipping to change at page 59, line 38
delayed or lost delayed or lost
An alternative approach is to define an extension parameter for the An alternative approach is to define an extension parameter for the
Alert-Info header field in RFC 3261 such as: Alert-Info header field in RFC 3261 such as:
Alert-Info: <file://ring.pcm>;alert=normal;appearance=0 Alert-Info: <file://ring.pcm>;alert=normal;appearance=0
This Alert-Info header would indicate to place the call on the first This Alert-Info header would indicate to place the call on the first
line appearance instance. line appearance instance.
OPEN ISSUE: What URI do we use if no special ring is requested?
The determination as to what value to use in the appearance parameter The determination as to what value to use in the appearance parameter
can be done at the proxy that forks the incoming request to all the can be done at the proxy that forks the incoming request to all the
registered UAs. There are a variety of ways the proxy can use to registered UAs. There are a variety of ways the proxy can use to
determine what value it should use to populate this parameter. For determine what value it should use to populate this parameter. For
example, the proxy could fetch this information by initiating a example, the proxy could fetch this information by initiating a
SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR 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 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 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 the State-Agent like any other UA. This would ensure that the active
dialog information is available without having to poll on a need dialog information is available without having to poll on a need
skipping to change at page 50, line 5 skipping to change at page 64, line 5
notification at any time during a call and setting "exclusive=no". notification at any time during a call and setting "exclusive=no".
It also allows a UA to learn that a particular dialog is exclusive by It also allows a UA to learn that a particular dialog is exclusive by
the presence of this parameter in a NOTIFY. In addition, a UA can the presence of this parameter in a NOTIFY. In addition, a UA can
still apply policy to any INVITE Join or Replaces requests it still apply policy to any INVITE Join or Replaces requests it
receives, as per normal SIP call control mechanisms. receives, as per normal SIP call control mechanisms.
With this approach, the number of appearances is centrally managed With this approach, the number of appearances is centrally managed
and controlled by the Appearance Agent. For UAs with soft keys or and controlled by the Appearance Agent. For UAs with soft keys or
buttons, this gives a great deal of flexibility in system management. buttons, this gives a great deal of flexibility in system management.
The User Agents in the group could SUBSCRIBE to each other and NOTIFY
dialog state events, but in a large group the User Agents have to
manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
Agent in the Appearance Agent helps in managing large groups better.
Further, the State Agent can filter dialog state events and NOTIFY
User Agents of the dialog state events which are required for the
application or feature. The State Agent can also SUBSCRIBE to dialog
state events with filters to reduce the number of NOTIFY messages
exchanged between the State Agent and the user agents in the group.
This allows a group of N UAs to each only establish a pair of dialog
state subscriptions (one in each direction) to learn the dialog state
of all other group members. This results in 2N total subscriptions
for the entire group. A full mesh of subscriptions without a state
agent would result in N(N-1) total subscriptions.
13.1.3. Appearance Selections Mechanisms 13.1.3. Appearance Selections Mechanisms
Regardless of how the appearance number is conveyed by UAs, there is Regardless of how the appearance number is conveyed by UAs, there is
still the issue of how appearance numbers are selected. For example, still the issue of how appearance numbers are selected. For example,
some UAs might have actual buttons and lamps, and pressing a some UAs might have actual buttons and lamps, and pressing a
particular button requires the UA to reserve a particular appearance particular button requires the UA to reserve a particular appearance
number. For devices with this type of user interface, the selection number. For devices with this type of user interface, the selection
must be done before the user continues with the call and dials digits must be done before the user continues with the call and dials digits
or a URI. Other UAs with different user interfaces can be flexible or a URI. Other UAs with different user interfaces can be flexible
at the time of dialing, updating the display with the appearance at the time of dialing, updating the display with the appearance
skipping to change at page 54, line 17 skipping to change at page 68, line 31
fact, it results in no additional messages or round trips. It is fact, it results in no additional messages or round trips. It is
also very similar to many current feature implementations today. also very similar to many current feature implementations today.
Standardizing this approach is likely to increase overall Standardizing this approach is likely to increase overall
interoperability of this feature. interoperability of this feature.
The rest of this document will only discuss the PUBLISH appearance The rest of this document will only discuss the PUBLISH appearance
selection mechanism. selection mechanism.
14. Acknowledgements 14. Acknowledgements
The following individuals were part of the SA Design team and have The following individuals were part of the shared appearance Design
provided input and text to the document (in alphabetical order): team and have provided input and text to the document (in
alphabetical order):
Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys.
Thanks to Chris Boulton for helping with the XML schema. Thanks to Chris Boulton for helping with the XML schema.
Much of the material has been drawn from previous work by Mohsen Much of the material has been drawn from previous work by Mohsen
Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar,
who in turn received assistance from: who in turn received assistance from:
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
Towlson, and Michael Procter of Citel Technologies, Rob Harder and Towlson, and Michael Procter of Citel Technologies, Rob Harder and
Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
Inc. Inc.
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
Dan York, Spenser Dawkins, and Martin Dolly for their comments. Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
comments.
15. Security Considerations 15. 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 [RFC3265], [RFC3903], security define in , and Event Notification [RFC3265], [RFC3903], security
considerations in these documents apply to this draft as well. considerations in these documents apply to this draft as well.
Specifically, since dialog state information and the dialog Specifically, since dialog state information and the dialog
identifiers are supplied by UA's in an appearance group to other identifiers are supplied by UA's in an appearance group to other
members, the same is prone to "call hijacks". For example, a rogue members, the same is prone to "call hijacks". For example, a rogue
UA could snoop for these identifiers and send an INVITE with Replaces UA could snoop for these identifiers and send an INVITE with Replaces
header containing these call details to take over the call. As such header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in [RFC3261]. before it mechanism (like Digest or S/MIME) described in [RFC3261]. before it
is accepted. NOTIFY message bodies that provide the dialog state is accepted. NOTIFY or PUBLISH message bodies that provide the
information and the dialog identifiers MAY be encrypted end-to-end dialog state information and the dialog identifiers MAY be encrypted
using the standard mechanics. All SUBSCRIBES between the UA's and end-to-end using the standard mechanics. All SUBSCRIBES between the
the Appearance Agent MUST be authenticated. UA's and the Appearance Agent MUST be authenticated.
16. Informative References 16. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 56, line 27 skipping to change at page 71, line 4
Alan Johnston (editor) Alan Johnston (editor)
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan@sipstation.com Email: alan@sipstation.com
Mohsen Soroushnejad Mohsen Soroushnejad
Sylantro Systems Corp Sylantro Systems Corp
Email: mohsen.soroush@sylantro.com Email: mohsen.soroush@sylantro.com
Venkatesh Venkataramanan Venkatesh Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
Email: vvenkatar@gmail.com Email: vvenkatar@gmail.com
Paul Pepper
Citel Technologies
Email: paul.pepper@citel.com
Anil Kumar
Yahoo Inc.
Email: anil@yahoo-inc.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 294 change blocks. 
927 lines changed or deleted 1570 lines changed or added

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