draft-ietf-bliss-shared-appearances-07.txt   draft-ietf-bliss-shared-appearances-08.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261, 4235 M. Soroushnejad Updates: 3261, 4235 (if approved) M. Soroushnejad
(if approved) V. Venkataramanan Intended status: Standards Track V. Venkataramanan
Intended status: Standards Track Sylantro Systems Corp Expires: December 5, 2011 Sylantro Systems Corp
Expires: September 15, 2011 March 14, 2011 June 3, 2011
Shared Appearances of a Session Initiation Protocol (SIP) Address of Shared Appearances of a Session Initiation Protocol (SIP) Address of
Record (AOR) Record (AOR)
draft-ietf-bliss-shared-appearances-07 draft-ietf-bliss-shared-appearances-08
Abstract Abstract
This document describes the requirements and implementation of a This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as shared appearances of an Address Protocol (SIP), it is referred to as shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. This of Record (AOR) since SIP does not have the concept of lines. This
feature is commonly offered in IP Centrex services and IP-PBX feature is commonly offered in IP Centrex services and IP-PBX
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on December 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements and Implementation . . . . . . . . . . . . . . . 7 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9
5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12 5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12
5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 12 5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 13
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13 5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 13 5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 14
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14
5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17
5.3.2. Appearance Numbers and Call Control . . . . . . . . . 16 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17
5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 17 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 17 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 18
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 19 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21
7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 21 7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23
8. User Interface Considerations . . . . . . . . . . . . . . . . 22 8. User Interface Considerations . . . . . . . . . . . . . . . . 24
8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 22 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24
8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 22 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24
8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 22 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24
8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 23 8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 24
8.1.4. Shared Appearance UAs with Variable Appearance 8.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 23 Number . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1.5. Example User Interface Issues . . . . . . . . . . . . 23 8.1.5. Example User Interface Issues . . . . . . . . . . . . 25
8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 24 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26
9. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 24 9. Interoperability with non-Shared Appearance UAs . . . . . . . 26
9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 24 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26
9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 24 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27
9.3. UAs Supporting Dialog Events but Not Shared Appearance . 25 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27
10. Provisioning Considerations . . . . . . . . . . . . . . . . . 25 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27
11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 26 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28
11.1. Registration and Subscription . . . . . . . . . . . . . . 26 11.1. Registration and Subscription . . . . . . . . . . . . . . 28
11.2. Appearance Selection for Incoming Call . . . . . . . . . 30 11.2. Appearance Selection for Incoming Call . . . . . . . . . 32
11.3. Outgoing Call without Appearance Seizure . . . . . . . . 33 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35
11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 36 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 38
11.5. Outgoing Call without using an Appearance Number . . . . 40 11.5. Outgoing Call without using an Appearance Number . . . . 42
11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 42 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44
11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 43 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 45
11.8. Calls between UAs within the Group . . . . . . . . . . . 47 11.8. Calls between UAs within the Group . . . . . . . . . . . 49
11.9. Consultation Hold with Appearances . . . . . . . . . . . 50 11.9. Consultation Hold with Appearances . . . . . . . . . . . 52
11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 53 11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 55
11.11. Appearance Allocation - Loss of Appearance . . . . . . . 55 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 57
11.12. Appearance Seizure Contention Race Condition . . . . . . 56 11.12. Appearance Seizure Contention Race Condition . . . . . . 58
11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 57 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60
11.14. Appearance Pickup Race Condition Failure . . . . . . . . 59 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 61
11.15. Appearance Seizure Incoming/Outgoing Contention Race 11.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . . 62 Condition . . . . . . . . . . . . . . . . . . . . . . . . 64
12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 12. Security Considerations . . . . . . . . . . . . . . . . . . . 65
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 63 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 66
13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 64 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 67
13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 64 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 67
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
15.1. Normative References . . . . . . . . . . . . . . . . . . 65 15.1. Normative References . . . . . . . . . . . . . . . . . . 68
15.2. Informative References . . . . . . . . . . . . . . . . . 66 15.2. Informative References . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
The feature and functionality requirements for SIP user agents (UAs) The feature and functionality requirements for SIP user agents (UAs)
supporting business telephony applications differ greatly from basic supporting business telephony applications differ greatly from basic
SIP user agents, both in terms of services and end user experience. SIP user agents, both in terms of services and end user experience.
In addition to basic SIP support [RFC3261], many of the services in a In addition to basic SIP support [RFC3261], many of the services in a
business environment require the support for SIP extensions such as business environment require the support for SIP extensions such as
REFER [RFC3515], SUBSCRIBE/NOTIFY primitives REFER [RFC3515], SUBSCRIBE/NOTIFY primitives
[I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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 standard SIP [RFC3261] in conjunction with SIP events
[I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] (carrying the
exchanging status among user agents, and the SIP dialog state event SIP dialog state event package [RFC4235]) for exchanging status among
package [RFC4235] to exchange dialog state information to achieve the user agents. Different approaches will be discussed including the
same. Different approaches will be discussed including the use of use of URI parameters, feature tags, and dialog package extensions
URI parameters, feature tags, and dialog package extensions along along with the strengths and weaknesses of 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. 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 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 of an user interface for the telephone - typically each appearance of an
AOR has a visual display (lamp that can change color or blink or a AOR has a visual display (lamp that can change color or blink or a
screen icon) and a button (used to select the appearance). The screen icon) and a button (used to select the appearance) where each
telephony concept of line appearance is still relevant to SIP due to appearance number is associated with a different dialog to/from the
the user interface considerations. It is important to keep the AOR. The telephony concept of line appearance is still relevant to
appearance number construct because: SIP due to the user interface considerations. It is important to
keep the appearance number construct because:
1. Human users are used to the concept and will expect it in 1. Human users are used to the concept and will expect it in
replacement systems (e.g. an overhead page announcement says "Joe replacement systems (e.g. an overhead page announcement says "Joe
pickup line 3"). pickup line 3").
2. It is a useful structure for user interface representation. 2. It is a useful structure for user interface representation.
The purpose of the appearance number is to identify active calls to The purpose of the appearance number is to identify active calls to
facilitate sharing between users (e.g. passing a call from one user facilitate sharing between users (e.g. passing a call from one user
to another). If a telephone has enough buttons/lamps, calls could be to another). If a telephone has enough buttons/lamps, the appearance
presented on the nth button. If not, it may still be desirable to number could be the positional sequence number of the button. If
present the call state, but the appearance number should be displayed not, it may still be desirable to present the call state, but the
so that users know which call, for example, is on hold on which key. appearance number should be displayed so that users know which call,
for example, is on hold on which key.
In this document, except for the usage scenarios in the next section, In this document, except for the usage scenarios in the next section,
we will use the term "appearance" rather than "line appearance" since we will use the term "appearance" rather than "line appearance" since
SIP does not have the concept of lines. Note that this does not mean SIP does not have the concept of lines. Note that this does not mean
that a conventional telephony user interface (lamps and buttons) must that a conventional telephony user interface (lamps and buttons) must
be used - implementations may use another metaphor as long as the be used - implementations may use another metaphor as long as the
appearance number is readily apparent to the user. Each AOR has a appearance number is readily apparent to the user. Each AOR has a
separate appearance numbering space. As a result, a given UA user separate appearance numbering space. As a result, a given UA user
interface may have multiple occurrences of the same appearance interface may have multiple occurrences of the same appearance
number, but they will be for different AORs. number, but they will be for different AORs.
skipping to change at page 8, line 48 skipping to change at page 8, line 48
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 join or take the
taken. Exclusivity may be requested at the start of an incoming or call. 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 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 seize a REQ-16 The mechanism should support a way for a UA to seize a
skipping to change at page 9, line 39 skipping to change at page 9, line 39
- The use of a State Agent for the Dialog Package meets REQ-4 and - The use of a State Agent for the Dialog Package meets REQ-4 and
REQ-5. REQ-5.
REQ-6 suggests the need for an entity which manages the appearance REQ-6 suggests the need for an entity which manages the appearance
resource. Just as conferencing systems commonly have a single point resource. Just as conferencing systems commonly have a single point
of control, known as a focus, a Shared Appearance group has a single of control, known as a focus, a Shared Appearance group has a single
point of control of the appearance shared resource. This is defined point of control of the appearance shared resource. This is defined
as an Appearance Agent for a group. While an Appearance Agent can be as an Appearance Agent for a group. While an Appearance Agent can be
part of a centralized server, it could also be co-resident in a part of a centralized server, it could also be co-resident in a
member User Agent who has taken on this functionality for a group. member User Agent that has taken on this functionality for a group.
The Appearance Agent knows or is able to determine the dialog state The Appearance Agent knows or is able to determine the dialog state
of all members of the group. of all members of the group.
While the appearance resource could be managed co-operatively by a While the appearance resource could be managed co-operatively by a
group of UAs without any central control, this is outside the scope group of UAs without any central control, this is outside the scope
of this draft. It is also possible that the Appearance Agent logic of this draft. 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,
skipping to change at page 10, line 38 skipping to change at page 10, line 38
3. Information learned about the dialog state of other UAs in the 3. Information learned about the dialog state of other UAs in the
group is rendered to the user. group is rendered to the user.
4. Incoming calls are forked to all UAs in the group, and any may 4. Incoming calls are forked to all UAs in the group, and any may
answer. UAs receive the appearance number to use in rendering answer. UAs receive the appearance number to use in rendering
the incoming call in a NOTIFY from the Appearance Agent and in the incoming call in a NOTIFY from the Appearance Agent and in
the INVITE itself. The UA will also receive a notification if the INVITE itself. The UA will also receive a notification if
the call is answered by another UA in the group so this the call is answered by another UA in the group so this
information can be rendered to the user. information can be rendered to the user.
5. For outgoing calls, the operation depends on the implementation. 5. For outgoing calls, the operation depends on the implementation.
If the user seizes a particular appearance number for the call, If the user seizes a particular appearance number for the call,
the UA publishes the 100 Trying state dialog information without the UA publishes the trying state dialog information with the
an appearance number and waits for a 200 OK before sending the desired appearance number and waits for a 2xx response before
INVITE. sending the INVITE.
6. For outgoing calls, if the user does not seize a particular 6. For outgoing calls, if the user does not seize a particular
appearance or does not care, the INVITE can be sent immediately, appearance or does not care, the INVITE can be sent immediately,
and the appearance number learned as the call progresses from a and the appearance number learned as the call progresses from a
notification from the Appearance Agent. notification from the Appearance Agent.
7. For outgoing calls, if the user does not wish to seize an 7. For outgoing calls, if the user does not want an appearance
appearance (such as during a consultation call or if a UA is number assigned (such as during a consultation call or if a UA is
fetching 'service media' such as music on hold fetching 'service media' such as music on hold
[I-D.worley-service-example]), the UA also publishes this prior [I-D.worley-service-example]), the UA also publishes prior to
to sending the INVITE. sending the INVITE but does not include an appearance number in
the publication.
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. The Appearance Agent may not have full access to the complete 9. The Appearance Agent may not have direct access to the complete
dialog state of some or all of the UAs in the group. If this is 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 the case, the Appearance Agent will subscribe to the dialog state
of individual UAs in the group to obtain this information. of individual UAs in the group to obtain this information. In
Normal notifications will be sent every time the dialog state any case, the Appearance Agent will send normal notifications
changes, including calls placed, answered, placed on and off (via the subscriptions established by the UAs in step 1) every
hold, and hangups. time the aggregate dialog state of the AOR changes, including
when calls are placed, answered, placed on and off hold, and hung
up.
5. Normative Description 5. Normative Description
This section normatively describes the shared appearance feature This section normatively describes the shared appearance feature
extensions. The following definitions are used throughout this extensions. The following definitions are used throughout this
document: document:
Appearance number: An appearance number is a positive integer
associated with one or more dialogs of an AOR. Appearance numbers
are managed by an Appearance Agent and displayed and rendered to the
user by UAs that support this specification. When an appearance
number is assigned or requested, generally the assigned number is the
smallest positive integer that is not currently assigned as an
appearance number to a dialog for this AOR.
Seizing: An appearance can be reserved prior to a call being placed Seizing: An appearance can be reserved prior to a call being placed
by seizing the appearance. An appearance can be seized by by seizing the appearance. An appearance can be seized by
communicating an artificial state of "trying" prior to actually communicating an artificial state of "trying" prior to actually
initiating a dialog, in order to appear as it was already initiating initiating a dialog (i.e. sending the INVITE), in order to appear as
a dialog. The appearance number is confirmed prior to sending the if it was already initiating a dialog.
INVITE.
Selecting(or Not-Seizing): An appearance is merely selected (i.e., Selecting(or Not-Seizing): An appearance is merely selected (i.e.,
not seized) if there is no such communication of artificial state of not seized) if there is no such communication of artificial state of
"trying" prior to initiating a dialog: i.e., the state is "trying" prior to initiating a dialog: i.e., the state is
communicated when the dialog is actually initiated. The appearance communicated when the dialog is actually initiated. The appearance
number is learned after the INVITE is sent. This is a user interface number is learned after the INVITE is sent.
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 12, line 17 skipping to change at page 12, line 30
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 [I-D.ietf-sipcore-rfc3265bis]. The schema is Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is
defined in Section 6. The elements are <appearance>, <exclusive>, defined in Section 6. The elements are <appearance>, <exclusive>,
<joined-dialog>, and <replaced-dialog> which are sub-elements of the <joined-dialog>, and <replaced-dialog> which are sub-elements of the
<dialog> element. <dialog> element.
5.2.1. The <appearance> element 5.2.1. The <appearance> element
The <appearance> element is used to convey the appearance number. The <appearance> element, a child of the <dialog> element, is used to
The appearance number is a positive integer. When sent in a convey the appearance number of the dialog described by the parent
publication in state Trying to the Appearance Agent, it is used to <dialog> element. When sent by a UA in a PUBLISH with parent
request an appearance number. When sent by the Appearance Agent, it <dialog> with state attribute "trying" to the Appearance Agent, the
indicates that the appearance number is associated with a dialog. UA is requesting assignment of the given appearance number to the
The UA generating the to-tag and from-tag parameters treats them from current or future dialog with the given dialog identifiers. When an
a local perspective. In other words, if the UA sent out a request <appearance> element is sent by the Appearance Agent in a NOTIFY, it
within the dialog, the to-tag parameter would match the remote tag, indicates that the appearance number has been assigned to the
and the from-tag parameter would match the local tag. specified dialog.
Note that a <dialog-info> element describes the contained dialogs
from the point of view of the UA (named by the "entity" attribute),
regardless of whether the containing request is sent by the UA or the
Appearance Agent. In particular, if the UA sent a request within the
described dialog, the To header field URI would match the <remote>
<identity> value and the to-tag parameter would match the remote-tag
attribute. Similarly, the From header field URI would match the
<local> <identity> value and the from-tag parameter would match the
local-tag attribute.
5.2.2. The <exclusive> element 5.2.2. The <exclusive> element
The <exclusive> element is a boolean used to indicate whether the UA The <exclusive> element, a child of the <dialog> element, is a
will accept Join or Replaces INVITEs for this dialog. For example, boolean, which when true, indicates that the UA is willing to accept
some shared appearance systems only allow call pickup when the call an INVITE with a Join or Replaces header field targeted to the dialog
is on hold. In this case, the <exclusive> element should be used to described by the <dialog> element that is the parent of the
explicitly indicate this, rather than implicitly by the hold state. <exclusive> element. For example, some shared appearance systems
only allow call pickup when the call is on hold. In this case, the
<exclusive> element should be set to "true" when the call is held and
"false" when the call is not held, rather than having the "exclusive"
value implied by the hold state.
It is important to note that this element is a hint. In order to It is important to note that this element is a hint. In order to
prevent another UA from taking or joining a call, a UA can, in prevent another UA from taking or joining a call, a UA can, in
addition to setting the <exclusive> tag, not report full dialog addition to setting the <exclusive> tag, not report full dialog
information to the Appearance Agent. Not having the full dialog information to the Appearance Agent. Not having the full dialog
information (Call-ID, remote-tag, and local-tag) prevents another UA information (Call-ID, remote-tag, and local-tag) prevents another UA
from constructing a Join or Replaces header field. Although a UA may from constructing a Join or Replaces header field. Although a UA may
set exclusive to true, the UA must still be ready to reject an INVITE set exclusive to true, the UA must still be ready to reject an INVITE
Join relating to this dialog. If these dialog identifiers have Join relating to this dialog. If these dialog identifiers have
already been shared with the Appearance Agent, the UA could send an already been shared with the Appearance Agent, the UA could send an
skipping to change at page 13, line 9 skipping to change at page 13, line 38
If the proxy knows which dialogs are marked exclusive, the proxy MAY If the proxy knows which dialogs are marked exclusive, the proxy MAY
enforce this exclusivity by rejecting INVITE Join and INVITE Replaces enforce this exclusivity by rejecting INVITE Join and INVITE Replaces
requests containing those dialog identifiers with a 403 Forbidden requests containing those dialog identifiers with a 403 Forbidden
response. response.
Note that exclusivity has nothing to do with appearance number Note that exclusivity has nothing to do with appearance number
selection or seizing - instead, it is about call control selection or seizing - instead, it is about call control
operations that can be performed on a dialog. operations that can be performed on a dialog.
If the <exclusive> element is not present, it is assumed to be false.
5.2.3. The <joined-dialog> element 5.2.3. The <joined-dialog> element
The <joined-dialog> element is used to convey dialog identifiers of The <joined-dialog> element, a child of the <dialog> element, is used
any other dialogs which are joined (mixed or bridged) with the to convey dialog identifiers of any other dialogs which are joined
dialog. Only the UA which is performing the actual media mixing (mixed or bridged) with the dialog. Only the UA which is the common
should include this element in publications to the Appearance Agent. endpoint of the mixed dialogs (and thus controlling the mixing
Note that this element should still be used even when the Join header operation) should include this element in publications to the
field was not used to join the dialogs. For example, two separate Appearance Agent. Note that this element should still be used even
dialogs on a UA could be joined without any SIP call control when the Join header field was not used to join the dialogs. For
operations. Joined dialogs will share the same appearance number. example, two separate dialogs on a UA could be joined without any SIP
call control operations. Joined dialogs will share the same
appearance number.
If the <joined-dialog> element is not present, it is assumed that the
dialog is not joined or to be joined to any other dialog.
5.2.4. The <replaced-dialog> element 5.2.4. The <replaced-dialog> element
The <replaced-dialog> element is used to convey dialog identifiers of The <replaced-dialog> element, a child of the <dialog> element, is
any other dialogs which will be or have been replaced with this used to convey dialog identifiers of any other dialogs which will be
dialog. For example, a UA in the group picking up a call on another or have been replaced with this dialog. For example, a UA in the
UA by sending an INVITE with Replaces would include this element for group picking up a call on another UA by sending an INVITE with
the replacing dialog. Replaced dialogs will share the same Replaces would include this element for the replacing dialog.
appearance number. Replaced dialogs will share the same appearance number.
If the <replaced-dialog> element is not present, it is assumed that
the dialog has not replaced or is not to replace to any other dialog.
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 13. Section 13.
User Agents MUST support the dialog package extensions in Section 5.2 User Agents MUST support the dialog package extensions in Section 5.2
along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and
skipping to change at page 14, line 25 skipping to change at page 15, line 16
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 In the following cases, before sending the INVITE, A UA MUST send a
situations: dialog package PUBLISH request and wait for a 2xx response before
proceeding:
1. When the user seizes a particular appearance number for an 1. When the user seizes a particular appearance number for an
outgoing call (i.e. seizing the appearance and going "off-hook", outgoing call (e.g. seizing the appearance and going "off-hook",
if the UA's user interface uses this metaphor). if the UA's user interface uses this metaphor).
2. When the user has requested that an appearance number not be used 2. When the user has requested that an appearance number not be used
for an outgoing call (i.e. during a consultation call, a 'service for an outgoing call (i.e. during a consultation call, a 'service
media' call such as for music on hold media' call such as for music on hold
[I-D.worley-service-example] or for a call not considered part of [I-D.worley-service-example] or for a call not considered part of
the shared appearance group). the shared appearance group).
3. When the user has selected to join (or bridge) an existing call. 3. When the user has selected to join (or bridge) an existing call.
4. When the user has selected to replace (or take) an existing call. 4. When the user has selected to replace (or take) an existing call.
In all these cases, the INVITE SHOULD NOT be sent until the 200 OK An exception is an emergency call, when a UA MUST never wait for a
response to the PUBLISH has been received, except for an emergency confirmed seizure before sending an INVITE. Instead, the emergency
call, when a UA MUST never wait for a confirmed seizure before call MUST proceed without waiting for the PUBLISH transaction.
sending an INVITE. Instead, the emergency call MUST proceed
regardless of the status of PUBLISH transaction.
Note that when a UA seizes an appearance prior to establishment of a Note that when a UA seizes an appearance prior to establishment of a
dialog (#1 and #2 in above list), not all dialog information will be dialog (#1 and #2 in above list), not all dialog information will be
available. In particular, when a UA publishes an attempt to seize an available. In particular, when a UA publishes an attempt to seize an
appearance prior to knowing the destination URI, minimal or no dialog appearance prior to knowing the destination URI, minimal or no dialog
information may be available. For example, in some cases, only the information may be available. For example, in some cases, only the
local target URI for the call will be known and no dialog local target URI for the call will be known and no dialog
information. If no dialog identification information is present in information. If the From tag and Call-ID were not present in the
the initial PUBLISH, the UA MUST PUBLISH again after receiving the initial PUBLISH, a new PUBLISH MUST be sent as soon as this
100 Trying response. information is available.
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 is refreshed as described in [RFC3903] during This publication state is refreshed as described in [RFC3903] during
the early dialog state or the Appearance Agent may reassign the the early dialog state or the Appearance Agent may reassign the
appearance number. Once the dialog has transitioned to the confirmed appearance number. Once the dialog has transitioned to the confirmed
state, no publication refreshes are necessary. state, no publication refreshes are necessary.
This specification assumes that the Appearance Agent has other
means besides UA publication to learn about the state of UA
dialogs. In this specification, PUBLISH is used to indicate
desired and intended appearance number operations. Once a dialog
transitions from early to confirmed, this role is over, and hence
no publication refreshes are needed.
Appearance numbers are a shorthand label for active and pending Appearance numbers are a shorthand label for active and pending
dialogs related to an AOR. Many of the features and services built dialogs related to an AOR. Many of the features and services built
using this extension rely on the correct rendering of this using this extension rely on the correct rendering of this
information to the human user. In addition, the group nature of the information to the human user. In addition, the group nature of the
feature means that the rendering must be similar between different feature means that the rendering must be similar between different
vendors and different models. Failure to do so will greatly reduce vendors and different models. Failure to do so will greatly reduce
the value and usefulness of these protocol extensions. The the value and usefulness of these protocol extensions. The
appearances number for each active and pending dialog SHOULD be appearances number for each active and pending dialog SHOULD be
explicitly (i.e. by appearance number) or implicitly (using a user explicitly (i.e. by appearance number) or implicitly (using a user
interface metaphor that makes the numbering and ordering clear to the interface metaphor that makes the numbering and ordering clear to the
skipping to change at page 15, line 46 skipping to change at page 16, line 44
package notifications containing the <appearance> element from the package notifications containing the <appearance> element from the
Appearance Agent or from the 'appearance' Alert-Info parameter in an Appearance Agent or from the 'appearance' Alert-Info parameter in an
incoming INVITE. Should they conflict, the dialog package incoming INVITE. Should they conflict, the dialog package
notification takes precedence. notification takes precedence.
A UA that does not need to seize a particular appearance number (or A UA that does not need to seize a particular appearance number (or
doesn't care) would just send an INVITE as normal to place an doesn't care) would just send an INVITE as normal to place an
outbound call. outbound call.
A user may select an appearance number but then abandon placing a A user may select an appearance number but then abandon placing a
call (go back on hook). In this case, the UA SHOULD free up the call (go back on hook). In this case, the UA MUST free up the
appearance number by removing the event state with a PUBLISH as appearance number by removing the event state with a PUBLISH as
described in [RFC3903]. described in [RFC3903].
A UA SHOULD register against the AOR only if it is likely the UA will A UA SHOULD register against the AOR only if it is likely the UA will
be answering incoming calls. If the UA is mainly going to be be answering incoming calls. If the UA is mainly going to be
monitoring the status of the shared appearance group calls and monitoring the status of the shared appearance group calls and
picking or joining calls, the UA SHOULD only subscribe to the AOR and picking or joining calls, the UA SHOULD only subscribe to the AOR and
not register against the AOR. not register against the AOR.
All subscribed UAs will receive dialog package NOTIFYs of Trying All subscribed UAs will receive dialog package NOTIFYs of Trying
state for incoming INVITEs. state for incoming INVITEs.
5.3.1. Appearance Numbers and Call Context 5.3.1. Appearance Numbers and Call Context
There are cases where two separate dialogs at a UA (non-mixed) share There are cases where two separate dialogs at a UA are not mixed but
the same 'context'. That is, they relate to each other and should share the same 'context'. That is, they relate to each other and
not be treated the same as any other two dialogs within the group. should not be treated the same as any other two dialogs within the
One example of this is a 'consultation call' where a user puts an group. One example of this is a 'consultation call' where a user
existing dialog on hold, then calls another user, before switching puts an existing dialog on hold, then calls another user, before
back to the original dialog. Another case, described below, occurs switching back to the original dialog. Another case, described
during transfer operations, where for a transient period, a UA is below, occurs during transfer operations, where for a transient
invovled in dialogs with two other UAs, but the dialogs are related, period, a UA is invovled in dialogs with two other UAs, but the
and should not be treated as independent dialogs. These cases are dialogs are related, and should not be treated as independent
best handled by having these dialogs that share a context with an dialogs. These cases are best handled by not assigning an appearance
existing dialog not have an an appearance number assigned to them. number to a newly-created dialog when it shares a context with an
existing dialog. But if the pre-existing dialog is terminated, its
appearance number should be reassigned to the newly-created 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 400 response with the reason phrase "Appearance appearance number, a 400 response is sent by the Appearance Agent and
Number Conflict" will be received, and the UA will republish either the UA will republish either selecting/seizing an appearance number
selecting/seizing an appearance number or send the INVITE without or send the INVITE without publishing, in which case the Appearance
publishing, in which case the Appearance Agent will assign one. Agent will assign one.
Note that if an Appearance Agent rejects calls without an Note that if an Appearance Agent rejects calls without an
appearance number, certain operations such as consultation calls, appearance number, certain operations such as consultation calls,
transfer, and music on hold may be impacted. transfer, and music on hold may be impacted.
5.3.2. Appearance Numbers and Call Control 5.3.2. Appearance Numbers and Call Control
When an INVITE is generated to attempt to bridge or take a call (i.e. When an INVITE is generated to attempt to bridge or take a call (i.e.
contains Join or Replaces with a dialog identifier of another dialog contains Join or Replaces with a dialog identifier of another dialog
in the shared appearance group), the appearance number of the joined in the shared appearance group), the UA MUST first send a PUBLISH to
or replaced call SHOULD be published. The publication MUST contain the Appearance Agent. This PUBLISH will contain:
the appearance number of the dialog to be joined or replaced and the
dialog identifier in the 'joined-dialog' or 'replaced-dialog' 1. The appearance number of the joined or replaced call in the
elements. <appearance> element
2. If the dialog is being joined, the <joined-dialog> element will
contain the dialog information from the Join header field
3. If the dialog is being replaced, the <replaced-dialog> element
will contain the dialog information from the Replaces header
field
Note that this information is provided to the Appearance Agent so Note that this information is provided to the Appearance Agent so
that it can provide proper appearance assignment behavior. If the that it can provide proper appearance assignment behavior. If the
INVITE Join or Replaces was sent without publishing first, the INVITE Join or Replaces was sent without publishing first, the
Appearance Agent might assign a new appearance number to this Appearance Agent might assign a new appearance number to this
INVITE, which would be a mistake. With Join, the publication has INVITE, which would be a mistake. With Join, the publication has
the 'joined-dialog' element to prevent the Appearance Agent from the <joined-dialog> element to prevent the Appearance Agent from
generating a 400 Appearance Number Conflict response due to the generating a 400 response due to the reuse of an appearance
reuse of an appearance number. For Replaces, the purpose of the number. For Replaces, the purpose of the <replaced-dialog> is to
'replaced-dialog' is to prevent a race condition where the BYE prevent a race condition where the BYE could cause the appearance
could cause the appearance number to be released when it should number to be released when it should stay with the replacing
stay with the replacing dialog. dialog.
5.3.3. Appearance Numbers and Transfer 5.3.3. Appearance Numbers and Transfer
During a transfer operation, it is important that the appearance During a transfer operation, it is important that the appearance
number not change during the operation. Consider the example of number not change during the operation. Consider the example of
Alice, a member of an appearance group, who is talking to Carol, who Alice, a member of an appearance group, who is talking to Carol, who
is outside the appearance group. Carol transfers Alice to David, who is outside the appearance group. Carol transfers Alice to David, who
is also outside the appearance group. For example, if Alice is using is also outside the appearance group. For example, if Alice is using
appearance 3 for the session with Carol, the resulting session with appearance 3 for the session with Carol, the resulting session with
David should also use appearance number 3. Otherwise, an appearance David should also use appearance number 3. Otherwise, an appearance
number change can cause a "jump" on the UI and confusion to the user. number change can cause a "jump" on the UI and confusion to the user.
There are two possible scenarios using the terminology of RFC 5589: There are two possible scenarios using the terminology of RFC 5589:
Alice is the transferee in any type of transfer (receives the REFER) Alice is the transferee in any type of transfer (receives the REFER)
or the transfer target in an attended transfer (receives the INVITE or the transfer target in an attended transfer (receives the INVITE
with Replaces). with Replaces).
If Alice is the transferee, the triggered INVITE from the REFER If Alice is the transferee, the triggered INVITE from the REFER is
should be treated as a consultation call, and should not use a new treated as a consultation call. Alice SHOULD publish requesting that
appearance number. When the transfer completes, the appearance the Appearance Agent not assign an appearance number for this INVITE.
number associated with the dialog with Carol is moved to the dialog When the transfer completes, Alice SHOULD publish again to move the
associated with David. appearance number from the dialog with Carol to the dialog with
David. Note that this publication MUST be sent prior to sending the
BYE to Carol to avoid a race condition where the Appearance Agent
reassigns the appearance number after seeing the BYE.
If Alice is the target, the incoming INVITE should not have a new If Alice is the target, the incoming INVITE will contain a Replaces
appearance number assigned. Instead, it should reuse the appearance header field. As a result, the Appearance Agent will have reused the
number associated with the dialog being replaced. If the Appearance appearance number of the dialog with Carol, and this appearance
Agent does assign a different appearance number, when the transfer number will continue to be used after the dialog with Carol has been
completes, Alice should release that appearance number and use the terminated.
original appearance number associated with the dialog with Carol.
5.4. Appearance Agent 5.4. Appearance Agent
An Appearance Agent defined in this specification MUST implement a An Appearance Agent defined in this specification MUST implement a
dialog package state agent for the UAs registered against the AOR. dialog package state agent for the UAs registered against the AOR.
The Appearance Agent MUST support the appearance dialog package The Appearance Agent MUST support the appearance dialog package
extensions defined in Section 5.2. The Appearance Agent MUST support extensions defined in Section 5.2. The Appearance Agent MUST support
publications and subscriptions for this event package. publications and subscriptions for this event package.
The Appearance Agent MUST have a way of discovering the state of all The Appearance Agent MUST have a way of discovering the state of all
skipping to change at page 18, line 24 skipping to change at page 19, line 30
1. A call is received, placed, answered, or terminated. 1. A call is received, placed, answered, or terminated.
2. A call is placed on or off hold. 2. A call is placed on or off hold.
3. A call is joined or replaced. 3. A call is joined or replaced.
4. An appearance number is reserved or released. 4. An appearance number is reserved or released.
The Appearance Agent MUST allocate an appearance number for all The Appearance Agent MUST allocate an appearance number for all
incoming calls and send immediate notifications to the UAs subscribed incoming calls and send immediate notifications to the UAs subscribed
to the shared group AOR. A new appearance number is allocated except to the shared group AOR. A new appearance number is allocated except
for an incoming INVITE with a Join or Replaces header field. For for an incoming INVITE with a Join or Replaces header field. For
this case, the appearance number should match the appearance number this case, the appearance number should match the appearance number
of the dialog being joined or replaced. The Appearance Agent MUST be of the dialog being joined or replaced. If the INVITE Replaces or
able to communicate with the forking proxy to learn about incoming Join comes from outside the appearance group, the Appearance Agent
calls and also to pass the appearance number to the proxy to insert will include a <joined-dialog> or <replaced-dialog> element in the
in the Alert-Info header field. NOTIFY containing the dialog information from the Replaces or Joined
header field.
The Appearance Agent MUST be able to communicate with the forking
proxy to learn about incoming calls and also to pass the appearance
number to the proxy to insert in the Alert-Info header field.
Note that UAs need to be able to handle incoming INVITEs without Note that UAs need to be able to handle incoming INVITEs without
an appearance number assigned. This could be caused by a failure an appearance number assigned. This could be caused by a failure
of the Appearance Agent or other error condition. Although the of the Appearance Agent or other error condition. Although the
proper rendering of the INVITE may not be possible, this is better proper rendering of the INVITE may not be possible, this is better
than ignoring or failing the INVITE. than ignoring or failing the INVITE.
An Appearance Agent SHOULD assign an appearance number to an outgoing An Appearance Agent SHOULD assign an appearance number to an outgoing
dialog if a PUBLISH has not been received selecting/seizing a dialog if a PUBLISH has not been received selecting/seizing a
particular appearance number. particular appearance number.
Note that if the appearance group has appearance-unaware UAs Note that if the appearance group has appearance-unaware UAs
making calls, the Appearance Agent will still allocate appearance making calls, the Appearance Agent will still allocate appearance
numbers for INVITEs sent by those UAs. numbers for INVITEs sent by those UAs.
An Appearance Agent receiving a PUBLISH with an appearance number An Appearance Agent receiving a PUBLISH with an appearance number
checks to make sure the publication is valid. An appearance number checks to make sure the publication is valid. An appearance number
can be assigned to only one dialog unless there is a 'joined-dialog' can be assigned to only one dialog unless there is a <joined-dialog>
or 'replaced-dialog' element indicating that the dialog will be/has or <replaced-dialog> element indicating that the dialog will be/has
been replaced or joined. A 400 response with the reason phrase been replaced or joined. A 400 response is returned if the chosen
"Appearance Number Conflict" is returned if the chosen appearance appearance number is invalid, and an immediate NOTIFY should be sent
number is invalid, and an immediate NOTIFY should be sent to the UA to the UA containing full dialog event state.
containing full dialog event state.
An Appearance Agent receiving a PUBLISH without an appearance number An Appearance Agent receiving a PUBLISH without an appearance number
but with the 'shared' event package parameter present interprets this but with the 'shared' event package parameter present interprets this
as a request by the UA to not assign an appearance number. If the as a request by the UA to not assign an appearance number. If the
Appearance Agent policy does not allow this, a 400 Appearance Number Appearance Agent policy does not allow this, a 400 response is
Conflict response is returned. If policy does allow this, a 200 OK returned. If policy does allow this, a 200 OK response is returned
response is returned and no appearance number is allocated. An and no appearance number is allocated. An Appearance Agent does not
Appearance Agent does not have to share this dialog information (i.e. have to share this dialog information (i.e. send a NOTIFY) with other
send a NOTIFY) with other UAs in the group as the information will UAs in the group as the information will not be rendered by the other
not be rendered by the other UAs. UAs.
The Appearance Agent allocates an apperance number to a dialog from The Appearance Agent allocates an apperance number to a dialog from
the time the appearance is requested via a PUBLISH or from the the time the appearance is requested via a PUBLISH or from the
receipt of an INVITE, to the time when the last dialog associated receipt of an INVITE, to the time when the last dialog associated
with the appearance is terminated, including all dialogs which are with the appearance is terminated, including all dialogs which are
joined or replaced. During the early dialog state, the Appearance joined or replaced. During the early dialog state, the Appearance
Agent controls the rate of dialog state publication using the Expires Agent controls the rate of dialog state publication using the Expires
header field in 200 OK responses to PUBLISH requests. An interval of header field in 200 OK responses to PUBLISH requests. An interval of
3 minutes is RECOMMENDED. After the dialog associated with the 3 minutes is RECOMMENDED. After the dialog associated with the
publication has been confirmed, the expiration of the publication publication has been confirmed, the expiration of the publication
skipping to change at page 20, line 7 skipping to change at page 22, line 7
6. XML Schema Definition 6. XML Schema Definition
The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive'
elements are defined within a new XML namespace URI. This namespace elements are defined within a new XML namespace URI. This namespace
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"
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" <xs:element name="joined-dialog" minOccurs="0"
maxOccurs="unbounded"> 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" <xs:element name="replaced-dialog" minOccurs="0"
maxOccurs="unbounded"> 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="appearance" minOccurs="0" maxOccurs="1"> <xs:element name="appearance" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:integer"> <xs:simpleType type="xs:integer">
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
<xs:element name="exclusive" minOccurs="0" maxOccurs="1"> <xs:element name="exclusive" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:boolean"> <xs:simpleType type="xs:boolean">
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
7. Alert-Info Appearance Parameter Definition 7. Alert-Info Appearance Parameter Definition
This specification extends RFC 3261 [RFC3261] to add an 'appearance' This specification extends RFC 3261 [RFC3261] to add an 'appearance'
parameter to the Alert-Info header field, and to also allow proxies parameter to the Alert-Info header field, and to also allow proxies
to modify or delete the Alert-Info header field. to modify or delete the Alert-Info header field.
The changes to RFC 3261 ABNF are: The changes to RFC 3261 ABNF are:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI alert-param = LAQUOT absoluteURI RAQUOT *( SEMI
(generic-param / appearance-param) ) (generic-param / appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT appearance-param = "appearance" EQUAL 1*DIGIT
A proxy inserting an 'appearance' Alert-Info parameter follows normal A proxy inserting an 'appearance' Alert-Info parameter follows normal
policies Alert-Info policies. If an Alert-Info is already present, policies Alert-Info policies. If an Alert-Info is already present,
the proxy either removes the Alert-Info if it is not trusted, or adds the proxy either removes the Alert-Info if it is not trusted, or adds
the 'appearance' parameter to the Alert-Info header field. If an the 'appearance' parameter to the Alert-Info header field. If an
appearance number parameter is already present (associated with appearance number parameter is already present (associated with
another AOR or by mistake), the value is rewritten adding the new another AOR or by mistake), the value is rewritten adding the new
appearance number. There MUST NOT be more than one appearance appearance number. There MUST NOT be more than one appearance
parameter in an Alert-Info header field. parameter in an Alert-Info header field.
skipping to change at page 22, line 35 skipping to change at page 24, line 35
Perfect interoperability across all UAs is clearly not possible, but Perfect interoperability across all UAs is clearly not possible, but
by careful design, interoperability up to the limits of each UA can by careful design, interoperability up to the limits of each UA can
be achieved. be achieved.
The following guidelines suggest how the appearance number should be The following guidelines suggest how the appearance number should be
handled in three typical user interface implementations. handled in three typical user interface implementations.
8.1.1. Single Appearance UAs 8.1.1. Single Appearance UAs
These devices are constrained by only having the capability of These devices are constrained by only having the capability of
displaying status indications for a single appearance. Despite this, displaying status indications for a single appearance. The UA should
it is important that devices of this type do not ignore the still send messages annotated with appearance number "1". Any call
appearance number. The UA should still send messages annotated with indications for appearances other than for number "1" should be
an appropriate appearance number (i.e. "0"). Any call indications rejected with a 486 or 480 response.
for appearances other than for number "0" should be rejected with a
486 or 480 response.
8.1.2. Dual Appearance UAs 8.1.2. Dual Appearance UAs
These devices are essentially single appearance phones that implement These devices are essentially single appearance phones that implement
call waiting. They have a very simple user interface that allows call waiting. They have a very simple user interface that allows
them to switch between two appearances (toggle or flash hook) and them to switch between two appearances (toggle or flash hook) and
perhaps audible tones to indicate the status of the other appearance. perhaps audible tones to indicate the status of the other appearance.
Only appearance numbers "0" and "1" will be used by these UAs. Only appearance numbers "1" and "2" will be used by these UAs.
8.1.3. Shared Appearance UAs with Fixed Appearance Number 8.1.3. Shared Appearance UAs with Fixed Appearance Number
This UA is the typical 'business-class' hard-phone. A number of This UA is the typical 'business-class' hard-phone. A number of
appearances are typically configured statically and labeled on appearances are typically configured statically and labeled on
buttons, and calls may be managed using these configured appearances. buttons, and calls may be managed using these configured appearances.
Any calls outside this range should be rejected, and not mapped to a Any calls outside this range should be rejected, and not mapped to a
free button. Users of these devices often seize specific appearance free button. Users of these devices often seize specific appearance
numbers for outgoing calls, and the UA will need to seize the numbers for outgoing calls, and the UA will need to seize the
appearance number and wait for confirmation from the Appearance Agent appearance number and wait for confirmation from the Appearance Agent
skipping to change at page 23, line 34 skipping to change at page 25, line 29
that the order should be consistent. These devices can typically that the order should be consistent. These devices can typically
make calls without waiting for confirmation from the Appearance Agent make calls without waiting for confirmation from the Appearance Agent
on the appearance number. on the appearance number.
8.1.5. Example User Interface Issues 8.1.5. Example User Interface Issues
The problems faced by each style of user interface are readily seen The problems faced by each style of user interface are readily seen
in this example: in this example:
1. A call arrives at the shared appearance group, and is assigned an 1. A call arrives at the shared appearance group, and is assigned an
appearance number of 0. All UAs should be able to render to the appearance number of "1". All UAs should be able to render to
user the arrival of this call. the user the arrival of this call.
2. Another call arrives at the shared appearance group, and is 2. Another call arrives at the shared appearance group, and is
assigned an appearance number of 1. The single appearance UA assigned an appearance number of "2". The single appearance UA
should not present this call to the user. Other user agents should not present this call to the user. Other user agents
should have no problems presenting this call distinctly from the should have no problems presenting this call distinctly from the
first call. first call.
3. The first call clears, releasing appearance number "0". The 3. The first call clears, releasing appearance number "1". The
single appearance UA should now be indicating no calls since it single appearance UA should now be indicating no calls since it
is unable to manage calls other than on the first appearance. is unable to manage calls other than on the first appearance.
Both shared appearance UAs should clearly show that appearance Both shared appearance UAs should clearly show that appearance
number 0 is now free, but that there is still a call on number "1" is now free, but that there is still a call on
appearance number 1. appearance number "2".
4. A third call arrives, and is assigned the appearance number of 0. 4. A third call arrives, and is assigned the appearance number of
All UAs should be able to render the arrival of this new call to "1". All UAs should be able to render the arrival of this new
the user. Multiple appearance UAs should continue to indicate call to the user. Multiple appearance UAs should continue to
the presence of the second call, and should also ensure that the indicate the presence of the second call, and should also ensure
presentation order is related to the appearance number and not that the presentation order is related to the appearance number
the order of call arrival. and not the order of call arrival.
8.2. Call State Rendering 8.2. Call State Rendering
UAs that implement the shared appearance feature typically have a UAs that implement the shared appearance feature typically have a
user interface that provides the state of other appearances in the user interface that provides the state of other appearances in the
group. As dialog state NOTIFYs from the Appearance Agent are group. As dialog state NOTIFYs from the Appearance Agent are
processed, this information can be rendered. Even the simplest user processed, this information can be rendered. Even the simplest user
interface typically has three states: idle, active, and hold. The interface typically has three states: idle, active, and hold. The
idle state, usually indicated by lamp off, is indicated for an idle state, usually indicated by lamp off, is indicated for an
appearance when the appearance number is not associated with any appearance when the appearance number is not associated with any
dialogs, as reported by the Appearance Agent. The active state, dialogs, as reported by the Appearance Agent. The active state,
usually indicated by a lamp on, is indicated by an appearance number usually indicated by a lamp on, is indicated by an appearance number
being associated with at least one dialog, as reported by the being associated with at least one dialog, as reported by the
Appearance Agent. The hold state, often indicated by a blinking Appearance Agent. The hold state, often indicated by a blinking
lamp, means the call state from the perspective of the UA in the lamp, means the call state from the perspective of the UA in the
shared appearance group is hold. This can be determined by the shared appearance group is hold. This can be determined by the
presence of the "sip+rendering=no" feature tag [RFC3840] with the presence of the "+sip.rendering=no" feature tag [RFC3840] with the
local target URI. Note that the hold state of the remote target URI local target URI. Note that the hold state of the remote target URI
is not relevant to this display. For joined dialogs, the state is is not relevant to this display. For joined dialogs, the state is
rendered as hold only if all local target URIs are indicated with the rendered as hold only if all local target URIs are indicated with the
"sip+rendering=no" feature tag. "+sip.rendering=no" feature tag.
9. Interop with non-Shared Appearance UAs 9. Interoperability with non-Shared Appearance UAs
It is desirable to allow a basic UA that does not directly support It is desirable to allow a basic UA that does not directly support
shared appearance to be part of a shared appearance group. To shared appearance to be part of a shared appearance group. To
support this the Proxy must collaborate with the Appearance Agent. support this the Proxy must collaborate with the Appearance Agent.
This is not required in the basic shared appearance architecture, This is not required in the basic shared appearance architecture,
consequently shared appearance interop with non-shared appearance UAs consequently shared appearance interoperability with non-shared
will not be available in all shared appearance deployments. appearance UAs will not be available in all shared appearance
deployments.
First, a UA which does not support dialog events or the shared First, a UA which does not support dialog events or the shared
appearance feature will be discussed. Then, a UA which does support appearance feature will be discussed. Then, a UA which does support
dialog events but not the shared appearance feature will be dialog events but not the shared appearance feature will be
discussed. discussed.
9.1. Appearance Assignment 9.1. Appearance Assignment
A UA that has no knowledge of appearances must will only have A UA that has no knowledge of appearances must will only have
appearance numbers for outgoing calls if assigned by the Appearance appearance numbers for outgoing calls if assigned by the Appearance
skipping to change at page 58, line 8 skipping to change at page 60, line 14
11.13. Appearance Agent Subscription to UAs 11.13. Appearance Agent Subscription to UAs
In this scenario, the Appearance Agent does not have any way of In this scenario, the Appearance Agent does not have any way of
knowing Bob's dialog state information, except through Bob. This knowing Bob's dialog state information, except through Bob. This
could be because the Appearance Agent is not part of a B2BUA, or could be because the Appearance Agent is not part of a B2BUA, or
perhaps Bob is remotely registering. When Bob registers, the perhaps Bob is remotely registering. When Bob registers, the
Appearance Agent receives a registration event package notification Appearance Agent receives a registration event package notification
from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's
dialog event state using Event:dialog in the SUBSCRIBE. Whenever dialog event state using Event:dialog in the SUBSCRIBE. Whenever
Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance
who then notifies the other other UAs in the group. Agent which then notifies the other other UAs in the group.
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<| |
skipping to change at page 63, line 18 skipping to change at page 66, line 10
semantics provided by [RFC3261], Event Package for Dialog State as semantics provided by [RFC3261], Event Package for Dialog State as
define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
[RFC3903], security considerations in these documents apply to this [RFC3903], security considerations in these documents apply to this
draft as well. draft as well.
NOTIFY or PUBLISH message bodies that provide the dialog state NOTIFY or PUBLISH message bodies that provide the dialog state
information and the dialog identifiers MAY be encrypted end-to-end information and the dialog identifiers MAY be encrypted end-to-end
using the standard mechanisms. All SUBSCRIBES between the UA's and using the standard mechanisms. All SUBSCRIBES between the UA's and
the Appearance Agent MUST be authenticated. the Appearance Agent MUST be authenticated.
For an emergency call, a UA MUST never wait for a confirmed seizure
of an appearance before sending an INVITE. Instead, the emergency
call MUST proceed regardless of the status of the PUBLISH
transaction.
13. IANA Considerations 13. IANA Considerations
This section registers the SIP event package parameter 'shared', the This section registers the SIP event package parameter 'shared', the
SIP Alert-Info header field parameter "appearance" and the XML SIP Alert-Info header field parameter "appearance" and the XML
namespace extensions to the SIP Dialog Package. namespace extensions to the SIP Dialog Package.
13.1. SIP Event Package Parameter: shared 13.1. SIP Event Package Parameter: shared
This specification defines a new event parameter 'shared' for the This specification defines a new event parameter 'shared' for the
Dialog Package. When used in a NOTIFY, it indicates that the Dialog Package. When used in a NOTIFY, it indicates that the
skipping to change at page 66, line 30 skipping to change at page 69, line 30
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[I-D.ietf-salud-alert-info-urns] [I-D.ietf-salud-alert-info-urns]
Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and
A. Siddiqui, "Alert-Info URNs for the Session Initiation A. Siddiqui, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-ietf-salud-alert-info-urns-00 (work Protocol (SIP)", draft-ietf-salud-alert-info-urns-02 (work
in progress), December 2010. in progress), May 2011.
15.2. Informative References 15.2. Informative References
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008. Examples", BCP 144, RFC 5359, October 2008.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", (SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
 End of changes. 61 change blocks. 
226 lines changed or deleted 284 lines changed or added

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