draft-ietf-bliss-shared-appearances-01.txt   draft-ietf-bliss-shared-appearances-02.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Expires: May 6, 2009 M. Soroushnejad Expires: September 10, 2009 M. Soroushnejad
V. Venkataramanan V. Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
November 2, 2008 March 9, 2009
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-01 draft-ietf-bliss-shared-appearances-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 May 6, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 of an Address
Address of Record (AOR) since SIP does not have the concept of lines. of Record (AOR) since SIP does not have the concept of lines. This
This feature is commonly offered in IP Centrex services and IP-PBX feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment. This document SIP feature servers used in a business environment. This document
lists requirements and compares implementation options for this lists requirements and compares implementation options for this
feature. Extensions to the SIP dialog event package are proposed. feature. Extensions to the SIP dialog event package are proposed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
5. Normative Description . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Implementation . . . . . . . . . . . . . . . . . . . . . 8 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 10 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 10 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 11
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.2.4. The <replaced-dialog> element . . . . . . . . . . . . 12
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 11 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 12
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 14 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16
7. User Interface Considerations . . . . . . . . . . . . . . . . 17 7. User Interface Considerations . . . . . . . . . . . . . . . . 18
7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18
7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18
7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18
7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . . 18 Number . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19
8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20
8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20
8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20
8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21
9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21
10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21
10.1. Registration and Subscription . . . . . . . . . . . . . . 21 10.1. Registration and Subscription . . . . . . . . . . . . . . 21
10.2. Appearance Selection for Incoming Call . . . . . . . . . 24 10.2. Appearance Selection for Incoming Call . . . . . . . . . 24
10.3. Outgoing Call with Without Appearance Pre-Selection . . . 28 10.3. Outgoing Call without Appearance Pre-Selection . . . . . 28
10.4. Outgoing Call with Appearance Selection . . . . . . . . . 33 10.4. Outgoing Call with Appearance Pre-Selection . . . . . . . 30
10.5. Outgoing Call without using an Appearance Number . . . . 37 10.5. Outgoing Call without using an Appearance Number . . . . 33
10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 39 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 35
10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 40 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 36
10.8. Calls between UAs within the Group . . . . . . . . . . . 44 10.8. Calls between UAs within the Group . . . . . . . . . . . 40
10.9. Consultation Hold with Appearances . . . . . . . . . . . 47 10.9. Consultation Hold with Appearances . . . . . . . . . . . 43
10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 52 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 45
10.11. Appearance Allocation - Loss of Appearance . . . . . . . 55 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 48
10.12. Appearance Selection Contention Race Condition . . . . . 56 10.12. Appearance Selection Contention Race Condition . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 50
11.1. SIP Event Package Parameter: shared . . . . . . . . . . . 58 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 58 11.1. SIP Event Package Parameter: shared . . . . . . . . . . . 52
11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 59 11.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 53
12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 59 11.3. XML Schema Registration . . . . . . . . . . . . . . . . . 53
13. Appendix B - Implementation Options Discussion . . . . . . . . 60 12. Appendix A - Incoming Appearance Assignment . . . . . . . . . 54
13.1. Appearance Implementation Options . . . . . . . . . . . . 60 13. Appendix B - Implementation Options Discussion . . . . . . . . 55
13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 60 13.1. Appearance Implementation Options . . . . . . . . . . . . 55
13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 61 13.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 55
13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 64 13.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 56
13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . 67 13.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 58
13.2.1. Comparison of Appearance Selection Methods . . . . . . 67 13.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . 61
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 13.2.1. Comparison of Appearance Selection Methods . . . . . . 62
15. Security Considerations . . . . . . . . . . . . . . . . . . . 69 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
16. Informative References . . . . . . . . . . . . . . . . . . . . 69 15. Security Considerations . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 16. Informative References . . . . . . . . . . . . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
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
fields, etc. Many of the popular business services have been fields, etc. Many of the popular business services have been
documented in the SIP Service Examples documented in the SIP Service Examples [RFC5359].
[I-D.ietf-sipping-service-examples].
This specification details a method for implementing a group This specification details a method for implementing a group
telephony feature known in telephony as Bridged Line Appearance (BLA) telephony feature known variously in telephony as Bridged Line
or Multiple Line Appearances (MLA), one of the more popular advanced Appearance (BLA) or Multiple Line Appearances (MLA), one of the more
features expected of SIP IP telephony devices in a business popular advanced features expected of SIP IP telephony devices in a
environment. Other names for this feature include Shared Call/Line business environment. Other names for this feature include Shared
Appearance (SCA), Shared Call Status and Multiple Call Appearance Call/Line Appearance (SCA), Shared Call Status and Multiple Call
(MCA). A variant of this feature is known as Single Line Extension. Appearance (MCA). A variant of this feature is known as Single Line
Extension.
This document looks at how this feature can be implemented using This document looks at how this feature can be implemented using
standard SIP [RFC3261] in conjunction with [RFC3265] and [RFC3903] standard SIP [RFC3261] in conjunction with SIP events [RFC3265] and
for exchanging status among user agents, and the SIP dialog state publication [RFC3903] for exchanging status among user agents, and
event package [RFC4235] to exchange dialog state information to the SIP dialog state event package [RFC4235] to exchange dialog state
achieve the same. Different approaches will be discussed including information to achieve the same. Different approaches will be
the use of URI parameters, feature tags, and dialog package discussed including the use of URI parameters, feature tags, and
extensions along with the strengths and weaknesses of the various dialog package extensions along with the strengths and weaknesses of
approaches. the various approaches.
A call flow for Single Line Extension was formerly included in the
SIP Service Examples [I-D.ietf-sipping-service-examples]. However,
the attempt to implement using standard SIP primitives ultimately
failed, leading to its removal from that document. This document
defines SIP extensions to implement this service.
In traditional telephony, the line is physical. A common scenario in In traditional telephony, the line is physical. A common scenario in
telephony is for a number of business telephones to share a single or telephony is for a number of business telephones to share a single or
a small number of lines. The sharing or appearance of these lines a small number of lines. The sharing or appearance of these lines
between a number of phones is what gives this feature its. A common 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 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 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
skipping to change at page 6, line 19 skipping to change at page 7, line 13
resulting in a conference call. resulting in a conference call.
3.3. Single Line Extension 3.3. Single Line Extension
In this scenario, incoming calls are offered to a group of UAs. When In this scenario, incoming calls are offered to a group of UAs. When
one answers, the other UAs are informed. If another UA in the group one answers, the other UAs are informed. If another UA in the group
selects the line (i.e. goes off hook), it is immediately bridged or selects the line (i.e. goes off hook), it is immediately bridged or
joined in with the call. This mimics the way residential telephone joined in with the call. This mimics the way residential telephone
extensions usually operate. extensions usually operate.
4. Requirements 4. Requirements and Implementation
The next section details the requirements and discusses the
implementation of the shared appearances of an AOR feature.
4.1. Requirements
The basic requirements of the shared appearance feature can be The basic requirements of the shared appearance feature can be
summarized as follows: summarized as follows:
REQ-1 Incoming calls to the AOR must be offered to a group of UAs and REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
can be answered by any of them. can be answered by any of them.
REQ-2 Each UA in the group must be able to learn the call status of REQ-2 Each UA in the group must be able to learn the call status of
the others in the group for the purpose of rendering this information the others in the group for the purpose of rendering this information
to the user. to the user.
skipping to change at page 7, line 46 skipping to change at page 8, line 44
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 4.2. Implementation
solution. Is this OK?
5. Normative Description
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
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.
- The SIP Replaces and Join header fields meets REQ-3. - The SIP Replaces and Join header fields meets REQ-3.
- The SIP Registration Package meets REQ-4. - The use of a State Agent for the Dialog Package meets REQ-4 and
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 dialog state The Appearance Agent learns the group state either dialog state
publications from members. publications from members.
skipping to change at page 8, line 43 skipping to change at page 9, line 31
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.
Figure 1 illustrates the SIP components involved in supporting these The next section discusses normal SIP operations used to implement
common requirements of the Shared Appearance using standard SIP parts of the shared appearance feature.
messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
+----------------------------+ +----+ 1. A UA is configured with the AOR of a shared appearance group. It
| | | | registers against the AOR, then attempts a dialog state
| Appearance Agent | | UA | subscription to the AOR. If the subscription fails, loops back
| | | | to itself, or returns a 482 Loop Detected, it knows there is no
+----------------------------+ +----+ State Agent, and hence no Appearance Agent and this feature is
^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE | not implemented.
| | |(Event:reg) | | registration sip:alice@example.com| 2. If the subscription receives a 200 OK, the UA knows there is a
| | V | | events V State Agent and that the feature is implemented. The UA then
| | +--------------------+ +----------+7)Query+--------+ follows the steps in this list.
| | | (example.com) | | |<===== | | 3. Information learned about the dialog state of other UAs in the
| | | |3) Store| Location | | Proxy | group is rendered to the user.
| | | Registrar |=======>| Service | | | 4. Incoming calls are forked to all UAs in the group, and any may
| | | | | |=====> | | answer. UAs receive a notification from the Appearance Agent
| | +--------------------+ +----------+8)Resp +--------+ indicating the appearance number to use in rendering the incoming
| | ^ ^ | | call. The UA will also receive a notification if the call is
| | | | 2) REGISTER (alice) | | answered by another UA in the group so this information can be
| | | | | | rendered to the user.
| | +----+ +----+ | |
| | | | | | | |
| | |UA1 | |UA2 | | |
| | | | | | | |
| | +----+ +----+ | |
| | ^ ^ ^ ^ | |
| | | | | | | |
| +----+ | | | | |
| | | +--------------------------------------+ |
| +----+-------------------------------------------+
| | 8) INVITE
+--------------+ sip:alice@example.com
5-7) SUBSCRIBE and/or PUBLISH
(Event:dialog)
OPEN ISSUE: This figure still shows the use of the registration event 5. For outgoing calls, the operation depends on the user input. If
package by the Appearance Agent - do we still need this? the user selects a particular appearance number for the call, the
UA publishes this information and waits for a 200 OK before
sending the INVITE.
6. For outgoing calls, if the user does not select a particular
appearance or does not care, the INVITE can be sent immediately,
and the appearance number learned as the call progresses from a
notification from the Appearance Agent.
7. For outgoing calls, if the user does not wish to select an
appearance (such as during a consultation call), the UA also
publishes this prior to sending the INVITE.
8. Established calls within the group may be joined (bridged) or
taken (picked) by another UA. Information in the dialog package
notifications can be used to construct Join or Replaces header
fields. Since the same appearance number is used for these types
of operations, this information is published prior to sending the
INVITE Join or INVITE Replaces.
9. In some cases, the Appearance Agent may not have full access to
the complete dialog state of some or all of the UAs in the group.
If this is the case, the Appearance Agent will subscribe to the
dialog state of individual UAs in the group to obtain this
information. Normal notifications will be sent every time the
dialog state changes, including calls placed, answered, placed on
and off hold, and hangups.
Figure 1. 5. Normative Description
The next section discusses normal SIP operations used to implement This section normatively describes the shared appearance feature
parts of the shared appearance feature. extensions. For a discussion of various approaches to implement this
feature, see Appendix B.
1. The Appearance Agent SUBSCRIBEs to the registration event package 5.1. Elements
as outlined in [RFC3680] for contacts registered to the group
AOR. Thus, it has knowledge of all User Agents registered
against the AOR at any point of time.
2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and,
after authentication, register against the same AOR (e.g.,
sip:alice@example.com).
3. Each registration is stored in the Location Service. A complete system to implement this feature consists of:
4. The registrar notifies the Appearance Agent of successful
registration at each UA.
5. UAs PUBLISH their dialog state to the State Agent in the
Appearance Agent.
6. The UAs SUBSCRIBE to the Appearance Agent for the state of all
dialogs as defined in [RFC3265]. The Request-URI of the
SUBSCRIBE could be either the AOR of the group or a provisioned
URI.
7. The UAs PUBLISH their dialog information to the Appearance Agent
every time their dialog state changes (i.e. send an INVITE, enter
alerting state, answer a call, terminate a call, etc.), pickups
or joins a call, or seizes/selects an appearance.
8. The Forking Proxy forks an incoming INVITE for the AOR address to
the registered user agents.
The Appearance Agent can select the appearance number for an incoming 1. User Agents that support publications, subscriptions, and
call notifications for the SIP dialog event package, and the shared
appearance dialog package extensions and behavior.
2. An Appearance Agent consisting of a State Agent for the dialog
event package that implements an Event State Compositor (ESC) and
the shared appearance dialog package extensions and behavior.
The Appearance Agent also has logic for assigning and releasing
appearance numbers, and resolving appearance number contention.
3. A forking proxy server that can communicate with the State Agent
4. A registrar that supports the registration event package.
OPEN ISSUE: Do we want to define another mode of operation in The behavior of these elements is described normatively in the
which UAs only PUBLISH to seize an appearance? This assumes the following sections after the definitions of the dialog package
Appearance Agent already knows about all dialogs related to the extensions.
AOR and could publish that information to the UAs in the shared
appearance group. This approach would simply UA operation and
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. Shared Appearance Dialog Package Extensions 5.2. Shared Appearance Dialog Package Extensions
This specification defines four new elements as extensions to the SIP This specification defines four new elements as extensions to the SIP
Dialog Event package [RFC3265]. The schema is defined in Section 6. Dialog Event package [RFC3265]. The schema is defined in Section 6.
The elements are <appearance>, <exclusive>, <joined-dialog>, and The elements are <appearance>, <exclusive>, <joined-dialog>, and
<replaced-dialog> which are sub-elements of the <dialog> element. <replaced-dialog> which are sub-elements of the <dialog> element.
5.2.1. The <appearance> element 5.2.1. The <appearance> element
skipping to change at page 12, line 6 skipping to change at page 12, line 24
the replacing dialog. Replaced dialogs will share the same the replacing dialog. Replaced dialogs will share the same
appearance number. appearance number.
5.3. Shared Appearance User Agents 5.3. Shared Appearance User Agents
User Agents that support the Shared Appearance feature MUST support User Agents that support the Shared Appearance feature MUST support
the dialog state package [RFC4235] with the shared appearance the dialog state package [RFC4235] with the shared appearance
extensions and the 'shared' dialog event package parameter defined in extensions and the 'shared' dialog event package parameter defined in
this draft. this draft.
User Agents MUST use the dialog package extensions in Section 5.2 User Agents MUST support the dialog package extensions in Section 5.2
along with the PUBLISH [RFC3903] method to send local status to the along with SUBSCRIBE and NOTIFY [RFC3265] and PUBLISH [RFC3903].
Appearance Agent, and SUBSCRIBE [RFC3265] to the Appearance Agent to SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package
learn the status of other User Agents in the group. SUBSCRIBE SHOULD include the 'shared' Event header field parameter.
requests MUST include the 'shared' Event package parameter.
The presence of the 'shared' Event package parameter in the
SUBSCRIBE tells the Appearance Agent that this UA supports this
specification.
PUBLISH requests SHOULD include the 'shared' Event package parameter, The presence of the 'shared' Event package parameter tells the
except when specified otherwise. The publication URI is either a Appearance Agent that this UA supports this specification.
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? Upon initialization and at regular intervals, the UA SHOULD subscribe
to the dialog event package of the AOR. If the SUBSCRIBE request
fails, loops back to itself, or returns a 482 Loop Detected, then no
Appearance Agent is present and this feature is not active for this
AOR. The UA MAY periodically retry the subscription to see if
conditions have changed.
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 with a Join [RFC3911] header
initiate bridging. User Agents MUST support receiving an INVITE with field to initiate bridging.
a Join header, though they are not obligated to support bridging of
calls, either through policy, preference, or implementation
limitations such as bandwidth or hardware constraints.
When publishing dialog package information, a UA MUST include all Note that the Join operation can be implemented outside the UA,
dialog identification available at the time of publication, with the for example, in a B2BUA. This is why UAs must support sending
exception that a UA may omit information if it wishes to prevent Join header fields even if they do not necessarily support
other UAs from joining or picking up a call. Dialog identification receiving them.
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 publishing or notifying dialog package information, a UA MUST
MUST be included in dialog package notifications. include all dialog identification available at the time of
publication, with the exception that a UA may omit information if it
wishes to prevent other UAs from joining or picking up a call.
Dialog identification 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 MUST be included in dialog package
notifications.
The accurate rendering of the idle/active/alerting/hold state of The accurate rendering of the idle/active/alerting/hold state of
other UAs in the group is an important part of the shared other UAs in the group is an important part of the shared
appearance feature. appearance feature.
A UA SHOULD render the appearance number to the user or display A UA MUST send dialog package PUBLISH requests in the following
appearance status information to the user in a way that preserves the situations:
appearance order.
A UA SHOULD send dialog package PUBLISH requests for the following 1. When the user selects a particular appearance number for an
events: outgoing call (i.e. seizing an appearance or going "off-hook"
with an appearance, if the UA's user interface uses this
metaphor).
2. When the user has requested that an appearance number not be used
for an outgoing call (i.e. during a consultation call or for a
call not considered part of the shared appearance group).
3. When the user has selected to join (or bridge) an existing call.
4. When the user has selected to replace (or take) an existing call.
1. When going selecting an appearance number (i.e. going "off-hook" In all these cases, the INVITE SHOULD NOT be sent until the 200 OK
if the UA's user interface uses this metaphor), response to the PUBLISH has been received, except for an emergency
2. When sending an outgoing INVITE, call, when a UA MUST never wait for a confirmed seizure before
3. When receiving a 18x response, sending an INVITE. Instead, the emergency call MUST proceed
4. When sending or receiving a 2xx response to an INVITE, regardless of the status of PUBLISH transaction.
5. When sending or receiving a BYE
A UA SHOULD NOT send dialog package PUBLISH requests when receiving Note that when a UA selects an appearance prior to establishment of a
an incoming INVITE or when sending a 18x response. dialog (#1 and #2 in above list), not all dialog information will be
available. In particular, when a UA publishes an attempt to select
an appearance prior to knowing the destination URI, minimal or no
dialog information may be available. For example, in some cases,
only the local target URI for the call will be known and no dialog
information. If no dialog identification information is present in
the initial PUBLISH, the UA MUST PUBLISH again after receiving the
100 Trying response.
A large group of UAs publishing in these conditions when an INVITE The first publication will cause the Appearance Agent to reserve
has forked will generate significant dialog package PUBLISH and the appearance number for this UA. If the publication does not
NOTIFY traffic that actually conveys no new information to other have any dialog identifiers (e.g. Call-ID, or local tag) the
UAs in the group. Appearance Agent cannot assign the appearance number to a
particular dialog of the UA until the second publication which
will contain some dialog identifiers.
UAs can tell that a set of dialogs are joined (bridged or mixed) This publication state SHOULD be refreshed during the early dialog
together by the presence of one or more <joined-dialog> elements state or the Appearance Agent may reassign the appearance number.
containing other SIP dialog identifiers.
Prior to placing an outbound call, UAs may select or "seize" an Once the dialog has transitioned to the confirmed state, no
appearance number by sending a PUBLISH to the Appearance Agent publication refreshes are necessary.
identifying the appearance number selected in an <appearance>
element. In traditional telephony terms, this corresponds to "going
off hook" with an analog telephone. Note that when a UA selects an
appearance prior to establishment of a dialog, not all dialog
information will be available. In particular, when a UA publishes an
attempt to select an appearance prior to knowing the destination very
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 UAs SHOULD render information about other appearances to the user.
before sending an INVITE. Instead, the emergency call MUST proceed This includes the state (idle, active, busy, joined, etc.). UAs can
regardless of the status of PUBLISH transaction. This requirement tell that a set of dialogs are joined (bridged or mixed) together by
applies to both clients and servers implementing this feature. the presence of one or more <joined-dialog> elements containing other
SIP dialog identifiers. A UA SHOULD render the appearance number to
the user or display appearance status information to the user in a
way that preserves the appearance order.
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 UA placing the call SHOULD PUBLISH after outbound call.
receiving a 1xx response to the INVITE. If the appearance number is
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.
The publication without the 'shared' event package parameter looks
identical to a publication from a UA which does not understand the
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 A UA wanting to place a call but not have an appearance number
assigned publishes before sending the INVITE without an 'appearance' assigned publishes before sending the INVITE without an 'appearance'
element but with the 'shared' event package parameter present. If element but with the 'shared' event package parameter present. If
the Appearance Agent policy does not allow calls without an assigned the Appearance Agent policy does not allow calls without an assigned
appearance number, a 409 Conflict response will be received, and the appearance number, a 409 Conflict response will be received, and the
UA will republish either selecting an appearance number or without UA will republish either selecting an appearance number or without
one, in which case the Appearance Agent will assign one. 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. When an INVITE is generated to attempt to bridge or take a call (i.e.
contains Join or Replaces with a dialog identifier of another dialog contains Join or Replaces with a dialog identifier of another dialog
in the shared appearance group), the appearance number of the joined in the shared appearance group), the appearance number of the joined
or replaced call SHOULD be used. In this case, the PUBLISH MUST be or replaced call SHOULD be used. The publication MUST contain the
sent prior to sending the INVITE. The publication MUST contain the
appearance number of the dialog to be joined or replaced and the appearance number of the dialog to be joined or replaced and the
dialog identifier in the 'joined-dialog' or 'replaced-dialog' dialog identifier in the 'joined-dialog' or 'replaced-dialog'
elements. The INVITE is sent after the receipt of a 200 OK to the elements.
PUBLISH.
For inbound calls which contain a reference to an appearance number Note that this information is provided to the Appearance Agent so
in the INVITE, a UA MUST PUBLISH the use of an appearance number that it can provide proper appearance assignment behavior. With
after it responds with a 2xx to establish a dialog. Join, the goal is to prevent the Appearance Agent from generating
a 409 Conflict response due to the reuse of an appearance number.
For Replaces, the goal is to prevent a race condition where the
BYE could cause the appearance number to be released when it
should stay with the replacing dialog.
A UA SHOULD register against the AOR only if it is likely the UA will A UA SHOULD register against the AOR only if it is likely the UA will
be answering incoming calls. If the UA is mainly going to be be answering incoming calls. If the UA is mainly going to be
monitoring the status of the shared appearance group calls and monitoring the status of the shared appearance group calls and
picking or joining calls, the UA SHOULD only subscribe to the picking or joining calls, the UA SHOULD only subscribe to the AOR and
Appearance Agent and not register against the AOR. not register against the AOR.
All subscribed UAs will received NOTIFYs of Trying state for All subscribed UAs will received NOTIFYs of Trying state for
incoming INVITEs. 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 Appearance Agent MUST support the appearance dialog package The Appearance Agent MUST support the appearance dialog package
extensions defined in Section 5.2. The Appearance Agent MUST support extensions defined in Section 5.2. The Appearance Agent MUST support
publications and subscriptions for this event package. publications and subscriptions for this event package.
The Appearance Agent MUST have a way of discovering the dialog The Appearance Agent MUST have a way of discovering the state of all
identifiers of incoming INVITEs. The Appearance Agent MUST allocate dialogs associated with the AOR. If this information is not
an appearance number for all incoming calls and send immediate available from a call stateful proxy or B2BUA, the Appearance Agent
notifications to the UAs subscribed to the shared group AOR. An MAY use the registration event package [RFC3680] to learn of UAs
Appearance Agent MAY assign an appearance number to an INVITE if a associated with the AOR and MAY subscribe to their dialog event
PUBLISH is not received for the dialog within a reasonable period of state. As a result, the registrar MUST support the registration
time. If the appearance group has non-shared appearance UAs, the event package. The Appearance Agent SHOULD send dialog event state
Appearance Agent MUST allocate appearance numbers for INVITEs sent by notifications whenever the following events happen to UAs in the AOR
those UAs. group:
Note that in general, the Appearance Agent makes appearance 1. A call is received, placed, answered, or terminated.
allocation decisions based on publications rather than on INVITEs. 2. A call is placed on or off hold.
3. A call is joined or replaced.
4. An appearance number is reserved or released.
The Appearance Agent MUST allocate an appearance number for all
incoming calls and send immediate notifications to the UAs subscribed
to the shared group AOR. The Appearance Agent MUST be able to
communicate with the forking proxy to learn about incoming calls and
also to pass the appearance number to the proxy to insert in the
Alert-Info header field.
An Appearance Agent SHOULD assign an appearance number to an outgoing
INVITE if a PUBLISH has not been received selecting a particular
appearance number.
Note that if the appearance group has non-shared appearance UAs,
the Appearance Agent will still allocate appearance numbers for
INVITEs sent by those UAs.
An Appearance Agent receiving a PUBLISH with an appearance number An Appearance Agent receiving a PUBLISH with an appearance number
checks to make sure the publication is valid. An appearance number checks to make sure the publication is valid. An appearance number
can be assigned to only one dialog unless there is a 'joined-dialog' can be assigned to only one dialog unless there is a 'joined-dialog'
or 'replaced-dialog' element indicating that the dialog will be/has or 'replaced-dialog' element indicating that the dialog will be/has
been replaced or joined. A 409 Conflict response is returned if the been replaced or joined. A 409 Conflict response is returned if the
chosen appearance number is invalid, and an immediate NOTIFY should chosen appearance number is invalid, and an immediate NOTIFY should
be sent to the UA. be sent to the UA containing full dialog event state.
An Appearance Agent receiving a PUBLISH without an appearance number
and without the 'shared' event package parameter checks to see if the
dialog already has an appearance number assigned to it. If it does,
it replies with 200 OK and updates the dialog information. If it
does not, the Appearance Agent assigns an available appearance
number, returns a 200 OK and NOTIFYs the other UAs in the group.
Note that this case could be a shared appearance unaware UA or a
UA that does not care what appearance number is used for the
dialog.
An Appearance Agent receiving a PUBLISH without an appearance number An Appearance Agent receiving a PUBLISH without an appearance number
but with the 'shared' event package parameter present interprets this but with the 'shared' event package parameter present interprets this
as a request by the UA to not assign an appearance number. If the as a request by the UA to not assign an appearance number. If the
Appearance Agent policy does not allow this, a 409 Conflict response Appearance Agent policy does not allow this, a 409 Conflict response
is returned. If policy does allow this, a 200 OK response is is returned. If policy does allow this, a 200 OK response is
returned and no appearance number is allocated. returned and no appearance number is allocated. In general, the
dialog state will not be shared with the other UAs in the group.
The Appearance Agent controls the rate of dialog state publication The Appearance Agent allocates an appearance number to a dialog from
using the Expires header field in 200 OK responses to PUBLISH the time the appearance is requested via a PUBLISH or from the
requests. The Appearance Agent MAY vary the expiration interval receipt of an INVITE, to the time when the last dialog associated
depending on the type of publication, or, an Appearance Agent MAY with the appearance is terminted, including all dialogs which are
just use the same interval for all publications. For publications of joined or replaced. During the early dialog state, the Appearance
trying, alerting, or connected state, an interval of 3 minutes is Agent controls the rate of dialog state publication using the Expires
RECOMMENDED. header field in 200 OK responses to PUBLISH requests. An interval of
3 minutes is RECOMMENDED. After the dialog associated with the
publication has been confirmed, the expiration of the publication
state has no effect on the appearance allocation. If the publication
contains no dialog state information, the Appearance Agent MUST
reserve the appearance number for the UA but can not assign the
appearance to any particular dialog of the UA. When the publication
state is updated with any dialog information, the appearance number
can then be assigned to the particular dialog.
During dynamic situations, such as during a call pickup or join During dynamic situations, such as during a call pickup or join
action, the Appearance Agent MAY choose to implement rate limiting to action, the Appearance Agent MAY choose to implement rate limiting to
reduce the amount of notification traffic. For example, an reduce the amount of notification traffic. For example, an
Appearance Agent may choose not to generate immediate NOTIFYs upon Appearance Agent may choose not to generate immediate NOTIFYs upon
receipt of PUBLISHes. Instead, a single NOTIFY can convey the receipt of PUBLISHes. Instead, a single NOTIFY can convey the
effects of a number of PUBLISHes, thus reducing the NOTIFY traffic effects of a number of PUBLISHes, thus reducing the NOTIFY traffic
within the group. within the group.
If an INVITE is sent and no appearance number is available, the proxy If an INVITE is sent and no appearance number is available, the proxy
skipping to change at page 17, line 12 skipping to change at page 17, line 12
is "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:element name="replaced-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>
skipping to change at page 21, line 24 skipping to change at page 21, line 26
will ignore appearance number limitations and may attempt to Join or will ignore appearance number limitations and may attempt to Join or
Replace dialogs marked exclusive. As a result, the Proxy or UAs may Replace dialogs marked exclusive. As a result, the Proxy or UAs may
need to 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. Previous versions of this draft required the URI of the Appearance
Agent be provisioned in each UA in the group. Since publication is
now done to the group URI, this provisioning is no longer necessary.
UAs can automatically discover if this feature is active for an AOR
by sending a SUBSCRIBE to the AOR, so no provisioning for this is
needed.
If the Appearance Agent needs to subscribe to the dialog state of the
UAs, then the Appearance Agent and the UAs need to be provisioned
with credentials so the UAs can authenticate the Appearance Agent.
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.
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. Alice REGISTERs Bob REGISTERs using contact sip:bob@ua2.example.com. Alice REGISTERs
skipping to change at page 22, line 18 skipping to change at page 22, line 31
| | | | | |
| |<----- SUBSCRIBE F3<| | |<----- SUBSCRIBE F3<|
| | | | | |
| |>F4 202 Accepted -->| | |>F4 202 Accepted -->|
| | | | | |
| |>F5 NOTIFY -------->| | |>F5 NOTIFY -------->|
| | | | | |
| |<-------- 200 OK F6<| | |<-------- 200 OK F6<|
| | | | | |
Figure 2. Figure 1.
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
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Max-Forwards: 70 Max-Forwards: 70
Expires: 3600 Expires: 3600
Content-Length: 0 Content-Length: 0
F2 Registrar ----> Alice F2 Registrar ----> Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com Call-ID: d3281184-518783de-cc23d6bb
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
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:alice@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:alice@example.com> To: <sip:alice@example.com>
CSeq: 1 SUBSCRIBE CSeq: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Event: dialog;shared Event: dialog;shared
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: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Call-ID: ef4704d9-bb68aa0b-474c9d94
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:alice@example.com>;tag=1636248422222257 To: <sip:alice@example.com>;tag=1636248422222257
Allow-Events: dialog Allow-Events: dialog
Expires: 3700 Expires: 3700
Contact: <sip:appearance-agent@stateagent.example.com> Contact: <sip:appearanceagent.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:alice@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
CSeq: 2 NOTIFY CSeq: 232 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active Subscription-State: active
Contact: <sip:appearance-agent@stateagent.example.com> Contact: <appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="40" version="40"
state="full" state="full"
entity="sip: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 appearanceagent.example.com;branch=z9hG4bK1846
From: <sip:alice@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: 232 NOTIFY
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Event: dialog;shared Event: dialog;shared
Content-Length: 0 Content-Length: 0
10.2. Appearance Selection for Incoming Call 10.2. Appearance Selection for Incoming Call
In the call flow below Bob and Alice are in an appearance group. In the call flow below Bob and Alice are in an appearance group.
Carol places a call to the appearance group AOR. The Appearance Carol places a call to the appearance group AOR. The Appearance
Agent sends NOTIFYs to Alice and Bob telling them what appearance the Agent sends NOTIFYs to Alice and Bob telling them what appearance the
call is using. Both Alice and Bob's devices are alerted of the call is using. Both Alice and Bob's devices are alerted of the
incoming call. Bob answers the call. He then places Carol on hold. incoming call. Bob answers the call.
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 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 send 200 OK responses to Carol. It is up to Carol to resolve this
to the Appearance Agent indicating that the selected appearance is in situation. Typically, Carol will send ACKs to both 200 OKs but send
use by their respective dialogs. The Appearance Agent can detect a BYE to terminate one of the dialogs. As a result, either Alice or
this since the Call-ID and remote-tag will be the same in both Bob will receive the BYE and publish that their dialog is over.
publications and should allow this for a period of time. It is up to However, if Carol answers both Alice and Bob and keeps both dialogs
Carol to resolve this situation. Typically, Carol will send ACKs to active, then the Appearance Agent will need to resolve the situation
both 200 OKs but send a BYE to terminate one of the dialogs. As a by moving either Alice or Bob's dialog to a different appearance.
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 All NOTIFY messages in the call flow below carry dialog events and
only dialog states are mentioned for simplicity. For brevity, the only dialog states are mentioned for simplicity. For brevity, the
details of some messages are not shown below. details of some messages are not shown below.
Forking Appearance Forking Appearance
Carol Proxy Agent Alice Bob Carol Proxy Agent Alice Bob
| | | | | | | | | |
|>F1 INVITE >| | | | |>F1 INVITE >| | | |
| |< - - - - - >| | | | |< - - - - - >| | |
| | |>F2 NOTIFY ----------->| | | |>F2 NOTIFY ----------->|
skipping to change at page 25, line 32 skipping to change at page 25, line 33
| | | | | | | | | |
| |>F8 INVITE (appearance=1) >| | | |>F8 INVITE (appearance=1) >| |
| | | | | | | | | |
| |<-------------------- Ringing 180 F9<| | |<-------------------- Ringing 180 F9<|
|< 180 F10 -<| | | | |< 180 F10 -<| | | |
| |<--------- 180 Ringing F11<| | | |<--------- 180 Ringing F11<| |
|< 180 F12 -<| | | | |< 180 F12 -<| | | |
| | | | | | | | | |
| |<------------------------ 200 OK F13<| | |<------------------------ 200 OK F13<|
|< 200 F14 -<| | | | |< 200 F14 -<| | | |
| | |<--------- PUBLISH F15<|
| | | | |
| | |>F16 200 OK ---------->|
| | | | | | | | | |
| |>F17 CANCEL -------------->| | | |>F15 CANCEL -------------->| |
| | | | | | | | | |
| |<-------------- 200 OK F18<| | | |<-------------- 200 OK F16<| |
| | | | | | | | | |
| |<Request Cancelled 487 F19<| | | |<Request Cancelled 487 F17<| |
| | | | | | | | | |
| |>F20 ACK ----------------->| | | |>F18 ACK ----------------->| |
|>F21 ACK -->| | | | |>F19 ACK -->| | | |
| |>F22 ACK --------------------------->| | |>F20 ACK --------------------------->|
| | | | | | | | | |
|<=============Both way RTP established===========>| |<=============Both way RTP established===========>|
| | | | | | | | | |
| | |>F23 NOTIFY >| | | | |>F21 NOTIFY >| |
| | | | | | | | | |
| | |<- 200 F24 -<| | | | |<- 200 F22 -<| |
| | | | | | | | | |
| | |>F25 NOTIFY ---------->| | | |>F23 NOTIFY ---------->|
| | | | | | | | | |
| | |<F26 200 OK ----------<| | | |<F24 200 OK ----------<|
| | | | | | | |
Figure 3. Figure 2.
F4 Appearance Agent ----> Alice F4 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:alice@example.com>;tag=151702541050937 From: <sip:alice@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sip:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 12 NOTIFY CSeq: 12 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active Subscription-State: active
Contact: <sip:appearance-agent@stateagent.example.com> Contact: <appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13" version="13"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c" <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345@example.com" call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42" remote-tag="44BAD75D-E3128D42"
direction="recipient"> direction="recipient">
<sa:appearance>1</appearance> <sa:appearance>1</appearance>
<state>trying</state> <state>trying</state>
<remote> <remote>
<identity>sip:carol@ua.example.com</identity> <identity>sip:carol@ua.example.com</identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F7 Proxy ----> Bob F7 Proxy ----> Bob
INVITE sip:alice@ua3.example.com SIP/2.0 INVITE sip:alice@ua3.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=44BAD75D-E3128D42 From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
To: <sip:alice@example.com> To: <sip:alice@example.com>
CSeq: 106 INVITE CSeq: 106 INVITE
Call-ID: 14-1541707345@example.com Call-ID: 14-1541707345
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> Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69 Max-Forwards: 69
Alert-Info: <file://ring.pcm>;alert=normal;appearance=1 Alert-Info: <file://ring.pcm>;alert=normal;appearance=1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 223 Content-Length: 223
v=0 v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com o=- 1102980499 1102980499 IN IP4 ua3.example.com
s= s=
c=IN IP4 ua3.example.com c=IN IP4 ua3.example.com
t=0 0 t=0 0
a=sendrecv a=sendrecv
m=audio 2238 RTP/AVP 0 8 101 m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
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 F21 Appearance Agent ----> Alice
PUBLILSH sip:appearance-agent@example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263 From: <sip:alice@example.com>;tag=151702541050937
From: <sip:bob@example.com>;tag=558C18F7-DB9DF7BC To: <sip:alice@example.com>;tag=18433323-C3D237CE
To: <sip:alice@example.com>;tag=1894685100249086 Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 14 PUBLISH CSeq: 12 NOTIFY
Call-ID: 77-505889516@example.com Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403
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
Event: dialog;shared
Subscription-State: active
Contact: <appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13" version="13"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="ida0f8dc17" <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345@example.com" call-id="14-1541707345"
local-tag="44BAD75D-E3128D42" remote-tag="44BAD75D-E3128D42"
remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" local-tag="7349dsfjkFD03s"
direction="recipient"> direction="recipient">
<sa:appearance>1</appearance> <sa:appearance>1</appearance>
<sa:exclusive>false</exclusive>
<state>confirmed</state> <state>confirmed</state>
<local>
<target uri="sip:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote> <remote>
<identity>sip:carol@ua.example.com</identity> <identity>sip:carol@ua.example.com</identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.3. Outgoing Call with Without Appearance Pre-Selection 10.3. Outgoing Call without Appearance Pre-Selection
In this scenario, Bob's UA places a call without first selecting an In this scenario, Bob's UA places a call without first selecting an
appearance number. After sending the INVITE, Bob sends out a dialog appearance number. After Bob sends the INVITE, the appearance
event PUBLISH with state (trying) but does not include an appearance assigns an appearance number for it and notifies both Alice and Bob.
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
| | | | | | | | | |
| | | | | | | | | |
| |<------------------------------------- INVITE F1<| | |<------------------------------------- INVITE F1<|
| | | | | | | | | |
| |>F2 100 Trying --------------------------------->| | |>F2 100 Trying --------------------------------->|
|<-- INVITE F3<| | | | |<-- INVITE F3<| | | |
| | | |<----- PUBLISH F4<| | | |<-- NOTIFY F4<| |
| | | | |
| | | |>F5 200 OK ------>|
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |<F9 200 OK ------<|
|>F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | |
| | | |<---- PUBLISH F12<|
| | | | | | | | | |
| | | |>F13 200 OK ----->| | | |>F5 200 OK -->| |
| | |<- NOTIFY F14<| | | | | |------- NOTIFY F6>|
| | | | | | | | | |
| | |>F15 200 OK ->| | | | | |<F7 200 OK ------<|
| | | |------ NOTIFY F16>| |>F8 180 ---->| | | |
| |>F9 180 Ringing -------------------------------->|
| | | | | | | | | |
| | | |<F17 200 OK -----<| | | |<- NOTIFY F10<| |
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | | | | | | |
| | | |<---- PUBLISH F20<| | | |>F11 200 OK ->| |
| | | |------ NOTIFY F12>|
| | | | | | | | | |
| | | |>F21 200 OK ----->| | | | |<F13 200 OK -----<|
|>F14 200 OK ->| | | |
| |>F15 200 OK ------------------------------------>|
| | | | | | | | | |
| |<--------------------------------------- ACK F22<| | |<--------------------------------------- ACK F16<|
|<---- ACK F23<| | | | |<---- ACK F17<| | | |
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| | |<- NOTIFY F18<| |
| | |<- NOTIFY F24<| |
| | | | | | | | | |
| | |>F25 200 OK ->| | | | |>F19 200 OK ->| |
| | | |------ NOTIFY F26>| | | | |------ NOTIFY F20>|
| | | | | | | | | |
| | | |<F27 200 OK -----<| | | | |<F21 200 OK -----<|
| | | | | | | | | |
Figure 3.
Figure 4.
F1 Bob ----> Proxy F1 Bob ----> Proxy
INVITE sip:carol@example.com SIP/2.0 INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: <sip:bob@example.com>;tag=15A3DE7C-9283203B From: <sip:bob@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com> To: <sip:carol@example.com>
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
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=- 1102980499 1102980499 IN IP4 ua2.example.com o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA s=IP SIP UA
c=IN IP4 ua2.example.com c=IN IP4 ua2.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
F4 Bob ----> Appearance Agent F6 Appearance Agent ----> Bob
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: 7 PUBLISH
Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog
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:exclusive>false</exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
F5 Appearance Agent ----> Bob
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
F8 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:bob@example.com>;tag=497585728578386 From: <sip:bob@example.com>;tag=497585728578386
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK1711759878512309
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active Subscription-State: active
Contact: <sip:appearance-agent@stateagent.example.com> Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" direction="initiator"> <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" 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@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F9 Bob ----> Appearance Agent 10.4. Outgoing Call with Appearance Pre-Selection
SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
From: <sip:bob@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
F20 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801
CSeq: 9 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="8"
state="partial"
entity="sip:alice@example.com">
<dialog id="id3d4f9c83"
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:exclusive>false</exclusive>
<local>
<target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" />
</remote>
</dialog>
</dialog-info>
10.4. Outgoing Call with Appearance Selection
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) selecting an appearance number before sending the state (trying) selecting an appearance number before sending the
INVITE. After receiving the 200 OK from the Appearance Agent INVITE. After receiving the 200 OK from the Appearance Agent
confirming the appearance number, Bob's UA sends the INVITE to Carol confirming the appearance number, Bob's UA sends the INVITE to Carol
and establishes a session. For brevity, details of some of the and establishes a session. For brevity, details of some of the
messages are not included in the message flows. messages are not included in the message flows.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| | | | |<----- PUBLISH F1<|
| | | | | | | | | |
| | | |>F2 200 OK ------>| | | | |>F2 200 OK ------>|
| | | | | | | | | |
| |<------------------------------------- INVITE F3<| | | |<-- NOTIFY F3<| |
| | | | | | | | | |
| |>F4 100 Trying --------------------------------->| | | |>F4 200 OK -->| |
|<-- INVITE F5<| | | | | | | |------- NOTIFY F5>|
| | |<-- NOTIFY F6<| |
| | | | | | | | | |
| | |>F7 200 OK -->| | | | | |<F6 200 OK ------<|
| | | |------- NOTIFY F8>|
| | | | | | | | | |
| | | |<F9 200 OK ------<| | |<------------------------------------- INVITE F7<|
|>F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | | | | | | |
| | | |<---- PUBLISH F12<| | |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | | | | | | |
| | | |>F13 200 OK ----->|
| | |<- NOTIFY F14<| | | | |<- NOTIFY F14<| |
| | | | | | | | | |
| | |>F15 200 OK ->| | | | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>| | | | |------ NOTIFY F16>|
| | | | | | | | | |
| | | |<F17 200 OK -----<| | | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | | |>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>| | |>F19 200 OK ------------------------------------>|
| | | | | | | | | |
| | | |<---- PUBLISH F20<| | |<--------------------------------------- ACK F20<|
| | | | | |<---- ACK F21<| | | |
| | | |>F21 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F22<|
|<---- ACK F23<| | | |
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| | |<- NOTIFY F24<| | | | |<- NOTIFY F22<| |
| | | | | | | | | |
| | |>F25 200 OK ->| | | | |>F23 200 OK ->| |
| | | |------ NOTIFY F26>| | | | |------ NOTIFY F24>|
| | | | | | | | | |
| | | |<F27 200 OK -----<| | | | |<F25 200 OK -----<|
| | | | | | | | | |
Figure 5. Figure 4.
F1 to F4: Bob uses the shared appearance appearance of Alice on his F1 to F4: Bob uses the shared appearance appearance of Alice on his
UA to place an outgoing call (e.g., he goes off-hook). Before UA to place an outgoing call (e.g., he goes off-hook). Before
sending the outgoing INVITE request, Bob publishes to the state agent sending the outgoing INVITE request, Bob publishes to the state agent
that Alice line appearance is in (trying) state. The Appearance that Alice line appearance is in (trying) state. The Appearance
Agent notifies Alice of the same event by forwarding the NOTIFY Agent notifies Alice of the same event by forwarding the NOTIFY
payload provided by Bob after appropriately changing the dialog id payload provided by Bob after appropriately changing the dialog id
field in the XML payload to a unique value towards each of the field in the XML payload to a unique value towards each of the
entities it is forwarding to (Alice in this example). Note 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 shortened expiration interval in F2 of 60 seconds. As long as Bob is
using the appearance number, he must refresh the publication every 60 using the appearance number, he must refresh the publication every 60
seconds or loose the appearance. seconds or loose the appearance.
F1 Bob ----> Appearance Agent F1 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0 PUBLISH sip:alice@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:alice@example.com>
CSeq: 7 PUBLISH CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog;shared Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6" version="6"
skipping to change at page 35, line 36 skipping to change at page 32, line 48
<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@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F2 Appearance Agent ----> Bob F10 Bob ----> Appearance Agent
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
F8 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0 PUBLISH sip:alice@example.com SIP/2.0
From: <sip:alice@example.com>;tag=497585728578386 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 From: <sip:bob@example.com>;tag=0CCf6-A7FdsB79D
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com To: <sip:alice@example.com>
CSeq: 7 NOTIFY CSeq: 437 PUBLISH
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 Call-ID: fwF14d4-F1FFF2F2893K38424
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
Event: dialog;shared
Subscription-State: active
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="6"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" direction="initiator"> <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
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@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F9 Bob ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
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
10.5. Outgoing Call without using an Appearance Number 10.5. Outgoing Call without using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' dialog event parameter. appearance element but does have the 'shared' dialog event parameter.
As a result, the Appearance Agent knows the UA does not wish to use As a result, the Appearance Agent knows the UA does not wish to use
an appearance number for this call. If the Appearance Agent does not an appearance number for this call. If the Appearance Agent does not
wish to allow this, it would reject the PUBLISH with a 409 Conflict wish to allow this, it would reject the PUBLISH with a 409 Conflict
response and the UA would know to re-PUBLISH selecting an appearance response and the UA would know to re-PUBLISH selecting an appearance
number. number.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| | | | |<----- PUBLISH F1<|
| | | | | | | | | |
| | | |>F2 200 OK ------>| | | | |>F2 200 OK ------>|
| | | | | | | | | |
| |<------------------------------------- INVITE F3<| | | |<-- NOTIFY F3<| |
| | | | | | | | | |
| |>F4 100 Trying --------------------------------->| | | |>F4 200 OK -->| |
|<-- INVITE F5<| | | | | | | |------- NOTIFY F5>|
| | |<-- NOTIFY F6<| |
| | | | | | | | | |
| | |>F7 200 OK -->| | | | | |<F6 200 OK ------<|
| | | |------- NOTIFY F8>|
| | | | | | | | | |
| | | |<F9 200 OK ------<| | |<------------------------------------- INVITE F7<|
|>F10 180 --->| | | |
| |>F11 180 Ringing ------------------------------->|
| | | | | | | | | |
| | | |<---- PUBLISH F12<| | |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | | | | | | |
| | | |>F13 200 OK ----->|
| | |<- NOTIFY F14<| | | | |<- NOTIFY F14<| |
| | | | | | | | | |
| | |>F15 200 OK ->| | | | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>| | | | |------ NOTIFY F16>|
| | | | | | | | | |
| | | |<F17 200 OK -----<| | | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | | |>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>| | |>F19 200 OK ------------------------------------>|
| | | | | | | | | |
| | | |<---- PUBLISH F20<| | |<--------------------------------------- ACK F20<|
| | | | | |<---- ACK F21<| | | |
| | | |>F21 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F22<|
|<---- ACK F23<| | | |
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| | |<- NOTIFY F24<| | | | |<- NOTIFY F22<| |
| | | | | | | | | |
| | |>F25 200 OK ->| | | | |>F23 200 OK ->| |
| | | |------ NOTIFY F26>| | | | |------ NOTIFY F24>|
| | | | | | | | | |
| | | |<F27 200 OK -----<| | | | |<F25 200 OK -----<|
| | | | | | | | | |
Figure 6. Figure 5.
F1 Bob ----> Appearance Agent F1 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0 PUBLISH sip:appearanceagent.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=4415df82k39sf
To: <sip:appearance-agent@example.com>;tag=428765950880801 To: <sip:alice@example.com>
CSeq: 7 PUBLISH CSeq: 7 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog;shared Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6" version="6"
skipping to change at page 39, line 17 skipping to change at page 35, line 42
Bob and Carol are in a dialog, created in one of the previous two 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 call flows. Carol sends a BYE to Bob to terminate the dialog. Bob
publishes the termination of the dialog and the Appearance Agent de- publishes the termination of the dialog and the Appearance Agent de-
allocates the appearance number used. allocates the appearance number used.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
|>F28 BYE ---->| | | | |>F22 BYE ---->| | | |
| |>F29 BYE --------------------------------------->| | |>F23 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ 200 OK F30<|
|<--200 OK F31<| | | |
| | | |<---- PUBLISH F32<|
| | | | | | | | | |
| | | |>F33 200 OK ----->| | |<------------------------------------ 200 OK F24<|
| | |<- NOTIFY F34<| | |<--200 OK F25<| | | |
| | |<- NOTIFY F26<| |
| | | | | | | | | |
| | |>F35 200 OK ->| | | | |>F27 200 OK ->| |
| | | |------ NOTIFY F36>| | | | |------ NOTIFY F28>|
| | | | | | | | | |
| | | |<F37 200 OK -----<| | | | |<F29 200 OK -----<|
Figure 7. Figure 6.
F32 Bob ----> Appearance Agent F28 Appearance Agent ----> Bob
PUBLISH sip:appearance-agent@example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 From: <sip:alice@example.com>;tag=497585728578386
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D To: <sip:bob@example.com>
To: <sip:appearance-agent@example.com>;tag=428765950880801 Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 37 PUBLISH CSeq: 7 NOTIFY
Call-ID: 65144-1289338424@example.com Via: SIP/2.0/UDP appearanceagent.example.com
Contact: <sip:bob@ua2.example.com> ;branch=z9hG4bK759878512309
Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6" version="27"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive>
<state>terminated</state> <state>terminated</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.7. Appearance Pickup 10.7. Appearance Pickup
In this scenario, Bob has an established dialog with Carol created In this scenario, Bob has an established dialog with Carol created
using the call flows of Figure 2 or Figure 3. Bob then places Carol using the call flows of Figure 1 or Figure 2. Bob then places Carol
on hold. Alice receives a notification of this and renders this on on hold. Alice receives a notification of this and renders this on
Alice's UI. Alice subsequently picks up the held call and has a Alice's UI. Alice subsequently picks up the held call and has a
established session with Carol. Finally, Carol hangs up. established session with Carol. Finally, Carol hangs up.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| |<------------------------------(hold) INVITE F28<| | |<------------------------------(hold) INVITE F22<|
|<- INVITE F29<| | | | |<- INVITE F23<| | | |
| | | | |
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | | | | | | |
| |<--------------------------------------- ACK F32<| |>F24 200 OK ->| | | |
|<---- ACK F33<| | | | | |>F25 200 OK ------------------------------------>|
| | | |<---- PUBLISH F34<|
| | | | | | | | | |
| | | |>F35 200 OK ----->| | |<--------------------------------------- ACK F26<|
| | |<- NOTIFY F36<| | |<---- ACK F27<| | | |
| | |<- NOTIFY F28<| |
| | | | | | | | | |
| | |>F37 200 OK ->| | | | |>F29 200 OK ->| |
| | | |>F38 NOTIFY ----->| | | | |>F30 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F39<| | | | |<----- 200 OK F31<|
| | | | | | | | | |
| | Alice decides to pick up the call | | | Alice decides to pick up the call |
| | | | | | | | | |
| | |>F40 PUBLISH->| | | | |>F32 PUBLISH->| |
| | | | | | | | | |
| | |<- 200 OK F41<| | | | |<- 200 OK F33<| |
| | | | | | | | | |
| | |<- NOTIFY F42<| | | | |<- NOTIFY F34<| |
| | | | | | | | | |
| | |>F43 200 OK ->| | | | |>F35 200 OK ->| |
| | | |>F44 NOTIFY ----->| | | | |>F36 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F45<| | | | |<----- 200 OK F37<|
| |<-- INVITE F46<| | | | |<-- INVITE F38<| | |
|<- INVITE F47<|(w/ Replaces) | | | |<- INVITE F39<|(w/ Replaces) | | |
|( w/ Replaces)| | | | |( w/ Replaces)| | | |
|>F48 200 OK ->| | | | |>F40 200 OK ->| | | |
| |>F49 200 OK -->| | | | |>F41 200 OK -->| | |
| | |>F50 PUBLISH->| | | | | |>F42 NOTIFY ----->|
| | | | |
| | |<- 200 OK F51<| |
| | | |>F52 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F53<| | | | |<----- 200 OK F43<|
| | |<- NOTIFY F54<| | | | |<- NOTIFY F44<| |
| | | | | | | | | |
| | |>F55 200 OK ->| | | | |>F45 200 OK ->| |
| | | | | | | | | |
| |<----- ACK F56<| | | | |<----- ACK F46<| | |
|<---- ACK F57<| | | | |<---- ACK F47<| | | |
| | | | | | | | | |
|<= Both way RTP established =>| | | |<= Both way RTP established =>| | |
| | | | | | | | | |
|>F58 BYE ---->| | | | |>F48 BYE ---->| | | |
| |>F59 BYE --------------------------------------->| | |>F49 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F60<|
|<- 200 OK F61<| | | |
| | | | | | | | | |
| | | |<---- PUBLISH F62<| | |<------------------------------------ OK 200 F50<|
|<- 200 OK F51<| | | |
| | | | | | | | | |
| | | |>F63 200 OK ----->| | | |<- NOTIFY F52<| |
| | |<- NOTIFY F64<| |
| | | | | | | | | |
| | |>F65 200 OK ->| | | | |>F53 200 OK ->| |
| | | | | | | | | |
| | | |>F66 NOTIFY ----->| | | | |>F54 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F67<| | | | |<----- 200 OK F55<|
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 Figure 7.
Alice of the same.
F34 Bob ----> Appearance Agent F28 Appearance ----> Alice
PUBLISH sip:appearance-agent@example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sip:alice@example.com>;tag=151702541050937
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D To: <sip:alice@example.com>;tag=18433323-C3D237CE
To: <sip:appearance-agent@example.com>;tag=428765950880801 Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 11 PUBLISH CSeq: 12 NOTIFY
Call-ID: 144-1289338424@example.com Via: SIP/2.0/UDP appearanceagent.example.com
Contact: <sip:bob@ua2.example.com> ;branch=z9hG4bK1403
Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:alice@example.com:5060"> entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator"> direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<state>active</state> <state>active</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="no"/>
</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>
F40 Alice ----> Appearance Agent F32 Alice ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0 PUBLISH sip:alice@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:alice@example.com>;tag=44150CC6-A7B7919D From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801 To: <sip:alice@example.com>;tag=428765950880801
CSeq: 11 PUBLISH CSeq: 11 PUBLISH
Call-ID: 1289338424@example.com Call-ID: 87837Fkw87asfds
Contact: <sip:alice@ua2.example.com> Contact: <sip:alice@ua2.example.com>
Event: dialog;shared Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:alice@example.com:5060"> entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83"> <dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" >
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<sa:replaced-dialog <sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
from-tag="15A3DE7C-9283203B" from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" /> to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sip:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<target uri="sip:carol@example.com" /> <target uri="sip:carol@example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F46: Alice picks up the held call by sending an INVITE with F38 Alice ----> Proxy
Replaces: header . Session is established between Alice and
Carol. The dialog between Carol and Bob is terminated.
F46 Bob ----> Proxy
INVITE sip:carol@example.com SIP/2.0 INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sip:alice@example.com>;tag=8C4183CB-BCEAB710 From: <sip:alice@example.com>;tag=8C4183CB-BCEAB710
To: <sip:carol@example.com:5075> To: <sip:carol@example.com:5075>
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com Call-ID: 3d57cd17-47deb849-dca8b6c6
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
<all-one-line> <all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line> </all-one-line>
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 223 Content-Length: 223
v=0 v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA s=IP SIP UA
c=IN IP4 ua1.example.com c=IN IP4 ua1.example.com
t=0 0 t=0 0
a=sendrecv a=sendrecv
m=audio 2238 RTP/AVP 0 8 101 m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
10.8. Calls between UAs within the Group 10.8. Calls between UAs within the Group
In this scenario, Bob calls Alice who is also in the Appearance In this scenario, Bob calls Alice who is also in the Appearance
group. He chooses to allocate an appearance. group.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| |<-------------------- INVITE (to Alice's UA) F1<| | |<-------------------- INVITE (to Alice's UA) F1<|
| | | | | | | | | |
| | | |<----- PUBLISH F2<| | |<- - - - - - ->| | |
| | | | |
| | | |>F3 200 OK ------>|
| | | | | | | | | |
| | |<-- NOTIFY F4<| | | | |<-- NOTIFY F2<| |
| | | | | | | | | |
| | |>F5 200 OK -->| | | | |>F3 200 OK -->| |
| | | |>F6 NOTIFY ------>| | | | |>F4 NOTIFY ------>|
| | | | | | | | | |
| | | |<------ 200 OK F7<| | | | |<------ 200 OK F5<|
| |>F8 INVITE --->| | | | |>F6 INVITE --->| | |
| | (appearance=1)| | | | | (appearance=1)| | |
| | | | | | | | | |
| |<------ 180 F9<| | | | |<------ 180 F7<| | |
| | | | |
| |>F10 180 -------------------------------------->|
| | | | |
| | | |<---- PUBLISH F11<|
| | | | |
| | | |>F12 200 OK ----->|
| | |<- NOTIFY F13<| |
| | | | |
| | |>F14 200 OK ->| |
| | | |>F15 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F16<|
| | | | | | | | | |
| |>F8 180 --------------------------------------->|
| | | | | | | | | |
| |<-- 200 OK F17<| | | | | |<-- NOTIFY F9<| |
| | |>F18 PUBLISH->| |
| | | | | | | | | |
| | |<- 200 OK F19<| | | | |>F10 200 OK ->| |
| | | |>F11 NOTIFY ----->|
| | | | | | | | | |
| | |<- NOTIFY F20<| | | | | |<----- 200 OK F12<|
| |<-- 200 OK F13<| | |
| | |<- NOTIFY F14<| |
| | | | | | | | | |
| | |>F21 200 OK ->| | | | |>F15 200 OK ->| |
| | | |>F22 NOTIFY ----->| | | | |>F16 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F23<| | | | |<----- 200 OK F17<|
| | | | | | | | | |
| |>F24 200 OK ------------------------------------>| | |>F18 200 OK ------------------------------------>|
| | | | | | | | | |
| |<--------------------------------------- ACK F25<| | |<--------------------------------------- ACK F19<|
| | | | | | | | | |
| |>F26 ACK ----->| | | | |>F20 ACK ----->| | |
| | | | | | | | | |
| | |<======= RTP established =======>| | | |<======= RTP established =======>|
| | | | | | | | | |
| | | |<---- PUBLISH F27<| | | |<- NOTIFY F21<| |
| | | | |
| | | |>F28 200 OK ----->|
| | |<- NOTIFY F29<| |
| | | | | | | | | |
| | |>F30 200 OK ->| | | | |>F22 200 OK ->| |
| | | |>F31 NOTIFY ----->| | | | |>F23 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F32<| | | | |<----- 200 OK F24<|
| | | | | | | | | |
Figure 9. Figure 8.
F2 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0 F16 Appearance Agent ----> Bob
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=497585728578386
To: <sip:appearance-agent@example.com>;tag=428765950880801 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
CSeq: 11 PUBLISH Call-ID: a7d559db-d6d7dcad-311c9e3a
Call-ID: 144-1289338424@example.com CSeq: 7 NOTIFY
Contact: <sip:bob@ua2.example.com> Via: SIP/2.0/UDP appearanceagent.example.com
Event: dialog ;branch=z9hG4bK1711759878512309
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared
Subscription-State: active
Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:alice@example.com:5060"> entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83" <dialog id="3xdsd4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5@ua2.example.com" call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B" local-tag="34322kdfr234f"
remote-tag="3153DE7C-928203B"
direction="initiator"> direction="initiator">
<sa:exclusive>true</exclusive> <sa:exclusive>true</exclusive>
<state>trying</state> <sa:appearance>1</appearance>
<state>connected</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:alice@example.com</identity> <identity>sip:alice@example.com</identity>
<target uri="sip:alice@example.com" /> <target uri="sip:alice@ua1.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info>
F6 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 id="4839589"
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" call-id="b3cbd0-ad2c5775e-5df9f8d5"
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" local-tag="3153DE7C-928203B"
direction="initiator"> remote-tag="34322kdfr234f"
direction="responder">
<sa:exclusive>true</exclusive> <sa:exclusive>true</exclusive>
<sa:appearance>1</appearance> <sa:appearance>1</appearance>
<state>trying</state> <state>connected</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:alice@ua1.example.com" />
</target>
</local> </local>
<remote> <remote>
<identity>sip:alice@example.com</identity> <identity>sip:alice@example.com</identity>
<target uri="sip:alice@example.com" /> <target uri="sip:bob@ua2.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.9. Consultation Hold with Appearances 10.9. Consultation Hold with Appearances
In this scenario, Bob has a call with Carol. Bob makes a In this scenario, Bob has a call with Carol. Bob makes a
consultation call to Alice by putting Carol on hold and calling consultation call to Alice by putting Carol on hold and calling
Alice. Bob chooses not to have an appearance number for the call to Alice. Bob chooses not to have an appearance number for the call to
Alice since he is treating it as part of the call to Carol. He Alice since he is treating it as part of the call to Carol. He
indicates this in his PUBLISH F34 which is sent before the INVITE to indicates this in his PUBLISH F32 which is sent before the INVITE to
Alice to ensure no appearance number is assigned by the Appearance Alice to ensure no appearance number is assigned by the Appearance
Agent. Finally, Bob hangs up with Alice and resumes the call with Agent. Finally, Bob hangs up with Alice and resumes the call with
Carol. Carol. Note that the Appearance Agent does not generate
notifications on the dialog state of the consultation call.
Note that if Carol hangs up while Bob is consulting with Alice, Bob Note that if Carol hangs up while Bob is consulting with Alice, Bob
can decide if he wants to reuse the appearance number used with Carol can decide if he wants to reuse the appearance number used with Carol
for the call with Alice. If not, Bob publishes the termination of for the call with Alice. If not, Bob publishes the termination of
the dialog with Carol and the Appearance Agent will re-allocate the the dialog with Carol and the Appearance Agent will re-allocate the
appearance. If he wants to keep the appearance, Bob will publish the appearance. If he wants to keep the appearance, Bob will publish the
termination of the dialog with Carol and also publish the appearance termination of the dialog with Carol and also publish the appearance
with the dialog with Alice. This will result in Bob keeping the with the dialog with Alice. This will result in Bob keeping the
appearance number until he reports the dialog with Alice terminated. appearance number until he reports the dialog with Alice terminated.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| |<------------------------------(hold) INVITE F28<| | |<------------------------------(hold) INVITE F22<|
|<- INVITE F29<| | | | |<- INVITE F23<| | | |
| | | | |
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | | | | | | |
| |<--------------------------------------- ACK F32<| |>F24 200 OK ->| | | |
|<---- ACK F33<| | | | | |>F25 200 OK ------------------------------------>|
| | | |<---- PUBLISH F34<|
| | | | | | | | | |
| | | |>F35 200 OK ----->| | |<--------------------------------------- ACK F26<|
| | |<- NOTIFY F36<| | |<---- ACK F27<| | | |
| | |<- NOTIFY F28<| |
| | | | | | | | | |
| | |>F37 200 OK ->| | | | |>F29 200 OK ->| |
| | | |>F38 NOTIFY ----->| | | | |>F30 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F39<| | | | |<----- 200 OK F31<|
| | | | | | | | | |
| | Bob makes a consultation call to Alice | | | Bob makes a consultation call to Alice |
| | | | | | | | | |
| | | |<---- PUBLISH F40<| | | | |<---- PUBLISH F32<|
| | | | |
| | | |>F41 200 OK ----->|
| | | | |
| |<------------------------------------ INVITE F42<|
| | | | |
| | |<- NOTIFY F43<| |
| | | | |
| | |>F44 200 OK ->| |
| | | |>F45 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F46<|
| |>F47 INVITE -->| | |
| | | | |
| |<-- 200 OK F48<| | |
| | |>F49 PUBLISH->| |
| | | | | | | | | |
| | |<- 200 OK F50<| | | | | |>F33 200 OK ----->|
| | | | | | | | | |
| | |<- NOTIFY F51<| | | |<------------------------------------ INVITE F34<|
| | | | | | | | | |
| | |>F52 200 OK ->| | | |>F35 INVITE -->| | |
| | | |>F53 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F54<| | |<-- 200 OK F36<| | |
| | | | | | | | | |
| |>F55 200 OK ------------------------------------>| | |>F37 200 OK ------------------------------------>|
| | | | | | | | | |
| |<--------------------------------------- ACK F56<| | |<--------------------------------------- ACK F38<|
| | | | | | | | | |
| |>F57 ACK ----->| | | | |>F39 ACK ----->| | |
| | | | | | | | | |
| | |<======= RTP established =======>| | | |<======= RTP established =======>|
| | | | | | | | | |
| | | |<---- PUBLISH F58<|
| | | | |
| | | |>F59 200 OK ----->|
| | |<- NOTIFY F60<| |
| | | | |
| | |>F61 200 OK ->| |
| | | |>F62 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F63<|
| | | | |
| | Bob hangs up with Alice | | | Bob hangs up with Alice |
| | | | | | | | | |
| |<--------------------------------------- BYE F64<| | |<--------------------------------------- BYE F40<|
| | | | |
| | | |<---- PUBLISH F65<|
| | | | |
| | | |>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 ->| | | |>F41 BYE ----->| | |
| | | |>F84 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F85<| | |<-- 200 OK F42<| | |
| | | | | | | | | |
| |<----------------------------(unhold) INVITE F86<| | |>F43 200 OK ------------------------------------>|
|<- INVITE F87<| | | |
| | | | | | | | | |
|>F88 200 OK ->| | | | | |<----------------------------(unhold) INVITE F44<|
| |>F89 200 OK ------------------------------------>| |<- INVITE F45<| | | |
| | | | | | | | | |
| |<--------------------------------------- ACK F90<| |>F46 200 OK ->| | | |
|<---- ACK F91<| | | | | |>F47 200 OK ------------------------------------>|
| | | |<---- PUBLISH F92<|
| | | | | | | | | |
| | | |>F93 200 OK ----->| | |<--------------------------------------- ACK F48<|
| | |<- NOTIFY F94<| | |<---- ACK F49<| | | |
| | |<- NOTIFY F50<| |
| | | | | | | | | |
| | |>F95 200 OK ->| | | | |>F51 200 OK ->| |
| | | |>F96 NOTIFY ----->| | | | |>F52 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F97<| | | | |<----- 200 OK F53<|
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
Figure 10. Figure 9.
F40 Bob ----> Appearance Agent F32 Bob ----> Appearance Agent
PUBLISH sip:appearance-agent@example.com SIP/2.0 PUBLISH sip:alice@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
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:alice@example.com>;tag=428765950880801
CSeq: 11 PUBLISH CSeq: 11 PUBLISH
Call-ID: 144-1289338424@example.com Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Event: dialog;shared Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:alice@example.com:5060"> entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5@ua2.example.com" call-id="b3cbd0-ad2c5775e-5df9f8d5"
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" local-tag="3153DE7C-928203B"
direction="initiator"> direction="initiator">
<sa:exclusive>true</exclusive> <sa:exclusive>true</exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:alice@example.com</identity> <identity>sip:alice@example.com</identity>
skipping to change at page 52, line 25 skipping to change at page 46, line 9
In this call flow, a call answered by Bob is joined by Alice or In this call flow, a call answered by Bob is joined by Alice or
"bridged". The Join header field is used by Alice to request this "bridged". The Join header field is used by Alice to request this
bridging. If Bob did not support media mixing, Bob could obtain bridging. If Bob did not support media mixing, Bob could obtain
conferencing resources as described in [RFC4579]. conferencing resources as described in [RFC4579].
Carol Forking Proxy Appearance Agent Alice Bob Carol Forking Proxy Appearance Agent Alice Bob
| | | | | | | | | |
|<=============Both way RTP established===========>| |<=============Both way RTP established===========>|
| | | | | | | | | |
| | |< PUBLISH F28| | | | |< PUBLISH F22| |
| | | | |
| | |>F29 200 OK >| |
| | | | |
| |<---- INVITE (w/ Join) F30<| |
| | | | |
| |>F31 INVITE (w/Join)---------------->|
| | | | |
| | |>F32 NOTIFY >| |
| | | | |
| | |< 200 OK F33<| |
| | | | |
| | |>F34 NOTIFY ---------->|
| | | | |
| | |<F35 200 OK ----------<|
| | | | |
| |<---- OK 200 Contact:Bob;isfocus F36<|
| | | | |
| | |<--------- PUBLISH F37<|
| | | | |
| | |>F38 200 OK ---------->|
| | | | |
| | |>F39 NOTIFY >| |
| | | | |
| | |< 200 OK F40<| |
| | | | | | | | | |
| | |>F41 NOTIFY ---------->| | | |>F23 200 OK >| |
| | | | | | | | | |
| | |<F42 200 OK ----------<| | |<---- INVITE (w/ Join) F24<| |
| | | | | | | | | |
| |>F43 200 OK Contact:B----->| | | |>F25 INVITE (w/Join)---------------->|
| | | | | | | | | |
| | |< PUBLISH F44| | | |<---- OK 200 Contact:Bob;isfocus F26<|
| | | | | | | | | |
| | |>F45 200 OK >| | | | |>F27 NOTIFY >| |
| | | | | | | | | |
| | |>F46 NOTIFY >| | | | |< 200 OK F28<| |
| | | | | | | | | |
| | |< 200 OK F47<| | | | |>F29 NOTIFY ---------->|
| | | | | | | | | |
| | |>F48 NOTIFY ---------->| | | |<F30 200 OK ----------<|
| | | | | | | | | |
| | |<F49 200 OK ----------<| | |>F31 200 OK Contact:B----->| |
| | | | | | | | | |
| |<----------------- ACK F50<| | | |<----------------- ACK F32<| |
| | | | | | | | | |
| |>ACK F51---------------------------->| | |>ACK F33---------------------------->|
| | | | | | | | | |
| |<-----INVITE Contact:Bob;isfocus F52<| | |<-----INVITE Contact:Bob;isfocus F34<|
|<-INVITE F53| | | | |<-INVITE F35| | | |
| | | | | | | | | |
|>F54 200 -->| | | | |>F26 200 -->| | | |
| |>F55 200 OK ------------------------>| | |>F37 200 OK ------------------------>|
| | | | | | | | | |
| |<--------------------------- ACK F56<| | |<--------------------------- ACK F38<|
|<--- ACK F57| | | | |<--- ACK F39| | | |
| | | |<==RTP==>| | | | |<==RTP==>|
|<=============Both way RTP established===========>| |<=============Both way RTP established===========>|
| | | | | | | | | |
| | |<--------- PUBLISH F58<| | | |>F40 NOTIFY >| |
| | | | |
| | |>F59 200 OK ---------->|
| | | | |
| | |>F60 NOTIFY >| |
| | | | | | | | | |
| | |< 200 OK F61<| | | | |< 200 OK F41<| |
| | | | | | | | | |
| | |>F62 NOTIFY ---------->| | | |>F42 NOTIFY ---------->|
| | | | | | | | | |
| | |<F63 200 OK ----------<| | | |<F43 200 OK ----------<|
| | | | | | | | | |
Figure 10.
Figure 11. F22 Alice ----> Appearance Agent
F28 Alice ----> Appearance Agent PUBLISH sip:alice@example.com SIP/2.0
PUBLISH sip:appearance-agent@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:alice@example.com>;tag=44150CC6-A7B7919D From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
To: <sip:appearance-agent@example.com>;tag=428765950880801 To: <sip:alice@example.com>;tag=428765950880801
CSeq: 11 PUBLISH CSeq: 11 PUBLISH
Call-ID: 1289338424@example.com Call-ID: 87837Fkw87asfds
Contact: <sip:alice@ua2.example.com> Contact: <sip:alice@ua2.example.com>
Event: dialog;shared Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:alice@example.com:5060"> entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83"> <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" >
<sa:appearance>0</appearance> <sa:appearance>0</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<sa:joined-dialog <sa:joined-dialog
call-id="14-1541707345@example.com" call-id="14-1541707345"
from-tag="44BAD75D-E3128D42" from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sip:alice@ua1.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<target uri="sip:bob@example.com" /> <target uri="sip:bob@example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F20 Alice ----> Proxy F24 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
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
<all-one-line> <all-one-line>
Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5 Join: 14-1541707345;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
skipping to change at page 56, line 11 skipping to change at page 49, line 11
terminated and frees up the appearance using NOTIFYs R24 and F26. terminated and frees up the appearance using NOTIFYs R24 and F26.
After retransmitting the NOTIFY F26 to Bob, the subscription is After retransmitting the NOTIFY F26 to Bob, the subscription is
terminated. terminated.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| | | | |<----- PUBLISH F1<|
| | | | | | | | | |
| | | |>F2 200 OK ------>| | | | |>F2 200 OK ------>|
| | | | | | | | | |
| |<------------------------------------- INVITE F3<| | | |<-- NOTIFY F3<| |
| | | | | | | | | |
| |>F4 100 Trying --------------------------------->| | | |>F4 200 OK -->| |
|<-- INVITE F5<| | | | | | | |------- NOTIFY F5>|
| | |<-- NOTIFY F6<| |
| | | | | | | | | |
| | |>F7 200 OK -->| | | | | |<F6 200 OK ------<|
| | | |------- NOTIFY F8>|
| | | | | | | | | |
| | | |<F9 200 OK ------<| | |<------------------------------------- INVITE F7<|
|>F10 180 --->| | | | | | | | |
| |>F11 180 Ringing ------------------------------->| | |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | | | | | | |
| | | | Bob goes offline | | | | Bob goes offline
| | | | | | | |
| | | Appearance selection times out | | | Appearance selection times out
| | | | | | | |
| | | | | | | |
| | |<- NOTIFY F24<| | | |<- NOTIFY F14<|
| | | | | | | |
| | |>F25 200 OK ->| | | |>F15 200 OK ->|
| | | |------ NOTIFY F26> | | | |------ NOTIFY F16>
| | | | | | | |
| | | NOTIFY is retransmitted | | | NOTIFY is retransmitted
Figure 12. Figure 11.
10.12. Appearance Selection Contention Race Condition 10.12. Appearance Selection Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the Bob and Alice both try to reserve appearance 2 by publishing at the
same time. The Appearance Agent allocates the appearance to Bob by same time. The Appearance Agent allocates the appearance to Bob by
sending a 200 OK and denies it to Alice by sending a 409 Conflict. sending a 200 OK and denies it to Alice by sending a 409 Conflict.
After the NOTIFY F24, Alice learns that Bob is using appearance 2. After the NOTIFY F24, Alice learns that Bob is using appearance 2.
Alice republishes for appearance 3 which is accepted. Alice republishes for appearance 3 which is accepted.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| | | | |<----- PUBLISH F1<|
| | | | (appearance=2) | | | | (appearance=2)
| | |>F2 PUBLISH ->| | | | |>F2 PUBLISH ->| |
| | | (appearance=2) | | | | (appearance=2) |
| | | | | | | | | |
| | | |>F2 200 OK ------>| | | | |>F3 200 OK ------>|
| | |<---- F3 409 <| | | | |<---- F4 409 <| |
| | | | | | | | | |
| | |<-- NOTIFY F4<| | | | |<-- NOTIFY F5<| |
| | | | | | | | | |
| | |>F5 200 OK -->| | | | |>F6 200 OK -->| |
| | | |------- NOTIFY F6>| | | | |------- NOTIFY F7>|
| | | | | | | | | |
| | | |<F7 200 OK ------<| | | | |<F8 200 OK ------<|
| | | | | | | | | |
| |<------------------------------------- INVITE F8<| | |<------------------------------------- INVITE F9<|
| | | | | | | | | |
| |>F9 100 Trying --------------------------------->| | |>F10 100 Trying -------------------------------->|
|<- INVITE F10<| | | | |<- INVITE F11<| | | |
| | |>F11 PUBLISH->| | | | | |<---- PUBLISH F12<|
| | | | (appearance=2)
| | | |>F13 200 OK ----->|
| | |>F14 PUBLISH->| |
| | | (appearance=3) | | | | (appearance=3) |
| | | | | | | | | |
| | |<--- F12 200 <| | | | |<--- F15 200 <| |
| | | | | | | | | |
| | |<- NOTIFY F13<| | | | |<- NOTIFY F16<| |
| | | | | | | | | |
| |>F14 200 OK ->| | | |>F17 200 OK ->| |
Dave | | |------ NOTIFY F15>| Dave | | |------ NOTIFY F18>|
| | | | | | | | | |
| | | |<F16 200 OK -----<| | | | |<F19 200 OK -----<|
| |<----------------- INVITE F17<| | | |<-- INVITE F20<| | |
| | | | |
| |>F21 100 ----->| | |
|<- INVITE F22<| | | |
Figure 12.
10.13. Appearance Agent Subscription to UAs
In this scenario, the Appearance Agent does not have any way of
knowing Bob's dialog state information, except through Bob. This
could be because the Appearance Agent is not part of a B2BUA, or
perhaps Bob is remotely registering. When Bob registers, the
Appearance Agent receives a registration event package notification
from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's
dialog event state. Whenever Bob's dialog state changes, a NOTIFY is
sent to the Appearance Agent who then notifies the other other UAs in
the group.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| |<----------------------------------- REGISTER F1<|
| | | | |
| |>F2 200 OK ------------------------------------->|
| | | | |
| |>F3 NOTIFY ------------------>| |
| | | | |
| |<------------------ 200 OK F4<| |
| | | |---- SUBSCRIBE F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| | | |<------ NOTIFY F7<|
| | | | |
| | | |>F8 200 OK ------>|
| | | | |
| | | |<--- SUBSCRIBE F9<|
| | | | |
| | | |>F10 200 OK ----->|
| | | | |
| | | |------ NOTIFY F11>|
| | | | |
| | | |<F12 200 OK -----<|
| | | | |
| |<------------------------------------ INVITE F13<|
| | | | |
| |>F14 100 Trying -------------------------------->|
|<- INVITE F15<| | | |
| | | |<----- NOTIFY F16<|
| | | | |
| | | |>F17 200 OK ----->|
| | |<- NOTIFY F18<| |
| | | | |
| | |>F19 200 OK ->| |
| | | |------ NOTIFY F20>|
| | | | |
| | | |<F21 200 OK -----<|
|>F22 180 --->| | | |
| |>F23 180 Ringing ------------------------------->|
| | | | |
| | | |<----- NOTIFY F24<|
| | | | |
| | | |>F25 200 OK ----->|
| | |<- NOTIFY F26<| |
| | | | |
| | |>F27 200 OK ->| |
| | | |------ NOTIFY F28>|
| | | | |
| | | |<F29 200 OK -----<|
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | |
| | | |<----- NOTIFY F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F34<|
|<---- ACK F35<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | |<- NOTIFY F36<| |
| | | | |
| | |>F37 200 OK ->| |
| | | |------ NOTIFY F38>|
| | | | |
| | | |<F39 200 OK -----<|
| | | | | | | | | |
| |>F18 100 Trying ------------->| |
|<- INVITE F19<| | | |
Figure 13. Figure 13.
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: shared 11.1. SIP Event Package Parameter: shared
skipping to change at page 58, line 17 skipping to change at page 53, line 7
This specification also defines a new event parameter 'shared' for This specification also defines a new event parameter 'shared' for
the Dialog Package. When used in a NOTIFY, it indicates that the the Dialog Package. When used in a NOTIFY, it indicates that the
notifier supports the shared appearance feature. When used in a notifier supports the shared appearance feature. When used in a
PUBLISH, it indicates that the publisher has explicit appearance PUBLISH, it indicates that the publisher has explicit appearance
information contained in the message body. If not present in a information contained in the message body. If not present in a
PUBLISH, the Appearance Agent MAY assign an appearance number to any PUBLISH, the Appearance Agent MAY assign an appearance number to any
new dialogs in the message body. 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
[RFC3688]. in [RFC3688].
URI: urn:ietf:params:xml:ns:sa-dialog-info. URI: urn:ietf:params:xml:ns:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan@sipstation.com> Alan Johnston <alan@sipstation.com>
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 59, line 7 skipping to change at page 53, line 38
<h1>Namespace for Shared Appearance Dialog Information</h1> <h1>Namespace for Shared Appearance Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2> <h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfcXXXX.txt"> <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfcXXXX.txt">
RFCXXXX</a>.</p> RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
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 <xref target='schema' />. The XML for this schema can be found in Section 6.
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 60, line 37 skipping to change at page 55, line 24
This section discusses some options on how to implement the Shared This section discusses some options on how to implement the Shared
Appearances feature in SIP. This section is non-normative. Appearances feature in SIP. This section is non-normative.
13.1. Appearance Implementation Options 13.1. Appearance Implementation Options
This section discusses and compares two methods of implementing, This section discusses and compares two methods of implementing,
conveying, and selecting appearances in SIP while meeting the conveying, and selecting appearances in SIP while meeting the
requirements of Section 4. One approach involves a URI parameter and requirements of Section 4. One approach involves a URI parameter and
is discussed in section 5.1.1. The other approach uses a SIP dialog is discussed in section 5.1.1. The other approach uses a SIP dialog
package extension parameter and is discussed in section 5.1.2. Both package extension parameter and is discussed in section 5.1.2. Both
approaches assume the common elements and operations of Figure 1. In approaches assume an Appearance Agent. In addition, this section
addition, this section discusses approaches for incoming appearance discusses approaches for incoming appearance indication, REQ-9, and
indication, REQ-9, and appearance contention, REQ-8. These appearance contention, REQ-8. These approaches will be discussed for
approaches will be discussed for an example appearance group of N an example appearance group of N phones each with n line appearances.
phones each with n line appearances. The usage of the word phone The usage of the word phone does not imply that this feature is
does not imply that this feature is limited to telephony devices. limited to telephony devices.
13.1.1. URI parameter Approach 13.1.1. URI parameter Approach
Some implementations of this feature utilize a URI parameter such as Some implementations of this feature utilize a URI parameter such as
"line=3" on the Contact URI. Each appearance is effectively a "line=3" on the Contact URI. Each appearance is effectively a
logical UA, so each line appearance requires a separate registration. logical UA, so each line appearance requires a separate registration.
The number of line appearances needs to be provisioned on each phone. The number of line appearances needs to be provisioned on each phone.
Each appearance also requires a separate dialog package subscription. Each appearance also requires a separate dialog package subscription.
Even using a State Agent for the dialog package, each phone must Even using a State Agent for the dialog package, each phone must
maintain n subscriptions to the dialog package. maintain n subscriptions to the dialog package.
This results in 2nN total subscriptions and nN registrations for this This results in 2nN total subscriptions and nN registrations for this
implementation. implementation.
Since Contact URI parameters will be conveyed by the dialog package, Since Contact URI parameters will be conveyed by the dialog package,
REQ-7 is met. REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
skipping to change at page 62, line 11 skipping to change at page 56, line 33
Instead of the URI parameter approach, consider an extension Instead of the URI parameter approach, consider an extension
parameter "appearance" to the SIP dialog package. The e.g.: parameter "appearance" to the SIP dialog package. The e.g.:
<?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" from-tag="3423" to-tag="a3f423j88uju1" <dialog id="id3d4f9c83" from-tag="3423"
direction="initiator"> to-tag="a3f423j88uju1" direction="initiator">
<sa:appearance>2</appearance> <sa:appearance>2</appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</exclusive>
<sa:joined-dialog call-id="sdfg" from-tag="832d1" to-tag="4542454" /> <sa:joined-dialog call-id="sdfg" from-tag="832d1"
<sa:joined-dialog call-id="873287876" from-tag="433" to-tag="jwjwuf5" /> to-tag="4542454" />
<sa:joined-dialog call-id="873287876" from-tag="433"
to-tag="jwjwuf5" />
<state>connected</state> <state>connected</state>
<local> <local>
<target uri="sip:bob@pc.example.com" /> <target uri="sip:bob@pc.example.com" />
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
... ...
In this approach, the appearance number is never carried in a In this approach, the appearance number is never carried in a
Request-URI or Contact URI. Instead, it is only present in dialog Request-URI or Contact URI. Instead, it is only present in dialog
skipping to change at page 69, line 49 skipping to change at page 64, line 28
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004. September 2004.
[I-D.ietf-sipping-service-examples] [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-15 (work in Examples", BCP 144, RFC 5359, October 2008.
progress), July 2008.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005. Protocol (SIP)", RFC 4235, November 2005.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004. (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", (SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
Authors' Addresses Authors' Addresses
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
skipping to change at page 71, line 4 skipping to change at page 65, line 17
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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 319 change blocks. 
1075 lines changed or deleted 817 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/