draft-ietf-bliss-shared-appearances-03.txt   draft-ietf-bliss-shared-appearances-04.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Expires: January 14, 2010 M. Soroushnejad Expires: April 29, 2010 M. Soroushnejad
V. Venkataramanan V. Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
July 13, 2009 October 26, 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-03 draft-ietf-bliss-shared-appearances-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 January 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
4. Requirements and Implementation . . . . . . . . . . . . . . . 7 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9
5. Normative Description . . . . . . . . . . . . . . . . . . . . 10 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 12
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 12 5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 12
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 12 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 12
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 16 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 17
7. User Interface Considerations . . . . . . . . . . . . . . . . 18 7. User Interface Considerations . . . . . . . . . . . . . . . . 19
7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 18 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 19
7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 18 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 19
7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 18 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 19
7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 18 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 19
7.1.4. Shared Appearance UAs with Variable Appearance 7.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 19 Number . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 19 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 20
8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 20 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 21
8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 20 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 21
8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 20 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 21
8.3. UAs Supporting Dialog Events but Not Shared Appearance . 21 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 22
9. Provisioning Considerations . . . . . . . . . . . . . . . . . 21 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 22
10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 21 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 22
10.1. Registration and Subscription . . . . . . . . . . . . . . 21 10.1. Registration and Subscription . . . . . . . . . . . . . . 23
10.2. Appearance Selection/Seizure for Incoming Call . . . . . 25 10.2. Appearance Selection for Incoming Call . . . . . . . . . 26
10.3. Outgoing Call without Appearance Pre-Selection/Seizure . 29 10.3. Outgoing Call without Appearance Seizure . . . . . . . . 30
10.4. Outgoing Call with Appearance Pre-Selection/Seizure . . . 32 10.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 33
10.5. Outgoing Call without using an Appearance Number . . . . 36 10.5. Outgoing Call without using an Appearance Number . . . . 37
10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 38 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 39
10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 39 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 40
10.8. Calls between UAs within the Group . . . . . . . . . . . 43 10.8. Calls between UAs within the Group . . . . . . . . . . . 44
10.9. Consultation Hold with Appearances . . . . . . . . . . . 45 10.9. Consultation Hold with Appearances . . . . . . . . . . . 47
10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 48 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 49
10.11. Appearance Allocation - Loss of Appearance . . . . . . . 51 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 52
10.12. Appearance Selection/Seizure Contention Race Condition . 52 10.12. Appearance Seizure Contention Race Condition . . . . . . 53
10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 53 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 54
10.14. Appearance Pickup Race Condition Failure . . . . . . . . 55 10.14. Appearance Pickup Race Condition Failure . . . . . . . . 56
10.15. Appearance Selection/Seizure Incoming/Outgoing 10.15. Appearance Seizure Incoming/Outgoing Contention Race
Contention Race Condition . . . . . . . . . . . . . . . . 58 Condition . . . . . . . . . . . . . . . . . . . . . . . . 59
11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 59 11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 60
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
12.1. SIP Event Package Parameter: shared . . . . . . . . . . . 60 12.1. SIP Event Package Parameter: shared . . . . . . . . . . . 61
12.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 61 12.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 62
12.3. XML Schema Registration . . . . . . . . . . . . . . . . . 61 12.3. XML Schema Registration . . . . . . . . . . . . . . . . . 62
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
14. Security Considerations . . . . . . . . . . . . . . . . . . . 62 14. Security Considerations . . . . . . . . . . . . . . . . . . . 63
15. Informative References . . . . . . . . . . . . . . . . . . . . 63 15. Informative References . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 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
[RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911] header [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces
fields, etc. Many of the popular business services have been [RFC3891], and Join [RFC3911] header fields, etc. Many of the
documented in the SIP Service Examples [RFC5359]. popular business services have been documented in the SIP Service
Examples [RFC5359].
This specification details a method for implementing a group This specification details a method for implementing a group
telephony feature known variously in telephony as Bridged Line telephony feature known variously in telephony as Bridged Line
Appearance (BLA) or Multiple Line Appearances (MLA), one of the more Appearance (BLA) or Multiple Line Appearances (MLA), one of the more
popular advanced features expected of SIP IP telephony devices in a popular advanced features expected of SIP IP telephony devices in a
business environment. Other names for this feature include Shared business environment. Other names for this feature include Shared
Call/Line Appearance (SCA), Shared Call Status and Multiple Call Call/Line Appearance (SCA), Shared Call Status and Multiple Call
Appearance (MCA). A variant of this feature is known as Single Line Appearance (MCA). A variant of this feature is known as Single Line
Extension. 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 SIP events [RFC3265] and standard SIP [RFC3261] in conjunction with SIP events
publication [RFC3903] for exchanging status among user agents, and [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for
the SIP dialog state event package [RFC4235] to exchange dialog state exchanging status among user agents, and the SIP dialog state event
information to achieve the same. Different approaches will be package [RFC4235] to exchange dialog state information to achieve the
discussed including the use of URI parameters, feature tags, and same. Different approaches will be discussed including the use of
dialog package extensions along with the strengths and weaknesses of URI parameters, feature tags, and dialog package extensions along
the various approaches. with the strengths and weaknesses of the various approaches.
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 name. A between a number of phones is what gives this feature its name. A
common scenario in SIP is for a number of business telephones to common scenario in SIP is for a number of business telephones to
share a single or a small number of Address of Record (AOR) URIs. In share a single or a small number of Address of Record (AOR) URIs. In
addition, an AOR can have multiple appearances on a single UA in addition, an AOR can have multiple appearances on a single UA in
terms of the user interface. The appearance number relates to the terms of the user interface. The appearance number relates to the
user interface for the telephone - typically each appearance or an user interface for the telephone - typically each appearance or an
skipping to change at page 7, line 9 skipping to change at page 7, line 11
phone in the IT work area. A call answered on one phone can be put phone in the IT work area. A call answered on one phone can be put
on hold and picked up on another phone. A shout or an IM to another on hold and picked up on another phone. A shout or an IM to another
staff member can result in them taking over a call on a particular staff member can result in them taking over a call on a particular
appearance. Another phone can request to be added, joined, or appearance. Another phone can request to be added, joined, or
bridged to an existing appearance resulting in a conference call. bridged to an existing appearance 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/seizes the line (i.e. goes off hook), it is immediately seizes the line (i.e. goes off hook), it is immediately bridged or
bridged or joined in with the call. This mimics the way residential joined in with the call. This mimics the way residential telephone
telephone extensions usually operate. extensions usually operate.
4. Requirements and Implementation 4. Requirements and Implementation
The next section details the requirements and discusses the The next section details the requirements and discusses the
implementation of the shared appearances of an AOR feature. implementation of the shared appearances of an AOR feature.
4.1. Requirements 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:
skipping to change at page 8, line 20 skipping to change at page 8, line 23
alerting. alerting.
REQ-10 The mechanism must have a way of reconstructing appearance REQ-10 The mechanism must have a way of reconstructing appearance
state after an outage that does not result in excessive traffic and state after an outage that does not result in excessive traffic and
processing. processing.
REQ-11 The mechanism must have backwards compatibility such that a UA REQ-11 The mechanism must have backwards compatibility such that a UA
which is unaware of the feature can still register against the group which is unaware of the feature can still register against the group
AOR and make and receive calls. AOR and make and receive calls.
REQ-12 The mechanism must not allow UAs outside the group to select/ REQ-12 The mechanism must not allow UAs outside the group to select,
seize or manipulate appearance numbers. seize or manipulate appearance numbers.
REQ-13 For privacy reasons, there must be a mechanism so that REQ-13 For privacy reasons, there must be a mechanism so that
appearance information is not leaked outside the group of UAs. (e.g. appearance information is not leaked outside the group of UAs. (e.g.
"So who do you have on line 1?") "So who do you have on line 1?")
REQ-14 The mechanism must support a way for UAs to request REQ-14 The mechanism must support a way for UAs to request
exclusivity on a line appearance. Exclusivity means that the UA exclusivity on a line appearance. Exclusivity means that the UA
requesting it desires to have a private conversation with the requesting it desires to have a private conversation with the
external party and other UAs must not be allowed to be joined or external party and other UAs must not be allowed to be joined or
taken. Exclusivity may be requested at the start of an incoming or taken. Exclusivity may be requested at the start of an incoming or
outgoing session or during the session. An exclusivity request may outgoing session or during the session. An exclusivity request may
be accepted or rejected by the entity providing the shared appearance be accepted or rejected by the entity providing the shared appearance
service. Therefore, the mechanism must provide a way of service. Therefore, the mechanism must provide a way of
communicating the result back to the requester UA. communicating the result back to the requester UA.
REQ-15 The mechanism should support a way for a UA to select/seize a REQ-15 The mechanism should support a way for a UA to seize 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/seize a REQ-16 The mechanism should support a way for a UA to seize a
particular appearance number and also send the request at the same particular appearance number and also send the request at the same
time. This is needed when 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.
4.2. Implementation 4.2. 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:
skipping to change at page 9, line 40 skipping to change at page 9, line 47
would need to be defined and implemented. would need to be defined and implemented.
The next section discusses the operations used to implement parts of The next section discusses the operations used to implement parts of
the shared appearance feature. An analysis of other mechanisms has the shared appearance feature. An analysis of other mechanisms has
been performed, with the mechanism described here best meeting the been performed, with the mechanism described here best meeting the
requirements of Section 4.1. requirements of Section 4.1.
1. A UA is configured with the AOR of a shared appearance group. It 1. A UA is configured with the AOR of a shared appearance group. It
registers against the AOR, then attempts a dialog state registers against the AOR, then attempts a dialog state
subscription to the AOR. If the subscription fails, loops back subscription to the AOR. If the subscription fails, loops back
to itself, or returns a 482 Loop Detected, it knows there is no to itself, or returns an error, it knows there is no State Agent,
State Agent, and hence no Appearance Agent and this feature is and hence no Appearance Agent and this feature is not
not implemented. implemented.
2. If the subscription receives a 200 OK, the UA knows there is a 2. If the subscription receives a 200 OK, the UA knows there is a
State Agent and that the feature is implemented. The UA then State Agent and that the feature is implemented. The UA then
follows the steps in this list. follows the steps in this list.
3. Information learned about the dialog state of other UAs in the 3. Information learned about the dialog state of other UAs in the
group is rendered to the user. group is rendered to the user.
4. Incoming calls are forked to all UAs in the group, and any may 4. Incoming calls are forked to all UAs in the group, and any may
answer. UAs receive the appearance number to use in rendering answer. UAs receive the appearance number to use in rendering
the incoming call in a NOTIFY from the Appearance Agent and in the incoming call in a NOTIFY from the Appearance Agent and in
the INVITE itself. The UA will also receive a notification if the INVITE itself. The UA will also receive a notification if
the call is answered by another UA in the group so this the call is answered by another UA in the group so this
information can be rendered to the user. information can be rendered to the user.
5. For outgoing calls, the operation depends on the implementation. 5. For outgoing calls, the operation depends on the implementation.
If the user selects/seizes a particular appearance number for the If the user seizes a particular appearance number for the call,
call, the UA publishes this information and waits for a 200 OK the UA publishes this information and waits for a 200 OK before
before sending the INVITE. sending the INVITE.
6. For outgoing calls, if the user does not select/seize a 6. For outgoing calls, if the user does not seize a particular
particular appearance or does not care, the INVITE can be sent appearance or does not care, the INVITE can be sent immediately,
immediately, and the appearance number learned as the call and the appearance number learned as the call progresses from a
progresses from a notification from the Appearance Agent. notification from the Appearance Agent.
7. For outgoing calls, if the user does not wish to select/seize an 7. For outgoing calls, if the user does not wish to seize an
appearance (such as during a consultation call), the UA also appearance (such as during a consultation call), the UA also
publishes this prior to sending the INVITE. publishes this prior to sending the INVITE.
8. Established calls within the group may be joined (bridged) or 8. Established calls within the group may be joined (bridged) or
taken (picked) by another UA. Information in the dialog package taken (picked) by another UA. Information in the dialog package
notifications can be used to construct Join or Replaces header notifications can be used to construct Join or Replaces header
fields. Since the same appearance number is used for these types fields. Since the same appearance number is used for these types
of operations, this information is published prior to sending the of operations, this information is published prior to sending the
INVITE Join or INVITE Replaces. INVITE Join or INVITE Replaces.
9. In some cases, the Appearance Agent may not have full access to 9. 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. 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 If this is the case, the Appearance Agent will subscribe to the
dialog state of individual UAs in the group to obtain this dialog state of individual UAs in the group to obtain this
information. Normal notifications will be sent every time the information. Normal notifications will be sent every time the
dialog state changes, including calls placed, answered, placed on dialog state changes, including calls placed, answered, placed on
and off hold, and hangups. and off hold, and hangups.
5. Normative Description 5. Normative Description
This section normatively describes the shared appearance feature This section normatively describes the shared appearance feature
extensions. extensions. The following definitions are used throughout this
document:
Seizing: An appearance can be reserved prior to a call being placed
by seizing the appearance. An appearance can be seized by
communicating an artificial state of "trying" prior to actually
initiating a dialog, in order to appear as it was already initiating
a dialog. The appearance number is confirmed prior to sending the
INVITE.
Selecting(or Not-Seizing): An appearance is merely selected (i.e.,
not seized) if there is no such communication of artificial state of
"trying" prior to initiating a dialog: i.e., the state is
communicated when the dialog is actually initiated. The appearance
number is learned after the INVITE is sent. This is a user interface
only issue.
5.1. Elements 5.1. Elements
A complete system to implement this feature consists of: A complete system to implement this feature consists of:
1. User Agents that support publications, subscriptions, and 1. User Agents that support publications, subscriptions, and
notifications for the SIP dialog event package, and the shared notifications for the SIP dialog event package, and the shared
appearance dialog package extensions and behavior. appearance dialog package extensions and behavior.
2. An Appearance Agent consisting of a State Agent for the dialog 2. An Appearance Agent consisting of a State Agent for the dialog
event package that implements an Event State Compositor (ESC) and event package that implements an Event State Compositor (ESC) and
skipping to change at page 11, line 10 skipping to change at page 11, line 32
3. A forking proxy server that can communicate with the State Agent 3. A forking proxy server that can communicate with the State Agent
4. A registrar that supports the registration event package. 4. A registrar that supports the registration event package.
The behavior of these elements is described normatively in the The behavior of these elements is described normatively in the
following sections after the definitions of the dialog package following sections after the definitions of the dialog package
extensions. extensions.
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 [I-D.ietf-sipcore-rfc3265bis]. The schema is
The elements are <appearance>, <exclusive>, <joined-dialog>, and defined in Section 6. The elements are <appearance>, <exclusive>,
<replaced-dialog> which are sub-elements of the <dialog> element. <joined-dialog>, and <replaced-dialog> which are sub-elements of the
<dialog> element.
5.2.1. The <appearance> element 5.2.1. The <appearance> element
The <appearance> element is used to convey the appearance number. The <appearance> element is used to convey the appearance number.
The appearance number is a non-negative integer. When sent in a The appearance number is a non-negative integer. When sent in a
publication in state Trying to the Appearance Agent, it is used to publication in state Trying to the Appearance Agent, it is used to
request an appearance number. When sent by the Appearance Agent, it request an appearance number. When sent by the Appearance Agent, it
indicates that the appearance number is associated with a dialog. indicates that the appearance number is associated with a dialog.
5.2.2. The <exclusive> element 5.2.2. The <exclusive> element
skipping to change at page 12, line 25 skipping to change at page 12, line 48
appearance number. appearance number.
5.3. Shared Appearance User Agents 5.3. Shared Appearance User Agents
User Agents that support the Shared Appearance feature MUST support User Agents that support the Shared Appearance feature MUST support
the dialog state package [RFC4235] with the shared appearance the dialog state package [RFC4235] with the shared appearance
extensions and the 'shared' dialog event package parameter defined in extensions and the 'shared' dialog event package parameter defined in
Section 11. Section 11.
User Agents MUST support the dialog package extensions in Section 5.2 User Agents MUST support the dialog package extensions in Section 5.2
along with SUBSCRIBE and NOTIFY [RFC3265] and PUBLISH [RFC3903]. along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and
SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the
SHOULD include the 'shared' Event header field parameter. dialog event package SHOULD include the 'shared' Event header field
parameter.
The presence of the 'shared' Event package parameter tells the The presence of the 'shared' Event package parameter tells the
Appearance Agent that this UA supports this specification. Appearance Agent that this UA supports this specification.
Upon initialization, the UA SHOULD subscribe to the dialog event Upon initialization, the UA SHOULD subscribe to the dialog event
package of the AOR and refresh the subscription per RFC 3265. If the package of the AOR and refresh the subscription per the SIP Events
SUBSCRIBE request fails, loops back to itself, or returns a 482 Loop Framework. If the SUBSCRIBE request fails, loops back to itself,
Detected, then no Appearance Agent is present and this feature is not then no Appearance Agent is present and this feature is not active
active for this AOR. The UA MAY periodically retry the subscription for this AOR. The UA MAY periodically retry the subscription to see
to see if conditions have changed. if conditions have changed.
OPEN ISSUE: Do we need to specifically call out the 482 response,
or is just saying if the request fails or loops, to give up?
User Agents SHOULD support sending and receiving an INVITE with a
Replaces [RFC3891] header to allow the Call Pickup operation. User
Agents SHOULD support sending an INVITE with a Join [RFC3911] header
field to initiate bridging. UAs SHOULD either support receiving a
Join header field or be configured to use a conference server or
B2BUA which supports the Join header field.
OPEN ISSUE: Replaces and Join support is a SHOULD. This means User Agents which implement call pickup, joining and bridging MUST
that taking and bridging/joining calls could fail if the UA does support sending an INVITE with Replaces [RFC3891] or Join [RFC3911].
not support them. Can we make these a MUST so that we can avoid All User Agents supporting INVITE MUST support receiving an INVITE
these failures? with a Replaces [RFC3891] or a Join [RFC3911] header field.
When publishing or notifying dialog package information, a UA MUST When publishing or notifying dialog package information, a UA MUST
include all dialog identification available at the time of include all dialog identification available at the time of
publication, with the exception that a UA may omit information if it publication, with the exception that a UA may omit information if it
wishes to prevent other UAs from joining or picking up a call. wishes to prevent other UAs from joining or picking up a call.
Dialog identification includes local and remote target URIs, call-id, Dialog identification includes local and remote target URIs, call-id,
to-tag, and from-tag. When calls are placed on hold, the to-tag, and from-tag. When calls are placed on hold, the
"+sip.rendering=no" feature tag MUST be included in dialog package "+sip.rendering=no" feature tag MUST be included in dialog package
notifications. notifications.
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 MUST send dialog package PUBLISH requests in the following A UA MUST send dialog package PUBLISH requests in the following
situations: situations:
1. When the user selects/seizes a particular appearance number for 1. When the user seizes a particular appearance number for an
an outgoing call (i.e. seizing the appearance and going "off- outgoing call (i.e. seizing the appearance and going "off-hook",
hook", if the UA's user interface uses this metaphor). if the UA's user interface uses this metaphor).
2. When the user has requested that an appearance number not be used 2. When the user has requested that an appearance number not be used
for an outgoing call (i.e. during a consultation call or for a for an outgoing call (i.e. during a consultation call or for a
call not considered part of the shared appearance group). call not considered part of the shared appearance group).
3. When the user has selected to join (or bridge) an existing call. 3. When the user has selected to join (or bridge) an existing call.
4. When the user has selected to replace (or take) an existing call. 4. When the user has selected to replace (or take) an existing call.
In all these cases, the INVITE SHOULD NOT be sent until the 200 OK In all these cases, the INVITE SHOULD NOT be sent until the 200 OK
response to the PUBLISH has been received, except for an emergency response to the PUBLISH has been received, except for an emergency
call, when a UA MUST never wait for a confirmed seizure before call, when a UA MUST never wait for a confirmed seizure before
sending an INVITE. Instead, the emergency call MUST proceed sending an INVITE. Instead, the emergency call MUST proceed
regardless of the status of PUBLISH transaction. regardless of the status of PUBLISH transaction.
Note that when a UA selects/seizes an appearance prior to Note that when a UA seizes an appearance prior to establishment of a
establishment of a dialog (#1 and #2 in above list), not all dialog dialog (#1 and #2 in above list), not all dialog information will be
information will be available. In particular, when a UA publishes an available. In particular, when a UA publishes an attempt to seize an
attempt to select/seize an appearance prior to knowing the appearance prior to knowing the destination URI, minimal or no dialog
destination URI, minimal or no dialog information may be available. information may be available. For example, in some cases, only the
For example, in some cases, only the local target URI for the call local target URI for the call will be known and no dialog
will be known and no dialog information. If no dialog identification information. If no dialog identification information is present in
information is present in the initial PUBLISH, the UA MUST PUBLISH the initial PUBLISH, the UA MUST PUBLISH again after receiving the
again after receiving the 100 Trying response. 100 Trying response.
The first publication will cause the Appearance Agent to reserve The first publication will cause the Appearance Agent to reserve
the appearance number for this UA. If the publication does not the appearance number for this UA. If the publication does not
have any dialog identifiers (e.g. Call-ID, or local tag) the have any dialog identifiers (e.g. Call-ID, or local tag) the
Appearance Agent cannot assign the appearance number to a Appearance Agent cannot assign the appearance number to a
particular dialog of the UA until the second publication which particular dialog of the UA until the second publication which
will contain some dialog identifiers. will contain some dialog identifiers.
This publication state SHOULD be refreshed during the early dialog This publication state SHOULD be refreshed during the early dialog
state or the Appearance Agent may reassign the appearance number. state or the Appearance Agent may reassign the appearance number.
skipping to change at page 14, line 23 skipping to change at page 14, line 36
tell that a set of dialogs are joined (bridged or mixed) together by tell that a set of dialogs are joined (bridged or mixed) together by
the presence of one or more <joined-dialog> elements containing other the presence of one or more <joined-dialog> elements containing other
SIP dialog identifiers. A UA SHOULD render the appearance number to SIP dialog identifiers. A UA SHOULD render the appearance number to
the user or display appearance status information to the user in a the user or display appearance status information to the user in a
way that preserves the appearance order. Appearance numbers of way that preserves the appearance order. Appearance numbers of
dialogs can be learned by dialog package notifications containing the dialogs can be learned by dialog package notifications containing the
<appearance> element from the Appearance Agent or from the <appearance> element from the Appearance Agent or from the
'appearance' Alert-Info parameter in an incoming INVITE. Should they 'appearance' Alert-Info parameter in an incoming INVITE. Should they
conflict, the dialog package notification takes precedence. conflict, the dialog package notification takes precedence.
A UA that does not need to select/seize a particular appearance A UA that does not need to seize a particular appearance number (or
number (or doesn't care) would just send an INVITE as normal to place doesn't care) would just send an INVITE as normal to place an
an outbound call. outbound call.
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/seizing an appearance number or UA will republish either selecting/seizing an appearance number or
without one, in which case the Appearance Agent will assign one. without one, in which case the Appearance Agent will assign one.
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.
skipping to change at page 18, line 48 skipping to change at page 19, line 48
call waiting. They have a very simple user interface that allows call waiting. They have a very simple user interface that allows
them to switch between two appearances (toggle or flash hook) and them to switch between two appearances (toggle or flash hook) and
perhaps audible tones to indicate the status of the other appearance. perhaps audible tones to indicate the status of the other appearance.
7.1.3. Shared Appearance UAs with Fixed Appearance Number 7.1.3. Shared Appearance UAs with Fixed Appearance Number
This UA is the typical 'business-class' hard-phone. A number of This UA is the typical 'business-class' hard-phone. A number of
appearances are typically configured statically and labeled on appearances are typically configured statically and labeled on
buttons, and calls may be managed using these configured appearances. buttons, and calls may be managed using these configured appearances.
Any calls outside this range should be ignored, and not mapped to a Any calls outside this range should be ignored, and not mapped to a
free button. Users of these devices often select/seize specific free button. Users of these devices often seize specific appearance
appearance numbers for outgoing calls, and the UA will need to numbers for outgoing calls, and the UA will need to seize the
select/seize the appearance number and wait for confirmation from the appearance number and wait for confirmation from the Appearance Agent
Appearance Agent before proceeding with calls. before proceeding with calls.
OPEN ISSUE: We currently have no upper limit on the appearance
number in the specification. Do we need a way for an Appearance
Agent to indicate to a UA that no more appearances are available?
7.1.4. Shared Appearance UAs with Variable Appearance Number 7.1.4. Shared Appearance UAs with Variable Appearance Number
This UA is typically a soft-phone or graphically rich user interface This UA is typically a soft-phone or graphically rich user interface
hard-phone. In these cases, even the idea of an appearance index may hard-phone. In these cases, even the idea of an appearance index may
seem unnecessary. However, for these phones to be able to interwork seem unnecessary. However, for these phones to be able to interwork
successfully with other phone types, it is important that they still successfully with other phone types, it is important that they still
use the appearance index to govern the order of appearance of calls use the appearance index to govern the order of appearance of calls
in progress. No specific guidance on presentation is given except in progress. No specific guidance on presentation is given except
that the order should be consistent. Thought should also be given to that the order should be consistent. Thought should also be given to
skipping to change at page 21, line 31 skipping to change at page 22, line 28
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
UAs can automatically discover if this feature is active for an AOR UAs can automatically discover if this feature is active for an AOR
by sending a SUBSCRIBE to the AOR, so no provisioning for this is by sending a SUBSCRIBE to the AOR, so no provisioning for this is
needed. needed.
The registrar will need to be provisioned to accept third part The registrar will need to be provisioned to accept either first or
registrations for the shared AOR. Either the credentials of the third party registrations for the shared AOR. First party
shared AOR or the user SHOULD be accepted by the registrar and the registration means the To and From URIs in the REGISTER request are
Appearance Agent. the shared AOR URI. Third party registration means the To URI is the
shared AOR URI and the From URI is a different AOR, perhaps that of
the individual user. Either the credentials of the shared AOR or the
user MUST be accepted by the registrar and the Appearance Agent,
depending on the authorization policy in place for the domain.
If the Appearance Agent needs to subscribe to the dialog state of the 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 UAs, then the Appearance Agent and the UAs need to be provisioned
with credentials so the UAs can authenticate the Appearance Agent. 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.
Note that the first twelve examples assume the Appearance Agent is
aware of dialog state events. Example 10.13 shows the case where
this is not the case and as a result the Appearance Agent initiates a
subscription to users of the shared AOR. Any of the other call flow
examples could have shown this mode of operation as it is equally
valid.
10.1. Registration and Subscription 10.1. Registration and Subscription
Bob and Alice are in an appearance group identified by the shared Bob and Alice are in an appearance group identified by the shared
appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact
sip:bob@ua2.example.com. Alice REGISTERs with contact sip:bob@ua2.example.com. Alice REGISTERs with contact
sip:alice@ua1.example.com. sip:alice@ua1.example.com.
User Agents for Alice and Bob subscribe to the dialog package for the User Agents for Alice and Bob subscribe to the dialog package for the
appearance AOR and publish dialog state to the Appearance Agent. appearance AOR and publish dialog state to the Appearance Agent.
Message exchanges between the Registrar, Appearance Agent, Alice, and Message exchanges between the Registrar, Appearance Agent, Alice, and
skipping to change at page 22, line 27 skipping to change at page 23, line 34
Registrar Appearance Agent Alice Bob Registrar Appearance Agent Alice Bob
| | | | | | | |
| | | | | | | |
|<--------------------------- REGISTER F1<| | |<--------------------------- REGISTER F1<| |
| | | | | | | |
|>F2 200 OK ----------------------------->| | |>F2 200 OK ----------------------------->| |
| | | | | | | |
| |<----- SUBSCRIBE F3<| | | |<----- SUBSCRIBE F3<| |
| | | | | | | |
| |>F4 202 Accepted -->| | | |>F4 200 OK -------->| |
| | | | | | | |
| |>F5 NOTIFY -------->| | | |>F5 NOTIFY -------->| |
| | | | | | | |
| |<-------- 200 OK F6<| | | |<-------- 200 OK F6<| |
| | | | | | | |
|<-------------------------------------------- REGISTER F7<| |<-------------------------------------------- REGISTER F7<|
| | | | | | | |
|>F8 200 OK ---------------------------------------------->| |>F8 200 OK ---------------------------------------------->|
| | | | | | | |
| |<---------------------- SUBSCRIBE F9<| | |<---------------------- SUBSCRIBE F9<|
| | | | | | | |
| |>F10 202 Accepted ------------------>| | |>F10 200 OK ------------------------>|
| | | | | | | |
| |>F11 NOTIFY ------------------------>| | |>F11 NOTIFY ------------------------>|
| | | | | | | |
| |<------------------------ 200 OK F12<| | |<------------------------ 200 OK F12<|
| | | | | | | |
Figure 1. Figure 1.
F1-F2: Alice registers AOR with F1-F2: Alice registers AOR with
contact: <sip:alice@ua1.example.com> 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:HelpDesk@example.com> To: <sip:HelpDesk@example.com>
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb Call-ID: d3281184-518783de-cc23d6bb
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Max-Forwards: 70 Max-Forwards: 70
Expires: 3600 Expires: 3600
Content-Length: 0 Content-Length: 0
skipping to change at page 23, line 47 skipping to change at page 25, line 8
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
Event: dialog;shared 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 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
CSeq: 91 SUBSCRIBE CSeq: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:HelpDesk@example.com>;tag=1636248422222257 To: <sip:HelpDesk@example.com>;tag=1636248422222257
Allow-Events: dialog Allow-Events: dialog
Expires: 3700 Expires: 3700
Contact: <sip:appearanceagent.example.com> Contact: <sip:appearanceagent.example.com>
Content-Length: 0 Content-Length: 0
skipping to change at page 25, line 27 skipping to change at page 26, line 33
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131 From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>;tag=fkwlwqi1 To: <sip:HelpDesk@example.com>;tag=fkwlwqi1
CSeq: 72 REGISTER CSeq: 72 REGISTER
Call-ID: 139490230230249348 Call-ID: 139490230230249348
Contact: <sip:alice@ua1.example.com>;expires=3200 Contact: <sip:alice@ua1.example.com>;expires=3200
Contact: <sip:bob@ua2.example.com>;expires=3600 Contact: <sip:bob@ua2.example.com>;expires=3600
Content-Length: 0 Content-Length: 0
10.2. Appearance Selection/Seizure 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. incoming call. Bob answers the call.
Note that it is possible that both Alice and Bob answer the call and Note that it is possible that both Alice and Bob answer the call and
send 200 OK responses to Carol. It is up to Carol to resolve this send 200 OK responses to Carol. It is up to Carol to resolve this
situation. Typically, Carol will send ACKs to both 200 OKs but send situation. Typically, Carol will send ACKs to both 200 OKs but send
skipping to change at page 27, line 31 skipping to change at page 28, line 39
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13" version="13"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c" <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345" call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42" remote-tag="44BAD75D-E3128D42"
direction="recipient"> direction="recipient">
<sa:appearance>1</appearance> <sa:appearance>1</sa: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:bob@ua2.example.com SIP/2.0 INVITE sip:bob@ua2.example.com SIP/2.0
skipping to change at page 28, line 44 skipping to change at page 30, line 5
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13" version="13"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c" <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345" call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42" remote-tag="44BAD75D-E3128D42"
local-tag="7349dsfjkFD03s" local-tag="7349dsfjkFD03s"
direction="recipient"> direction="recipient">
<sa:appearance>1</appearance> <sa:appearance>1</sa:appearance>
<state>confirmed</state> <state>confirmed</state>
<local> <local>
<target>sip:bob@ua2.example.com</target> <target>sip:bob@ua2.example.com</target>
</local> </local>
<remote> <remote>
<identity>sip:carol@ua.example.com</identity> <identity>sip:carol@ua.example.com</identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.3. Outgoing Call without Appearance Pre-Selection/Seizure 10.3. Outgoing Call without Appearance Seizure
In this scenario, Bob's UA places a call without first selecting/ In this scenario, Bob's UA places a call without first selecting/
seizing an appearance number. After Bob sends the INVITE, the seizing an appearance number. After Bob sends the INVITE, the
appearance assigns an appearance number for it and notifies both appearance assigns an appearance number for it and notifies both
Alice and Bob. Alice and Bob.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | | | | | | | |
| |<------------------------------------- INVITE F1<| | |<------------------------------------- INVITE F1<|
skipping to change at page 31, line 17 skipping to change at page 32, line 25
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator"> local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F6 Appearance Agent ----> Bob F6 Appearance Agent ----> Bob
skipping to change at page 32, line 5 skipping to change at page 33, line 14
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator"> local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.4. Outgoing Call with Appearance Pre-Selection/Seizure 10.4. Outgoing Call with Appearance Seizure
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) selecting/seizing an appearance number before sending state (trying) selecting/seizing an appearance number before sending
the INVITE. After receiving the 200 OK from the Appearance Agent the INVITE. After receiving the 200 OK from the Appearance Agent
confirming the appearance number, Bob's UA sends the INVITE to Carol confirming the appearance number, Bob's UA sends the INVITE to Carol
and establishes a session. For brevity, details of some of the and establishes a session. For brevity, details of some of the
messages are not included in the message flows. messages are not included in the message flows.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
skipping to change at page 34, line 15 skipping to change at page 35, line 23
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6" version="6"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F2 Appearance Agent ----> Bob F2 Appearance Agent ----> Bob
skipping to change at page 35, line 33 skipping to change at page 36, line 41
<?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:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
direction="initiator"> direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<identity uri="sip:carol@example.com"> <identity uri="sip:carol@example.com">
</identity> </identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.5. Outgoing Call without using an Appearance Number 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.
skipping to change at page 37, line 41 skipping to change at page 38, line 45
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6" version="6"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="id3d4f9c83" direction="initiator">
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
Note that F7 would be the same as the previous example. Note that F7 would be the same as the previous example.
10.6. Appearance Release 10.6. Appearance Release
Bob and Carol are in a dialog, created, for example as in Section Bob and Carol are in a dialog, created, for example as in Section
10.3. Carol sends a BYE to Bob to terminate the dialog. Bob 10.3. 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-
skipping to change at page 39, line 11 skipping to change at page 40, line 16
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator"> direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<state>terminated</state> <state>terminated</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.7. Appearance Pickup 10.7. Appearance Pickup
skipping to change at page 41, line 35 skipping to change at page 42, line 39
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator"> direction="initiator">
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa: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="no"/> <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@ua3.example.com" /> <target uri="sip:carol@ua3.example.com" />
</remote> </remote>
skipping to change at page 42, line 27 skipping to change at page 43, line 31
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6" call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" > local-tag="8C4183CB-BCEAB710" >
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog <sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
from-tag="15A3DE7C-9283203B" from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" /> to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sip:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
skipping to change at page 45, line 16 skipping to change at page 46, line 19
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="3xdsd4f9c83" <dialog id="3xdsd4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5" call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="34322kdfr234f" local-tag="34322kdfr234f"
remote-tag="3153DE7C-928203B" remote-tag="3153DE7C-928203B"
direction="initiator"> direction="initiator">
<sa:exclusive>true</exclusive> <sa:exclusive>true</sa:exclusive>
<sa:appearance>1</appearance> <sa:appearance>1</sa:appearance>
<state>connected</state> <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:HelpDesk@example.com</identity> <identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" /> <target uri="sip:alice@ua1.example.com" />
</remote> </remote>
</dialog> </dialog>
<dialog id="4839589" <dialog id="4839589"
call-id="b3cbd0-ad2c5775e-5df9f8d5" call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B" local-tag="3153DE7C-928203B"
remote-tag="34322kdfr234f" remote-tag="34322kdfr234f"
direction="responder"> direction="responder">
<sa:exclusive>true</exclusive> <sa:exclusive>true</sa:exclusive>
<sa:appearance>1</appearance> <sa:appearance>1</sa:appearance>
<state>connected</state> <state>connected</state>
<local> <local>
<target uri="sip:alice@ua1.example.com" /> <target uri="sip:alice@ua1.example.com" />
</local> </local>
<remote> <remote>
<identity>sip:HelpDesk@example.com</identity> <identity>sip:HelpDesk@example.com</identity>
<target uri="sip:bob@ua2.example.com" /> <target uri="sip:bob@ua2.example.com" />
</remote> </remote>
</dialog> </dialog>
skipping to change at page 48, line 22 skipping to change at page 49, line 26
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5" call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B" local-tag="3153DE7C-928203B"
direction="initiator"> direction="initiator">
<sa:exclusive>true</exclusive> <sa:exclusive>true</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:HelpDesk@example.com</identity> <identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" /> <target uri="sip:alice@ua1.example.com" />
</remote> </remote>
</dialog> </dialog>
skipping to change at page 50, line 23 skipping to change at page 51, line 28
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com:5060"> entity="sip:HelpDesk@example.com:5060">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48" call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" > local-tag="605AD957-1F6305C2" >
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<sa:joined-dialog <sa:joined-dialog
call-id="14-1541707345" call-id="14-1541707345"
from-tag="44BAD75D-E3128D42" from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<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>
skipping to change at page 52, line 44 skipping to change at page 53, line 44
| | | | | | | | | |
| | |<- NOTIFY F14<| | | | |<- NOTIFY F14<| |
| | | | | | | | | |
| | |>F15 200 OK ->| | | | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>| | | | |------ NOTIFY F16>|
| | | | | | | | | |
| | | NOTIFY is retransmitted | | | | NOTIFY is retransmitted |
Figure 11. Figure 11.
10.12. Appearance Selection/Seizure Contention Race Condition 10.12. Appearance Seizure Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the Bob and Alice both try to reserve appearance 2 by publishing at the
same time. The Appearance Agent allocates the appearance to Bob by same time. The Appearance Agent allocates the appearance to Bob by
sending a 200 OK and denies it to Alice by sending a 409 Conflict. sending a 200 OK and denies it to Alice by sending a 409 Conflict.
After the NOTIFY F5, Alice learns that Bob is using appearance 2. After the NOTIFY F5, Alice learns that Bob is using appearance 2.
Alice 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<|
skipping to change at page 54, line 11 skipping to change at page 55, line 11
In this scenario, the Appearance Agent does not have any way of In this scenario, the Appearance Agent does not have any way of
knowing Bob's dialog state information, except through Bob. This knowing Bob's dialog state information, except through Bob. This
could be because the Appearance Agent is not part of a B2BUA, or could be because the Appearance Agent is not part of a B2BUA, or
perhaps Bob is remotely registering. When Bob registers, the perhaps Bob is remotely registering. When Bob registers, the
Appearance Agent receives a registration event package notification Appearance Agent receives a registration event package notification
from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's
dialog event state. Whenever Bob's dialog state changes, a NOTIFY is 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 sent to the Appearance Agent who then notifies the other other UAs in
the group. the group.
OPEN ISSUE: Does Bob PUBLISH to select/seize an appearance, or
does he just NOTIFY the Appearance Agent?
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| |<----------------------------------- REGISTER F1<| | |<----------------------------------- REGISTER F1<|
| | | | | | | | | |
| |>F2 200 OK ------------------------------------->| | |>F2 200 OK ------------------------------------->|
| | | | | | | | | |
| |>F3 NOTIFY ------------------>| | | |>F3 NOTIFY ------------------>| |
| | | | | | | | | |
| |<------------------ 200 OK F4<| | | |<------------------ 200 OK F4<| |
| | | |---- SUBSCRIBE F5>| | | | |---- SUBSCRIBE F5>|
skipping to change at page 57, line 36 skipping to change at page 58, line 33
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48" call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" > local-tag="605AD957-1F6305C2" >
<sa:appearance>0</appearance> <sa:appearance>0</sa:appearance>
<sa:exclusive>false</exclusive> <sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog <sa:replaced-dialog
call-id="14-1541707345" call-id="14-1541707345"
from-tag="44BAD75D-E3128D42" from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>terminated</state> <state>terminated</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:carol@ua3.example.com" /> <target uri="sip:carol@ua3.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.15. Appearance Selection/Seizure Incoming/Outgoing Contention Race 10.15. Appearance Seizure Incoming/Outgoing Contention Race Condition
Condition
Alice tries to select/seize appearance 2 at the same time appearance Alice tries to seize appearance 2 at the same time appearance 2 is
2 is allocated to an incoming call. The Appearance Agent resolves allocated to an incoming call. The Appearance Agent resolves the
the conflict by sending a 409 Conflict to Alice. After the NOTIFY conflict by sending a 409 Conflict to Alice. After the NOTIFY F6,
F6, Alice learns that the incoming call is using appearance 2. Alice Alice learns that the incoming call is using appearance 2. Alice
republishes for appearance 3, which is accepted. Note that this republishes for appearance 3, which is accepted. Note that this
example shows the INVITE being received before the NOTIFY from the example shows the INVITE being received before the NOTIFY from the
Appearance Agent. Appearance Agent.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|>-- INVITE F1>| | | | |>-- INVITE F1>| | | |
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |>F2 PUBLISH ->| | | | |>F2 PUBLISH ->| |
skipping to change at page 59, line 15 skipping to change at page 60, line 14
11. Incoming Appearance Assignment 11. 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
UAs could begin alerting using the appearance number selected/seized. UAs could begin alerting using the appearance number seized. This
This approach is sub-optimal since the UAs could receive the INVITE approach is sub-optimal since the UAs could receive the INVITE but be
but be unable to begin alerting if the NOTIFY from the Appearance unable to begin alerting if the NOTIFY from the Appearance Agent is
Agent is delayed or lost delayed or lost
An alternative approach is to define an extension parameter for the An alternative approach is to define an extension parameter for the
Alert-Info header field in RFC 3261 such as: Alert-Info header field in RFC 3261 such as:
Alert-Info: <urn:alert:tone:normal>;appearance=0 Alert-Info: <urn:alert:tone:normal>;appearance=0
This Alert-Info header would indicate to place the call on the first This Alert-Info header would indicate to place the call on the first
line appearance instance. line appearance instance.
A proxy inserting an 'appearance' Alert-Info parameter follows normal A proxy inserting an 'appearance' Alert-Info parameter follows normal
skipping to change at page 60, line 10 skipping to change at page 61, line 6
to the State-Agent like any other UA. This would ensure that the to the State-Agent like any other UA. This would ensure that the
active dialog information is available without having to poll on a active dialog information is available without having to poll on a
need basis. It could keep track of the list of active calls for need basis. It could keep track of the list of active calls for
the appearance AOR based on how many unique INVITE requests it has the appearance AOR based on how many unique INVITE requests it has
forked to or received from the appearance AOR. Another approach forked to or received from the appearance AOR. Another approach
would be for the Proxy to first send the incoming INVITE to the would be for the Proxy to first send the incoming INVITE to the
Appearance Agent which would redirect to the appearance group URI Appearance Agent which would redirect to the appearance group URI
and escape the proper Alert-Info header field for the Proxy to and escape the proper Alert-Info header field for the Proxy to
recurse and distribute to the other UAs in the group. recurse and distribute to the other UAs in the group.
The Appearance Agent needs to know about all incoming requests to The Appearance Agent needs to know about all incoming requests to
the AOR in order to select/seize the appearance number. One way the AOR in order to seize the appearance number. One way in which
in which this could be done is for the Appearance Agent to this could be done is for the Appearance Agent to register against
register against the AOR with a higher q value. This will result the AOR with a higher q value. This will result in the INVITE
in the INVITE being sent to the Appearance Agent first, then being being sent to the Appearance Agent first, then being offered to
offered to the UAs in the group. the UAs in the group.
The changes to RFC 3261 ABNF are: The changes to RFC 3261 ABNF are:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param / alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
appearance-param) ) appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT appearance-param = "appearance" EQUAL *DIGIT
12. IANA Considerations 12. IANA Considerations
skipping to change at page 62, line 37 skipping to change at page 63, line 37
Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
comments. comments.
Thanks to Francois Audet, Andy Hutton, Tim Ross, Raji Chinnappa, and Thanks to Francois Audet, Andy Hutton, Tim Ross, Raji Chinnappa, and
Harsh Mendiratta for their detailed review of the document. Harsh Mendiratta for their detailed review of the document.
14. Security Considerations 14. Security Considerations
Since multiple line appearance features are implemented using Since multiple line appearance features are implemented using
semantics provided by [RFC3261], Event Package for Dialog State as semantics provided by [RFC3261], Event Package for Dialog State as
define in , and Event Notification [RFC3265], [RFC3903], security define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
considerations in these documents apply to this draft as well. [RFC3903], security considerations in these documents apply to this
draft as well.
Specifically, since dialog state information and the dialog Specifically, since dialog state information and the dialog
identifiers are supplied by UA's in an appearance group to other identifiers are supplied by UA's in an appearance group to other
members, the same is prone to "call hijacks". For example, a rogue members, the same is prone to "call hijacks". For example, a rogue
UA could snoop for these identifiers and send an INVITE with Replaces UA could snoop for these identifiers and send an INVITE with Replaces
header containing these call details to take over the call. As such header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in [RFC3261]. before it mechanism (like Digest or S/MIME) described in [RFC3261]. before it
is accepted. NOTIFY or PUBLISH message bodies that provide the is accepted. NOTIFY or PUBLISH message bodies that provide the
dialog state information and the dialog identifiers MAY be encrypted dialog state information and the dialog identifiers MAY be encrypted
skipping to change at page 63, line 18 skipping to change at page 64, line 18
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [I-D.ietf-sipcore-rfc3265bis]
Event Notification", RFC 3265, June 2002. Roach, A., "SIP-Specific Event Notification",
draft-ietf-sipcore-rfc3265bis-00 (work in progress),
July 2009.
[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.
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
 End of changes. 63 change blocks. 
184 lines changed or deleted 200 lines changed or added

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