draft-ietf-bliss-shared-appearances-15.txt   rfc7463.txt 
BLISS A. Johnston, Ed. Internet Engineering Task Force (IETF) A. Johnston, Ed.
Internet-Draft Avaya Request for Comments: 7463 Avaya
Updates: 3261, 4235 (if approved) M. Soroushnejad Updates: 3261, 4235 M. Soroushnejad, Ed.
Intended status: Standards Track V. Venkataramanan Category: Standards Track V. Venkataramanan
Expires: July 20, 2013 Sylantro Systems Corp ISSN: 2070-1721 Sylantro Systems Corp.
January 16, 2013 March 2015
Shared Appearances of a Session Initiation Protocol (SIP) Address of Shared Appearances of a Session Initiation Protocol (SIP)
Record (AOR) Address of Record (AOR)
draft-ietf-bliss-shared-appearances-15
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 Private
offerings and is likely to be implemented on SIP IP telephones and Branch Exchange (IPBX) offerings and is likely to be implemented on
SIP feature servers used in a business environment. This feature SIP IP telephones and SIP feature servers used in a business
allows several user agents (UAs) to share a common AOR, learn about environment. This feature allows several user agents (UAs) to share
calls placed and received by other UAs in the group, and pick up or a common AOR, learn about calls placed and received by other UAs in
join calls within the group. This document discusses use cases, the group, and pick up or join calls within the group. This document
lists requirements and defines extensions to implement this feature. discusses use cases, lists requirements, and defines extensions to
This specification updates RFC3261 and RFC4235. implement this feature. This specification updates RFCs 3261 and
4235.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 20, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7463.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 29
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6
3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements and Implementation . . . . . . . . . . . . . . . 7 4. Requirements and Implementation . . . . . . . . . . . . . . . 6
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8
5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12 5.2.1. The <appearance> Element . . . . . . . . . . . . . . 11
5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 13 5.2.2. The <exclusive> Element . . . . . . . . . . . . . . . 12
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13 5.2.3. The <joined-dialog> Element . . . . . . . . . . . . . 12
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 14 5.2.4. The <replaced-dialog> Element . . . . . . . . . . . . 13
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13
5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16
5.3.2. Appearance Numbers and Call Control . . . . . . . . . 18 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17
5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 19 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 18
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21
7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23 7. Alert-Info Appearance Parameter Definition . . . . . . . . . 23
8. User Interface Considerations . . . . . . . . . . . . . . . . 24 8. User Interface Considerations . . . . . . . . . . . . . . . . 24
8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24
8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24
8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24
8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 25 8.1.3. Shared Appearance UAs with Fixed Appearance Number . 25
8.1.4. Shared Appearance UAs with Variable Appearance 8.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 25 Numbers . . . . . . . . . . . . . . . . . . . . . . . 25
8.1.5. Example User Interface Issues . . . . . . . . . . . . 25 8.1.5. Example User Interface Issues . . . . . . . . . . . . 25
8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26
9. Interoperability with non-Shared Appearance UAs . . . . . . . 26 9. Interoperability with Non-shared Appearance UAs . . . . . . . 26
9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26
9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27
9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27
10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27
11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28
11.1. Registration and Subscription . . . . . . . . . . . . . . 28 11.1. Registration and Subscription . . . . . . . . . . . . . 28
11.2. Appearance Selection for Incoming Call . . . . . . . . . 32 11.2. Appearance Selection for Incoming Call . . . . . . . . . 32
11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35
11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 38 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . 38
11.5. Outgoing Call without using an Appearance Number . . . . 42 11.5. Outgoing Call without Using an Appearance Number . . . . 42
11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44
11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 45 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . 45
11.8. Calls between UAs within the Group . . . . . . . . . . . 50 11.8. Call between UAs within the Group . . . . . . . . . . . 50
11.9. Consultation Hold with Appearances . . . . . . . . . . . 52 11.9. Consultation Hold with Appearances . . . . . . . . . . . 52
11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 55 11.10. Joining or Bridging an Appearance . . . . . . . . . . . 55
11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58 11.11. Loss of Appearance during Allocation . . . . . . . . . . 58
11.12. Appearance Seizure Contention Race Condition . . . . . . 59 11.12. Appearance Seizure Contention Race Condition . . . . . . 59
11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60
11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62
11.15. Appearance Seizure Incoming/Outgoing Contention Race 11.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . . 65 Condition . . . . . . . . . . . . . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 66 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
13.1. SIP Event Header Field Parameter: shared . . . . . . . . 66 13.1. SIP Event Header Field Parameter: shared . . . . . . . . 67
13.2. SIP Alert-Info Header Field Parameter: appearance . . . . 67 13.2. SIP Alert-Info Header Field Parameter: appearance . . . 68
13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68 13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68
13.4. XML Schema Registration . . . . . . . . . . . . . . . . . 68 13.4. XML Schema Registration . . . . . . . . . . . . . . . . 68
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 14.1. Normative References . . . . . . . . . . . . . . . . . . 69
15.1. Normative References . . . . . . . . . . . . . . . . . . 69 14.2. Informative References . . . . . . . . . . . . . . . . . 70
15.2. Informative References . . . . . . . . . . . . . . . . . 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
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 UAs, both in terms of services and end-user experience. In
In addition to basic SIP support [RFC3261], many of the services in a 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 [RFC6665], PUBLISH [RFC3903], the
[I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces SIP Replaces [RFC3891], and Join [RFC3911] header fields, etc. Many
[RFC3891], and Join [RFC3911] header fields, etc. Many of the of the popular business services have been documented in the SIP
popular business services have been documented in the SIP Service Service Examples [RFC5359].
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 standard SIP [RFC3261] in conjunction with SIP events [RFC6665] and
[I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] (carrying the publication [RFC3903] (carrying the SIP dialog state event package
SIP dialog state event package [RFC4235]) for exchanging status among [RFC4235]) for exchanging status among UAs.
user agents.
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) where each screen icon) and a button (used to select the appearance) where each
appearance number is associated with a different dialog to/from the appearance number is associated with a different dialog to/from the
AOR. The telephony concept of line appearance is still relevant to AOR. The telephony concept of line appearance is still relevant to
SIP due to the user interface considerations. It is important to SIP due to the user interface considerations. It is important to
keep the appearance number construct because: 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
pickup line 3"). "Joe 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, the appearance to another). If a telephone has enough buttons/lamps, the appearance
number could be the positional sequence number of the button. If number could be the positional sequence number of the button. If
not, it may still be desirable to present the call state, but the not, it may still be desirable to present the call state, but the
appearance number should be displayed so that users know which call, appearance number should be displayed so that users know which call,
for example, is on hold on which key. 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.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119]
indicate requirement levels for compliant mechanisms. and indicate requirement levels for compliant mechanisms.
3. Usage Scenarios 3. Usage Scenarios
The following examples are common applications of the Shared The following examples are common applications of the shared
Appearances feature and are mentioned here as informative use cases. appearances feature and are mentioned here as informative use cases.
All these example usages can be supported by the Shared Appearances All these example usages can be supported by the shared appearances
feature described in this document. The main differences relate to feature described in this document. The main differences relate to
the user interface considerations of the device. the user interface considerations of the device.
3.1. Executive/Assistant Arrangement 3.1. Executive/Assistant Arrangement
The appearances on the executive's UA also appear on the assistant's The appearances on the executive's UA also appear on the assistant's
UA. The assistant may answer incoming calls to the executive and UA. The assistant may answer incoming calls to the executive and
then place the call on hold for the executive to pick up. The then place the call on hold for the executive to pick up. The
assistant can always see the state of all calls on the executive's assistant can always see the state of all calls on the executive's
UA. UA.
3.2. Call Group 3.2. Call Group
Users with similar business needs or tasks can be assigned to Users with similar business needs or tasks can be assigned to
specific groups and share an AOR. For example, an IT department specific groups and share an AOR. For example, an IT department
staff of five might answer a help line which has three appearances on staff of five might answer a help line that has three appearances on
each phone in the IT work area. A call answered on one phone can be each 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 put 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 another staff member can result in them taking over a call on a
particular appearance. Another phone can request to be added/joined/ particular appearance. Another phone can request to be added/joined/
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
seizes the line (i.e. goes off hook), it is immediately bridged or seizes the line (i.e., goes off-hook), it is immediately bridged or
joined in with the call. This mimics the way residential telephone joined in with the call. This mimics the way residential telephone
extensions usually operate. extensions usually operate.
3.4. Changing UAs 3.4. Changing UAs
A user is on a call on one UA and wishes to change devices and A user is on a call on one UA and wishes to change devices and
continue the call on another UA. They place the call on hold, note continue the call on another UA. They place the call on hold, note
the appearance number of the call, then walk to another UA. They are the appearance number of the call, then walk to another UA. They are
able to identify the same appearance number on the other UA, pickup able to identify the same appearance number on the other UA, pick up
the call, and continue the conversation. the call, and continue the conversation.
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 feature.
4.1. Requirements 4.1. Requirements
The basic requirements of the shared appearance feature can be The basic requirements of the shared appearances feature can be
summarized as follows: summarized as follows:
REQ-1 Incoming calls to the AOR must be offered to a group of UAs and REQ-1: Incoming calls to the AOR must be offered to a group of UAs
can be answered by any of them. and can be answered by any of them.
REQ-2 Each UA in the group must be able to learn the call status of REQ-2: Each UA in the group must be able to learn the call status
the others in the group for the purpose of rendering this information of the others in the group for the purpose of rendering this
to the user. information to the user.
REQ-3 A UA must be able to join (also called bridge or conference REQ-3: A UA must be able to join (also called bridge or conference
together) or pick up (take) an active call of another UA in the group together) or pick up (take) an active call of another UA in
in a secure way. the group in a secure way.
REQ-4 The mechanism should require the minimal amount of REQ-4: The mechanism should require the minimal amount of
configuration. UAs registering against the group AOR should be able configuration. UAs registering against the group AOR should
to participate in the appearance group without manual configuration be able to participate in the shared appearance group
of group members. without manual configuration of group members.
REQ-5 The mechanism must scale for large numbers of appearances and REQ-5: The mechanism must scale for large numbers of appearances
large numbers of UAs without introducing excessive messaging traffic. and large numbers of UAs without introducing excessive
messaging traffic.
REQ-6 Each call or session (incoming or outgoing) should be assigned REQ-6: Each call or session (incoming or outgoing) should be
a common "appearance" number from a managed pool administered for the assigned a common "appearance" number from a managed pool
AOR group. Once the session has terminated, the appearance number is administered for the AOR group. Once the session has
released back into the pool and can be reused by another incoming or terminated, the appearance number is released back into the
outgoing session. pool and can be reused by another incoming or outgoing
session.
REQ-7 Each UA in the group must be able to learn the status of all REQ-7: Each UA in the group must be able to learn the status of all
appearances of the group. appearances of the group.
REQ-8 There must be mechanisms to resolve appearance contention among REQ-8: There must be mechanisms to resolve appearance contention
the UAs in the group. Contention in this context means an appearance among the UAs in the group. Contention in this context
number being associated with multiple dialogs that are not mixed or means an appearance number being associated with multiple
otherwise associated. dialogs that are not mixed or otherwise associated.
REQ-9 The mechanism must allow all UAs receiving an incoming session REQ-9: The mechanism must allow all UAs receiving an incoming
request to utilize the same appearance number at the time of session request to utilize the same appearance number at the
alerting. time of 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
processing. traffic and processing.
REQ-11 The mechanism must have backwards compatibility such that a UA REQ-11: The mechanism must have backwards compatibility such that a
which is unaware of the feature can still register against the group UA that is unaware of the feature can still register against
AOR and make and receive calls. the group 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
seize or manipulate appearance numbers. select, 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
"So who do you have on line 1?") UAs (e.g., "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
requesting it desires to have a private conversation with the the UA requesting it desires a private conversation with the
external party and other UAs must not be allowed to join or take the external party and other UAs must not be allowed to join or
call. Exclusivity may be requested at the start of an incoming or take the call. Exclusivity may be requested at the start of
outgoing session or during the session. An exclusivity request may an incoming or outgoing session or during the session. An
be accepted or rejected by the entity providing the shared appearance exclusivity request may be accepted or rejected by the
service. Therefore, the mechanism must provide a way of entity providing the shared appearance service. Therefore,
communicating the result back to the requester UA. the mechanism must provide a way of 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
the actual request. This is often called seizure. sending 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
particular appearance number and also send the request at the same particular appearance number and also send the request at
time. This is needed when an automatic ringdown feature (a telephone the same time. This is needed when an automatic ringdown
configured to immediately dial a phone number when it goes off hook) feature (a telephone configured to immediately dial a phone
is combined with shared appearances - in this case, seizing the line number when it goes off-hook) is combined with shared
is integrated with dialing. appearances. In this case, seizing the line is integrated
with dialing.
4.2. Implementation 4.2. Implementation
This section non-normatively discusses the implementation of the This section non-normatively discusses the implementation of the
shared appearance feature. The normative description is in shared appearances feature. The normative description is in
Section 5. Many of the requirements for this service can be met Section 5. Many of the requirements for this service can be met
using standard SIP mechanisms such as: using standard SIP mechanisms such as:
- A SIP Forking Proxy and Registrar/Location Service meets REQ-1. o A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
- The SIP Dialog Package meets REQ-2. o The SIP Dialog Package meets REQ-2.
- The combination of the SIP Replaces and Join header fields meets o The combination of the SIP Replaces and Join header fields meets
REQ-3. REQ-3.
- The use of a State Agent for the Dialog Package meets REQ-4 and o 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 that 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 that has taken on this functionality for a group. member UA that has taken on this functionality for a group. The
The Appearance Agent knows or is able to determine the dialog state Appearance Agent knows or is able to determine the dialog state of
of all members of the group. all members of the group.
While the appearance resource could be managed co-operatively by a While the appearance resource could be managed cooperatively 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 document. It is also possible that the Appearance Agent
could be distributed in all UAs in the group. For example, rules logic could be distributed in all UAs in the group. For example,
that govern assigning appearance numbers for incoming requests (e.g. rules that govern assigning appearance numbers for incoming requests
lowest available appearance number) and rules for contention handling (e.g., lowest available appearance number) and rules for contention
(e.g. when two UAs request the use of the same appearance number, handling (e.g., when two UAs request the use of the same appearance
hash dialog identifiers and compare with the lowest hash winning) number, hash dialog identifiers and compare with the lowest hash
would need to be defined and implemented. winning) would need to be defined and implemented.
To best meet REQ-9, the appearance number for an incoming INVITE To best meet REQ-9, the appearance number for an incoming INVITE
needs to be contained in the INVITE, in addition to being delivered needs to be contained in the INVITE, in addition to being delivered
in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or
lost, a UA in the group might receive an incoming INVITE but might lost, a UA in the group might receive an incoming INVITE but might
not know which appearance number to render during alerting. not know which appearance number to render during alerting.
This specification defines an extension parameter, which is This specification defines an extension parameter, which is
normatively defined in Section 7, for the Alert-Info header field in normatively defined in Section 7, for the Alert-Info header field in
RFC 3261 to carry the appearance number: RFC 3261 to carry the appearance number:
Alert-Info: <urn:alert:service:normal>;appearance=1 Alert-Info: <urn:alert:service:normal>;appearance=1
The following list describes the operation of the shared appearance The following list describes the operation of the shared appearances
feature. feature.
1. A UA is configured with the AOR of a shared appearance group. It 1. A UA is configured with the AOR of a shared appearance group. It
registers against the AOR, then attempts a dialog state registers against the AOR, then attempts a dialog state
subscription to the AOR. If the subscription fails, loops back subscription to the AOR. If the subscription fails, loops back
to itself, or returns an error, it knows there is no State Agent, to itself, or returns an error, it knows there is no State Agent
and hence no Appearance Agent and this feature is not and, hence, no Appearance Agent and this feature is not
implemented. implemented.
2. If the subscription receives a 200 OK, the UA knows there is a 2. If the subscription receives a 200 OK, the UA knows there is a
State Agent and that the feature is implemented. The UA then State Agent and that the feature is implemented. The UA then
follows the steps in this list. follows the steps in this list.
3. Information learned about the dialog state of other UAs in the 3. Information learned about the dialog state of other UAs in the
group is rendered to the user. group is rendered to the user.
4. Incoming calls are forked to all UAs in the group, and any may 4. Incoming calls are forked to all UAs in the group, and any may
answer. UAs receive the appearance number to use in rendering answer. UAs receive the appearance number to use in rendering
the incoming call in a NOTIFY from the Appearance Agent and in the incoming call in a NOTIFY from the Appearance Agent and in
the INVITE itself. The UA will also receive a notification if the INVITE itself. The UA will also receive a notification if
the call is answered by another UA in the group so this the call is answered by another UA in the group so this
information can be rendered to the user. information can be rendered to the user.
5. For outgoing calls, the operation depends on the implementation. 5. For outgoing calls, the operation depends on the implementation.
If the user seizes a particular appearance number for the call, If the user seizes a particular appearance number for the call,
the UA publishes the trying state dialog information with the the UA publishes the trying state dialog information with the
desired appearance number and waits for a 2xx response before desired appearance number and waits for a 2xx response before
sending the 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 want an appearance 7. For outgoing calls, if the user does not want an appearance
number assigned (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 [RFC7088]), the UA
[I-D.worley-service-example]), the UA also publishes prior to also publishes prior to sending the INVITE but does not include
sending the INVITE but does not include an appearance number in an appearance number in the publication.
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 direct 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. In of individual UAs in the group to obtain this information. In
any case, the Appearance Agent will send normal notifications any case, the Appearance Agent will send normal notifications
(via the subscriptions established by the UAs in step 1) every (via the subscriptions established by the UAs in step 1) every
time the aggregate dialog state of the AOR changes, including time the aggregate dialog state of the AOR changes, including
when calls are placed, answered, placed on and off hold, and hung when calls are placed, answered, placed on and off hold, and hung
up. up.
skipping to change at page 11, line 24 skipping to change at page 10, line 26
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. In of individual UAs in the group to obtain this information. In
any case, the Appearance Agent will send normal notifications any case, the Appearance Agent will send normal notifications
(via the subscriptions established by the UAs in step 1) every (via the subscriptions established by the UAs in step 1) every
time the aggregate dialog state of the AOR changes, including time the aggregate dialog state of the AOR changes, including
when calls are placed, answered, placed on and off hold, and hung when calls are placed, answered, placed on and off hold, and hung
up. up.
5. Normative Description 5. Normative Description
This section normatively describes the shared appearance feature This section normatively describes the shared appearances 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 Appearance number: An appearance number is a positive integer
associated with one or more dialogs of an AOR. Appearance numbers associated with one or more dialogs of an AOR. Appearance numbers
are managed by an Appearance Agent and displayed and rendered to the are managed by an Appearance Agent and displayed and rendered to
user by UAs that support this specification. When an appearance the user by UAs that support this specification. When an
number is assigned or requested, generally the assigned number is the appearance number is assigned or requested, generally the assigned
smallest positive integer that is not currently assigned as an number is the smallest positive integer that is not currently
appearance number to a dialog for this AOR. This specification does assigned as an appearance number to a dialog for this AOR. This
not define an upper limit on appearance numbers; however, using specification does not define an upper limit on appearance
appearance numbers that are not easily represented using common numbers; however, using appearance numbers that are not easily
integer representations is likely to cause failures. represented using common integer representations is likely to
cause failures.
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 (i.e. sending the INVITE), in order to appear as initiating a dialog (i.e., sending the INVITE), in order to appear
if it was already initiating a dialog. as if it were already initiating a dialog.
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
"trying" prior to initiating a dialog: i.e., the state is of "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
number is learned after the INVITE is sent. appearance number is learned after the INVITE is sent.
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. UAs that support publications, subscriptions, and notifications
notifications for the SIP dialog event package, and the shared for the SIP dialog event package and the shared appearance dialog
appearance dialog package extensions and behavior. 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
the shared appearance dialog package extensions and behavior. the shared appearance dialog package extensions and behavior.
The Appearance Agent also has logic for assigning and releasing The Appearance Agent also has logic for assigning and releasing
appearance numbers, and resolving appearance number contention. appearance numbers and resolving appearance number contention.
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 [RFC4235]. The schema is defined in Section 6. Dialog Event package [RFC4235]. The schema is defined in Section 6.
The elements are <appearance>, <exclusive>, <joined-dialog>, and The elements are <appearance>, <exclusive>, <joined-dialog>, and
<replaced-dialog> which are sub-elements of the <dialog> element. <replaced-dialog>, which are sub-elements of the <dialog> element.
5.2.1. The <appearance> element 5.2.1. The <appearance> Element
The <appearance> element, a child of the <dialog> element, is used to The <appearance> element, a child of the <dialog> element, is used to
convey the appearance number of the dialog described by the parent convey the appearance number of the dialog described by the parent
<dialog> element. When sent by a UA in a PUBLISH with parent <dialog> element. When sent by a UA in a PUBLISH with parent
<dialog> with state attribute "trying" to the Appearance Agent, the <dialog> with state attribute "trying" to the Appearance Agent, the
UA is requesting assignment of the given appearance number to the UA is requesting assignment of the given appearance number to the
current or future dialog with the given dialog identifiers. When an current or future dialog with the given dialog identifiers. When an
<appearance> element is sent by the Appearance Agent in a NOTIFY, it <appearance> element is sent by the Appearance Agent in a NOTIFY, it
indicates that the appearance number has been assigned to the indicates that the appearance number has been assigned to the
specified dialog. specified dialog.
skipping to change at page 13, line 5 skipping to change at page 12, line 10
Note that a <dialog-info> element describes the contained dialogs Note that a <dialog-info> element describes the contained dialogs
from the point of view of the UA (named by the "entity" attribute), 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 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 Appearance Agent. In particular, if the UA sent a request within the
described dialog, the To header field URI would match the <remote> described dialog, the To header field URI would match the <remote>
<identity> value and the to-tag parameter would match the remote-tag <identity> value and the to-tag parameter would match the remote-tag
attribute. Similarly, the From header field URI would match the attribute. Similarly, the From header field URI would match the
<local> <identity> value and the from-tag parameter would match the <local> <identity> value and the from-tag parameter would match the
local-tag attribute. local-tag attribute.
5.2.2. The <exclusive> element 5.2.2. The <exclusive> Element
The <exclusive> element, a child of the <dialog> element, is a The <exclusive> element, a child of the <dialog> element, is a
boolean, which when true, indicates that the UA is not willing to boolean, which, when true, indicates that the UA is not willing to
accept an INVITE with a Join or Replaces header field targeted to the accept an INVITE with a Join or Replaces header field targeted to the
dialog described by the <dialog> element that is the parent of the dialog described by the <dialog> element that is the parent of the
<exclusive> element. For example, some shared appearance systems <exclusive> element. For example, some shared appearance systems
only allow call pickup when the call is on hold. In this case, the only allow call pickup when the call is on hold. In this case, the
<exclusive> element should be set to "false" when the call is held <exclusive> element should be set to "false" when the call is held
and "true" when the call is not held, rather than having the and "true" when the call is not held, rather than having the
"exclusive" value implied by the hold state. "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
Join relating to this dialog. If these dialog identifiers have INVITE Join relating to this dialog. If these dialog identifiers
already been shared with the Appearance Agent, the UA could send an have already been shared with the Appearance Agent, the UA could send
INVITE Replaces to change them and then not report the new ones to an INVITE Replaces to change them and then not report the new ones to
the Appearance Agent. the Appearance Agent.
If the proxy knows which dialogs are marked exclusive, the proxy MAY If the proxy knows which dialogs are marked exclusive, the proxy MAY
enforce this exclusivity by rejecting INVITE Join and INVITE Replaces enforce this exclusivity by rejecting INVITE Join and INVITE Replaces
requests containing those dialog identifiers with a 403 Forbidden requests containing those dialog identifiers with a 403 (Forbidden)
response. response.
Note that exclusivity has nothing to do with appearance number Note that exclusivity has nothing to do with appearance number
selection or seizing - instead, it is about call control selection or seizing -- instead, it is about call control
operations that can be performed on a dialog. operations that can be performed on a dialog.
If the <exclusive> element is not present, it is assumed to be false. 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, a child of the <dialog> element, is used The <joined-dialog> element, a child of the <dialog> element, is used
to convey dialog identifiers of any other dialogs which are joined to convey dialog identifiers of any other dialogs that are joined
(mixed or bridged) with the dialog. Only the UA which is the common (mixed or bridged) with the dialog. Only the UA that is the common
endpoint of the mixed dialogs (and thus controlling the mixing endpoint of the mixed dialogs (and thus controlling the mixing
operation) should include this element in publications to the operation) should include this element in publications to the
Appearance Agent. Note that this element should still be used even Appearance Agent. Note that this element should still be used even
when the Join header field was not used to join the dialogs. For when the Join header field was not used to join the dialogs. For
example, two separate dialogs on a UA could be joined without any SIP example, two separate dialogs on a UA could be joined without any SIP
call control operations. Joined dialogs will share the same call control operations. Joined dialogs will share the same
appearance number. appearance number.
If the <joined-dialog> element is not present, it is assumed that the 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. 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, a child of the <dialog> element, is The <replaced-dialog> element, a child of the <dialog> element, is
used to convey dialog identifiers of any other dialogs which will be used to convey dialog identifiers of any other dialogs that will be
or have been replaced with this dialog. For example, a UA in the or have been replaced with this dialog. For example, a UA in the
group picking up a call on another UA by sending an INVITE with group picking up a call on another UA by sending an INVITE with
Replaces would include this element for the replacing dialog. Replaces would include this element for the replacing dialog.
Replaced dialogs will share the same appearance number. Replaced dialogs will share the same appearance number.
If the <replaced-dialog> element is not present, it is assumed that 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. 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 use the dialog UAs that support the shared appearances feature use the dialog state
state package [RFC4235] with the shared appearance extensions and the package [RFC4235] with the shared appearance extensions and the
'shared' Event header field parameter defined in Section 13. 'shared' Event header field parameter defined in Section 13.
User Agents use the dialog package extensions in Section 5.2 along UAs use the dialog package extensions in Section 5.2 along with
with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and PUBLISH SUBSCRIBE [RFC6665], NOTIFY [RFC6665], and PUBLISH [RFC3903].
[RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package
event package include the 'shared' Event header field parameter as include the 'shared' Event header field parameter as required by this
required by this specification. specification.
The presence of the 'shared' Event header field parameter tells The presence of the 'shared' Event header field parameter tells
the Appearance Agent that the UA supports this specification. the Appearance Agent that the UA supports this specification.
Upon initialization, the UA MUST subscribe to the dialog event Upon initialization, the UA MUST subscribe to the dialog event
package of the AOR and refresh the subscription per the SIP Events package of the AOR and refresh the subscription per the SIP Events
Framework. If the SUBSCRIBE request fails, then no Appearance Agent Framework [RFC6665]. If the SUBSCRIBE request fails, then no
may be present and this feature is not active for this AOR. The UA Appearance Agent may be present and this feature is not active for
MAY periodically retry the subscription to see if conditions have this AOR. The UA MAY periodically retry the subscription to see if
changed at intervals no shorter than 4 hours. conditions have changed at intervals no shorter than four hours.
Four hours was chosen to limit the subscription test to 6 per day Four hours was chosen to limit the subscription test to six per
per UA. Increasing this interval would reduce this failure day per UA. Increasing this interval would reduce this failure
traffic but take longer for a newly activated Appearance Agent to traffic but take longer for a newly activated Appearance Agent to
be discovered. be discovered.
UAs can also use the presence of the 'shared' Event header field UAs can also use the presence of the 'shared' Event header field
parameter in NOTIFYs to discover the presence of an Appearance Agent parameter in NOTIFYs to discover the presence of an Appearance Agent
for the AOR. for the AOR.
User Agents which implement the shared appearances feature and call UAs that implement the shared appearances feature, call pickup,
pickup, joining and bridging MUST support sending an INVITE with joining, and bridging MUST support sending an INVITE with Replaces
Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to [RFC3891] or Join [RFC3911]. The User Agent Client (UAC) needs to
include the to-tag and from-tag information in the Replaces or Join include the to-tag and from-tag information in the Replaces or Join
header so that the correct dialog will be matched by the User Agent header so that the correct dialog will be matched by the User Agent
Server per the rules in RFC 3891 and RFC 3911. Server (UAS) per the rules in RFCs 3891 and 3911.
All User Agents which implement the shared appearances feature and All UAs that implement the shared appearances feature and support
support INVITE MUST support receiving an INVITE with a Replaces INVITE MUST support receiving an INVITE with a Replaces [RFC3891] or
[RFC3891] or a Join [RFC3911] header field. a Join [RFC3911] header field.
When publishing or notifying dialog package information, a UA When publishing or notifying dialog package information, a UA
includes the largest set of dialog identification available at the includes the largest set of dialog identification available at the
time of publication, with the exception that a UA may omit time of publication, with the exception that a UA may omit
information if it wishes to prevent other UAs from joining or picking information if it wishes to prevent other UAs from joining or picking
up a call. Dialog identification includes local and remote target up a call. Dialog identification includes local and remote target
URIs, call-id, to-tag, and from-tag. While this dialog URIs, call-id, to-tag, and from-tag. While this dialog
identification information is optional in [RFC4235], it is essential identification information is optional in [RFC4235], it is essential
in the shared appearance feature, allowing call control operations. in the shared appearances feature, allowing call control operations.
When placing calls on hold, use the "+sip.rendering=no" feature tag When placing calls on hold, use the "+sip.rendering=no" feature tag
to indicate this in dialog package notifications. Using the full SDP to indicate this in dialog package notifications. Using the full SDP
session description instead forces the endpoint to do a lot of extra session description instead forces the endpoint to do a lot of extra
parsing, unnecessarily complicating the code and inviting errors. parsing, unnecessarily complicating the code and inviting errors.
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. appearances feature.
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.
If the call is an emergency call, a UA MUST never wait for a If the call is an emergency call, a UA MUST never wait for a
confirmed seizure before sending an INVITE. Instead, the emergency confirmed seizure before sending an INVITE. Instead, the emergency
call MUST proceed without waiting for the PUBLISH transaction. call MUST proceed without waiting for the PUBLISH transaction.
If a UA requires a particular appearance number, the a UA MUST send a If a UA requires a particular appearance number, the a UA MUST send a
dialog package PUBLISH request and wait for a 2xx response before dialog package PUBLISH request and wait for a 2xx response before
sending the INVITE. This is required in the following situations: sending the INVITE. This is required in the following situations:
1. When the user seizes a particular appearance number for an 1. When the user seizes a particular appearance number for an
outgoing call (e.g. 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
media' call such as for music on hold 'service media' call such as for music on hold [RFC7088], or for
[I-D.worley-service-example] or for a call not considered part of 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.
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 (numbers 1 and 2 in the above list), not all dialog
available. In particular, when a UA publishes an attempt to seize an information will be available. In particular, when a UA publishes an
appearance prior to knowing the destination URI, minimal or no dialog attempt to seize an appearance prior to knowing the destination URI,
information may be available. For example, in some cases, only the minimal or no dialog information may be available. For example, in
local target URI for the call will be known and no dialog some cases, only the local target URI for the call will be known: not
information. If the From tag and Call-ID were not present in the any dialog information. If the From tag and Call-ID were not present
initial PUBLISH, a new PUBLISH MUST be sent as soon as this in the initial PUBLISH, a new PUBLISH MUST be sent as soon as this
information is available. 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 This specification assumes that the Appearance Agent has other
means besides UA publication to learn about the state of UA means besides UA publication to learn about the state of UA
dialogs. In this specification, PUBLISH is used to indicate dialogs. In this specification, PUBLISH is used to indicate
desired and intended appearance number operations. Once a dialog desired and intended appearance number operations. Once a dialog
transitions from early to confirmed, this role is over, and hence transitions from early to confirmed, this role is over; hence, no
no publication refreshes are needed. 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. In a the value and usefulness of these protocol extensions. In a
correctly designed user interface for this feature, the appearances correctly designed user interface for this feature, the appearances
number for each active and pending dialog is explicitly (i.e. by number for each active and pending dialog is explicitly (i.e., by
appearance number) or implicitly (using a user interface metaphor appearance number) or implicitly (using a user interface metaphor
that makes the numbering and ordering clear to the user) rendered to that makes the numbering and ordering clear to the user) rendered to
the user. The far end identity of each dialog (e.g. the remote party the user. The far-end identity of each dialog (e.g., the remote
identity) is not a useful replacement for the appearance number. The party identity) is not a useful replacement for the appearance
state of each appearance is also be rendered (idle, active, busy, number. The state of each appearance is also to be rendered (idle,
joined, etc.). UAs can tell that a set of dialogs are joined active, busy, joined, etc.). UAs can tell that a set of dialogs are
(bridged or mixed) together by the presence of one or more <joined- joined (bridged or mixed) together by the presence of one or more
dialog> elements containing other SIP dialog identifiers. Appearance <joined-dialog> elements containing other SIP dialog identifiers.
numbers of dialogs can be learned by dialog package notifications Appearance numbers of dialogs can be learned by dialog package
containing the <appearance> element from the Appearance Agent or from notifications containing the <appearance> element from the Appearance
the 'appearance' Alert-Info parameter in an incoming INVITE. Should Agent or from the 'appearance' Alert-Info parameter in an incoming
they conflict, the dialog package notification takes precedence. INVITE. Should they conflict, the dialog package notification takes
precedence.
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 frees up the appearance call (go back on-hook). In this case, the UA frees up the appearance
number by removing the event state with a PUBLISH as described in number by removing the event state with a PUBLISH as described in
[RFC3903]. A failure to do this will require extra unnecessary [RFC3903]. A failure to do this will require unnecessary operations
operations by the Appearance Agent, and also tie up appearance by the Appearance Agent and tie up appearance numbers that could
numbers which could otherwise be used by other UAs in the appearance otherwise be used by other UAs in the shared appearance group.
group.
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. If a monitoring UA registers rather not register against the AOR. If a monitoring UA registers rather
than just subscribing generates large amounts of unnecessary network than just subscribing, it generates large amounts of unnecessary
traffic. network traffic.
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.
A UA MUST NOT insert an 'appearance' parameter into an Alert-Info A UA MUST NOT insert an 'appearance' parameter into an Alert-Info
header field in an INVITE or other request. header field in an INVITE or other request.
The Appearance Agent is solely responsible for doing this. The Appearance Agent is solely responsible for doing this.
5.3.1. Appearance Numbers and Call Context 5.3.1. Appearance Numbers and Call Context
skipping to change at page 17, line 46 skipping to change at page 17, line 4
There are cases where two separate dialogs at a UA are not mixed but There are cases where two separate dialogs at a UA are not mixed but
share the same 'context'. That is, they relate to each other and share the same 'context'. That is, they relate to each other and
should not be treated the same as any other two dialogs within the should not be treated the same as any other two dialogs within the
group. One example of this is a 'consultation call' where a user group. One example of this is a 'consultation call' where a user
puts an existing dialog on hold, then calls another user, before puts an existing dialog on hold, then calls another user, before
switching back to the original dialog. Another case, described switching back to the original dialog. Another case, described
below, occurs during transfer operations, where for a transient below, occurs during transfer operations, where for a transient
period, a UA is involved in dialogs with two other UAs, but the period, a UA is involved in dialogs with two other UAs, but the
dialogs are related, and should not be treated as independent dialogs are related, and should not be treated as independent
dialogs. These cases are best handled by not assigning an appearance dialogs. These cases are best handled by not assigning an appearance
number to a newly-created dialog when it shares a context with an number to a newly created dialog when it shares a context with an
existing dialog. But if the pre-existing dialog is terminated, its existing dialog. But if the preexisting dialog is terminated, its
appearance number should be reassigned to the newly-created dialog. 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 that wants to place a call but does not have an appearance
assigned sends a PUBLISH before sending the INVITE. The PUBLISH does number assigned sends a PUBLISH before sending the INVITE. The
not have an 'appearance' element present, but does have the 'shared' PUBLISH does not have an 'appearance' element present, but it does
Event header field parameter present. If the Appearance Agent policy have the 'shared' Event header field parameter present. If the
does not allow calls without an assigned appearance number, a 400 Appearance Agent policy does not allow calls without an assigned
(Bad Request) response is sent by the Appearance Agent and the UA appearance number, a 400 (Bad Request) response is sent by the
will republish either selecting/seizing an appearance number or send Appearance Agent and the UA will republish either selecting/seizing
the INVITE without publishing, in which case the Appearance Agent an appearance number or send the INVITE without publishing, in which
will assign one. case the Appearance Agent will assign one.
Note that if an Appearance Agent rejects calls without an Note that if an Appearance Agent rejects calls without an
appearance number, certain operations such as consultation calls, appearance number, certain operations such as consultation calls,
transfer, and music on hold may be negatively impacted. transfer, and music on hold may be negatively 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
contains Join or Replaces with a dialog identifier of another dialog (i.e., contains Join or Replaces with a dialog identifier of another
in the shared appearance group), the UA MUST first send a PUBLISH to dialog in the shared appearance group), the UA MUST first send a
the Appearance Agent. This PUBLISH will contain: PUBLISH to the Appearance Agent. This PUBLISH will contain:
1. The appearance number of the joined or replaced call in the 1. The appearance number of the joined or replaced call in the
<appearance> element <appearance> element
2. If the dialog is being joined, the <joined-dialog> element will
contain the dialog information from the Join header field 2. The dialog information from the Join header field in the <joined-
3. If the dialog is being replaced, the <replaced-dialog> element dialog> element, if the dialog is being joined
will contain the dialog information from the Replaces header
field 3. The dialog information from the Replaces header field in the
<replaced-dialog> element, if the dialog is being replaced
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 (Bad Request) response due to the reuse of an generating a 400 (Bad Request) response due to the reuse of an
appearance number. For Replaces, the purpose of the <replaced- appearance number. For Replaces, the purpose of the <replaced-
dialog> is to prevent a race condition where the BYE could cause dialog> is to prevent a race condition where the BYE could cause
the appearance number to be released when it should stay with the the appearance number to be released when it should stay with the
replacing dialog. replacing 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 a shared appearance group, who is talking to
is outside the appearance group. Carol transfers Alice to David, who Carol, who is outside the shared appearance group. Carol transfers
is also outside the appearance group. For example, if Alice is using Alice to David, who is also outside the shared appearance group. For
appearance 3 for the session with Carol, the resulting session with example, if Alice is using appearance 3 for the session with Carol,
David should also use appearance number 3. Otherwise, an appearance the resulting session with David should also use appearance number 3.
number change can cause a "jump" on the UI and confusion to the user. Otherwise, an appearance number change can cause a "jump" on the UI
There are two possible scenarios using the terminology of RFC 5589: and confusion to the user. There are two possible scenarios using
Alice is the transferee in any type of transfer (receives the REFER) the terminology of RFC 5589: Alice is the transferee in any type of
or the transfer target in an attended transfer (receives the INVITE transfer (receives the REFER) or the transfer target in an attended
with Replaces). transfer (receives the INVITE with Replaces).
If Alice is the transferee, the triggered INVITE from the REFER is If Alice is the transferee, the triggered INVITE from the REFER is
treated as a consultation call. Alice SHOULD publish requesting that treated as a consultation call. Alice SHOULD publish requesting that
the Appearance Agent not assign an appearance number for this INVITE. the Appearance Agent not assign an appearance number for this INVITE.
When the transfer completes, Alice SHOULD publish again to move the When the transfer completes, Alice SHOULD publish again to move the
appearance number from the dialog with Carol to the dialog with appearance number from the dialog with Carol to the dialog with
David. If a PUBLISH is sent to move the appearance number, the David. If a PUBLISH is sent to move the appearance number, the
publication MUST be sent prior to sending the BYE to Carol to avoid a publication MUST be sent prior to sending the BYE to Carol to avoid a
race condition where the Appearance Agent reassigns the appearance race condition where the Appearance Agent reassigns the appearance
number after seeing the BYE. number after seeing the BYE.
skipping to change at page 19, line 41 skipping to change at page 18, line 51
extensions defined in Section 5.2 and use the 'shared' Event header extensions defined in Section 5.2 and use the 'shared' Event header
field parameter. The Appearance Agent MUST support publications and field parameter. The Appearance Agent MUST support publications and
subscriptions for this event package. subscriptions for this event package.
The Appearance Agent MUST have a way of discovering the state of all The Appearance Agent MUST have a way of discovering the state of all
dialogs associated with the AOR. If this information is not dialogs associated with the AOR. If this information is not
available from a call stateful proxy or Back-to-Back User Agent available from a call stateful proxy or Back-to-Back User Agent
(B2BUA), the Appearance Agent can use the registration event package (B2BUA), the Appearance Agent can use the registration event package
[RFC3680] to learn of UAs associated with the AOR and subscribe to [RFC3680] to learn of UAs associated with the AOR and subscribe to
their dialog event state. An Appearance Agent can also subscribe to their dialog event state. An Appearance Agent can also subscribe to
a UAs dialog event state in order to reconstruct state. As a result, a UA's dialog event state in order to reconstruct state. As a
the registrar MUST support the registration event package. Dialog result, the registrar MUST support the registration event package.
package notifications are recommended by RFC 4235 to "only contain
information on the dialogs whose state or participation information Dialog package notifications are recommended by RFC 4235 to "only
has changed." This specification extends RFC 4235 as follows. The contain information on the dialogs whose state or participation
Appearance Agent SHOULD send dialog event state notifications information has changed." This specification extends RFC 4235 as
whenever the following events happen to UAs in the AOR group: follows. The Appearance Agent SHOULD send dialog event state
notifications whenever the following events happen to UAs in the AOR
group:
1. A call is received, placed, answered, or terminated. 1. A call is received, placed, answered, or terminated.
2. A call is placed on or off hold. 2. A call is placed on or off hold.
3. A call is joined or replaced. 3. A call is joined or replaced.
4. An appearance number is reserved or released. 4. An appearance number is reserved or released.
The Appearance Agent MUST allocate an appearance number for all The Appearance Agent MUST allocate an appearance number for all
incoming calls and send immediate notifications to the UAs subscribed incoming calls and send immediate notifications to the UAs subscribed
to the shared group AOR. 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. If the INVITE Replaces or of the dialog being joined or replaced. If the INVITE Replaces or
Join comes from outside the appearance group, the Appearance Agent Join comes from outside the shared appearance group, the Appearance
will include a <joined-dialog> or <replaced-dialog> element in the Agent will include a <joined-dialog> or <replaced-dialog> element in
NOTIFY containing the dialog information from the Replaces or Joined the NOTIFY containing the dialog information from the Replaces or
header field. Joined header field.
The Appearance Agent MUST be able to communicate with the forking The Appearance Agent MUST be able to communicate with the forking
proxy to learn about incoming calls and also to pass the appearance proxy to learn about incoming calls and also to pass the appearance
number to the proxy, or otherwise ensure the Alert-Info header field number to the proxy or ensure the Alert-Info header field is included
is included in the INVITE with the appropriate appearance number. in the INVITE with the appropriate appearance number.
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 shared appearance group has appearance-unaware
making calls, the Appearance Agent will still allocate appearance UAs making calls, the Appearance Agent will still allocate
numbers for INVITEs sent by those UAs. appearance numbers for INVITEs sent by those UAs.
An Appearance Agent receiving a PUBLISH with an appearance number An Appearance Agent receiving a PUBLISH with an appearance number
checks to make sure the publication is valid. An appearance number checks to make sure the publication is valid. An appearance number
can be assigned to only one dialog unless there is a <joined-dialog> can be assigned to only one dialog unless there is a <joined-dialog>
or <replaced-dialog> element indicating that the dialog will be/has or <replaced-dialog> element indicating that the dialog will be/has
been replaced or joined. A 400 (Bad Request) response is returned if been replaced or joined. A 400 (Bad Request) response is returned if
the chosen appearance number is invalid, and an immediate NOTIFY the chosen appearance number is invalid, and an immediate NOTIFY
SHOULD be sent to the UA containing full dialog event state. SHOULD be sent to the UA containing full dialog event state.
An Appearance Agent receiving a PUBLISH without an appearance number An Appearance Agent receiving a PUBLISH without an appearance number
but with the 'shared' Event header field parameter present interprets but with the 'shared' Event header field parameter present interprets
this as a request by the UA to not assign an appearance number. If this as a request by the UA to not assign an appearance number. If
the Appearance Agent policy does not allow this, a 400 (Bad Request) the Appearance Agent policy does not allow this, a 400 (Bad Request)
response is returned. If policy does allow this, a 200 OK response response is returned. If policy does allow this, a 200 (OK) response
is returned and no appearance number is allocated. An Appearance is returned and no appearance number is allocated. An Appearance
Agent does not have to share this dialog information (i.e. send a Agent does not have to share this dialog information (i.e., send a
NOTIFY) with other UAs in the group as the information will not be NOTIFY) with other UAs in the group as the information will not be
rendered by the other UAs. rendered by the other UAs.
The Appearance Agent allocates an apperance number to a dialog from The Appearance Agent allocates an appearance 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
with the appearance is terminated, including all dialogs which are the appearance is terminated, including all dialogs that are joined
joined or replaced. During the early dialog state, the Appearance or replaced. During the early dialog state, the Appearance Agent
Agent controls the rate of dialog state publication using the Expires 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
3 minutes is RECOMMENDED. After the dialog associated with the of 3 minutes is RECOMMENDED. After the dialog associated with the
publication has been confirmed, the expiration of the publication publication has been confirmed, the expiration of the publication
state has no effect on the appearance allocation. If the publication state has no effect on the appearance allocation. If the publication
contains no dialog state information, the Appearance Agent MUST contains no dialog state information, the Appearance Agent MUST
reserve the appearance number for the UA but can not assign the reserve the appearance number for the UA but cannot assign the
appearance to any particular dialog of the UA. When the publication appearance to any particular dialog of the UA. When the publication
state is updated with any dialog information, the appearance number state is updated with any dialog information, the appearance number
can then be assigned to the particular dialog. A UA which has been can then be assigned to the particular dialog. A UA that has been
allocated an appearance number using a PUBLISH MAY free up the allocated an appearance number using a PUBLISH MAY free up the
appearance number by removing the event state with a PUBLISH as appearance number by removing the event state with a PUBLISH as
described in [RFC3903]. described in [RFC3903].
If an INVITE is sent by a member of the group to the shared AOR (i.e. If an INVITE is sent by a member of the group to the shared AOR
they call their own AOR), the Appearance Agent MUST assign two (i.e., they call their own AOR), the Appearance Agent MUST assign two
appearance numbers. The first appearance number will be the one appearance numbers. The first appearance number will be the one
selected or assigned to the outgoing INVITE. The second appearance selected or assigned to the outgoing INVITE. The second appearance
number will be another one assigned by the Appearance Agent for the number will be another one assigned by the Appearance Agent for the
INVITE as it is forked back to the members of the group. INVITE as it is forked back to the members of the group.
The is to preserve a common behavior in legacy systems. The is to preserve a common behavior in legacy systems.
If an INVITE is sent by a member of the group using the shared AOR or If an INVITE is sent by a member of the group using the shared AOR or
sent to the shared AOR and no appearance number is available, the sent to the shared AOR and no appearance number is available, the
proxy MAY reject the INVITE with a 403 Forbidden response code. proxy MAY reject the INVITE with a 403 (Forbidden) response code.
Appearance numbers are only used for dialogs in which one or more UAs Appearance numbers are only used for dialogs in which one or more UAs
associated with the group AOR is a participant. If an incoming associated with the group AOR are participants. If an incoming
INVITE to the group AOR is forwarded to another AOR, the appearance INVITE to the group AOR is forwarded to another AOR, the appearance
number is immediately freed up and can be assigned to another dialog. number is immediately freed up and can be assigned to another dialog.
6. XML Schema Definition 6. XML Schema Definition
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:
skipping to change at page 23, line 7 skipping to change at page 23, line 7
</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 [RFC3261] to add an 'appearance' parameter
parameter to the Alert-Info header field, and to also allow proxies to the Alert-Info header field and also to allow proxies to modify or
to modify or delete the Alert-Info header field. delete the Alert-Info header field.
The changes to RFC 3261 ABNF [RFC5234] are: The changes to the ABNF [RFC5234] in RFC 3261 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 1*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
Alert-Info policies. To indicate the appearance number for this Alert-Info policies. To indicate the appearance number for this
dialog, the proxy adds the Alert-Info header field with the dialog, the proxy adds the Alert-Info header field with the
'appearance' parameter to the INVITE. If an Alert-Info is already 'appearance' parameter to the INVITE. If an Alert-Info is already
present, the proxy adds the 'appearance' parameter to the Alert-Info present, the proxy adds the 'appearance' parameter to the Alert-Info
header field. If an appearance number parameter is already present header field. If an appearance number parameter is already present
(associated with another AOR or by mistake), the value is rewritten (associated with another AOR or by mistake), the value is rewritten
adding the new appearance number. There MUST NOT be more than one adding the new appearance number. There MUST NOT be more than one
appearance parameter in an Alert-Info header field. appearance parameter in an Alert-Info header field.
If no special ringtone is desired, a normal ringtone SHOULD be If no special ringtone is desired, a normal ringtone SHOULD be
indicated using the urn:alert:service:normal in the Alert-Info, as indicated using the urn:alert:service:normal in the Alert-Info, as
per [I-D.ietf-salud-alert-info-urns]. The appearance number present per [RFC7462]. The appearance number present in an Alert-Info header
in an Alert-Info header field SHOULD be rendered by the UA to the field SHOULD be rendered by the UA to the user, following the
user, following the guidelines in Section 5.3. If the INVITE is guidelines in Section 5.3. If the INVITE is forwarded to another
forwarded to another AOR, the appearance parameter in the Alert-Info AOR, the appearance parameter in the Alert-Info SHOULD be removed
SHOULD be removed before forwarding outside the group. before forwarding outside the group.
The determination as to what value to use in the appearance parameter The determination as to what value to use in the appearance parameter
can be done at the proxy that forks the incoming request to all the can be done at the proxy that forks the incoming request to all the
registered UAs. registered UAs.
There are a variety of ways the proxy can use to determine what There is a variety of ways the proxy can determine what value it
value it should use to populate this parameter. For example, the should use to populate this parameter. For example, the proxy
proxy could fetch this information by initiating a SUBSCRIBE could fetch this information by initiating a SUBSCRIBE request
request with Expires: 0 to the Appearance Agent for the AOR to with Expires: 0 to the Appearance Agent for the AOR to fetch the
fetch the list of lines that are in use. Alternatively, it could list of lines that are in use. Alternatively, it could act like a
act like a UA that is a part of the appearance group and SUBSCRIBE UA that is a part of the shared appearance group and SUBSCRIBE to
to the State-Agent like any other UA. This would ensure that the 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 shared appearance
and escape the proper Alert-Info header field for the Proxy to group URI and escape the proper Alert-Info header field for the
recurse and distribute to the other UAs in the group. Proxy to 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 seize the appearance number. One way in which the AOR in order to seize the appearance number. One way in which
this could be done is for the Appearance Agent to register against this could be done is for the Appearance Agent to register against
the AOR with a higher q value. This will result in the INVITE the AOR with a higher q value. This will result in the INVITE
being sent to the Appearance Agent first, then being offered to being sent to the Appearance Agent first, then being offered to
the UAs in the group. the UAs in the group.
8. User Interface Considerations 8. User Interface Considerations
The "appearance number" allocated to a call is an important concept The appearance number allocated to a call is an important concept
that enables calls to be handled by multiple devices with that enables calls to be handled by multiple devices with
heterogeneous user interfaces in a manner that still allows users to heterogeneous user interfaces in a manner that still allows users to
see a consistent model. Careful treatment of the appearance number see a consistent model. Careful treatment of the appearance number
is essential to meet the expectations of the users. Also, rendering is essential to meet the expectations of the users. Also, rendering
the correct call/appearance state to users is also important. the correct call/appearance state to users is also important.
8.1. Appearance Number Rendering 8.1. Appearance Number Rendering
Since different UAs have different user interface capabilities, it is Since different UAs have different user interface capabilities, it is
usual to find that some UAs have restrictions that others do not. usual to find that some UAs have restrictions that others do not.
skipping to change at page 24, line 38 skipping to change at page 24, line 40
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. The UA SHOULD displaying status indications for a single appearance. The UA SHOULD
still send messages annotated with appearance number "1". Any call still send messages annotated with appearance number "1". Any call
indications for appearances other than for number "1" SHOULD be indications for appearances other than for number "1" SHOULD be
rejected with a 486 or 480 response. Note that this means that a rejected with a 480 (Temporarily Unavailable) or 486 (Busy Here)
single appearance UA cannot answer its own call to the shared AOR, response. Note that this means that a single appearance UA cannot
since this call would use a second appearance number. answer its own call to the shared AOR, since this call would use a
second appearance number.
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 "1" and "2" 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
before proceeding with calls. before proceeding with calls.
8.1.4. Shared Appearance UAs with Variable Appearance Number 8.1.4. Shared Appearance UAs with Variable Appearance Numbers
This UA is typically a soft-phone or graphically rich user interface This UA is typically a soft-phone or graphically rich user interface
hard-phone. In these cases, even the idea of an appearance index may hard-phone. In these cases, even the idea of an appearance index may
seem unnecessary. However, for these phones to be able to interwork seem unnecessary. However, for these phones to be able to interwork
successfully with other phone types, it is important that they still successfully with other phone types, it is important that they still
use the appearance index to govern the order of appearance of calls use the appearance index to govern the order of appearance of calls
in progress. No specific guidance on presentation is given except in progress. No specific guidance on presentation is given except
that the order should be consistent. These devices can typically that the order should be consistent. These devices can typically
make calls without waiting for confirmation from the Appearance Agent make calls without waiting for confirmation from the Appearance Agent
on the appearance number. on the appearance number.
8.1.5. Example User Interface Issues 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 "1". All UAs should be able to render to appearance number of "1". All UAs should be able to render to
the 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 "2". 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 UAs should have
should have no problems presenting this call distinctly from the no problems presenting this call distinctly from the first call.
first call.
3. The first call clears, releasing appearance number "1". 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 "1" 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 "2". appearance number "2".
4. A third call arrives, and is assigned the appearance number of
4. A third call arrives and is assigned the appearance number of
"1". All UAs should be able to render the arrival of this new "1". All UAs should be able to render the arrival of this new
call to the user. Multiple appearance UAs should continue to call to the user. Multiple appearance UAs should continue to
indicate the presence of the second call, and should also ensure indicate the presence of the second call, and they should also
that the presentation order is related to the appearance number ensure that the presentation order is related to the appearance
and not the order of call arrival. number 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 appearances 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, means that an appearance number is
being associated with at least one dialog, as reported by the associated with at least one dialog, as reported by the Appearance
Appearance Agent. The hold state, often indicated by a blinking Agent. The hold state, often indicated by a blinking lamp, means the
lamp, means the call state from the perspective of the UA in the call state from the perspective of the UA in the shared appearance
shared appearance group is hold. This can be determined by the group is hold. This can be determined by the presence of the
presence of the "+sip.rendering=no" feature tag [RFC3840] with the "+sip.rendering=no" feature tag [RFC3840] with the local target URI.
local target URI. Note that the hold state of the remote target URI Note that the hold state of the remote target URI is not relevant to
is not relevant to this display. For joined dialogs, the state is this display. For joined dialogs, the state is rendered as hold only
rendered as hold only if all local target URIs are indicated with the if all local target URIs are indicated with the "+sip.rendering=no"
"+sip.rendering=no" feature tag. feature tag.
9. Interoperability 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 interoperability with non-shared consequently, shared appearance interoperability with non-shared
appearance UAs will not be available in all shared appearance appearance UAs will not be available in all shared appearance
deployments. deployments.
First, a UA which does not support dialog events or the shared First, a UA that does not support dialog events or the shared
appearance feature will be discussed. Then, a UA which does support appearances feature will be discussed. Then, a UA that does support
dialog events but not the shared appearance feature will be dialog events but not the shared appearances 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 will only have appearance
appearance numbers for outgoing calls if assigned by the Appearance numbers for outgoing calls if assigned by the Appearance Agent. If
Agent. If the non-shared appearance UA does not support Join or the non-shared appearance UA does not support Join or Replaces, all
Replaces, all dialogs SHOULD be marked "exclusive" to indicate that dialogs SHOULD be marked "exclusive" to indicate that these options
these options are not available. Marking these dialogs "exclusive" are not available. Marking these dialogs "exclusive" provides a
provides a better user experience and avoids extra SIP messaging better user experience and avoids extra SIP messaging failures.
failures.
9.2. Appearance Release 9.2. Appearance Release
In all cases the Appearance Agent must be aware of dialog lifetime to In all cases, the Appearance Agent must be aware of the dialog
release appearances back into the group. lifetime to release appearances back into the group.
It is also desirable that any dialog state changes (such as hold, It is also desirable that any dialog state changes (such as hold,
etc) be made available to other UAs in the group through the Dialog etc.) be made available to other UAs in the group through the Dialog
Event Package. If the Appearance Agent includes a proxy which Event Package. If the Appearance Agent includes a proxy that Record-
Record-Routes for dialogs from the non-shared appearance aware UA, Routes for dialogs from the non-shared-appearance-aware UA, the
the Appearance Agent will know about the state of dialogs including Appearance Agent will know about the state of dialogs including hold,
hold, etc. This information could be determined from inspection of etc. This information could be determined from inspection of non-
non-end-to-end-encrypted INVITE and re-INVITE messages and added to end-to-end-encrypted INVITE and re-INVITE messages and added to the
the dialog information conveyed to other UAs. dialog information conveyed to other UAs.
9.3. UAs Supporting Dialog Events but Not Shared Appearance 9.3. UAs Supporting Dialog Events but Not Shared Appearance
Interoperability with UAs which support dialog events but not the Interoperability with UAs that support dialog events but not the
shared appearance feature is more straightforward. As before, all shared appearances feature is more straightforward. As before, all
appearance number assignment must be done by the Appearance Agent. appearance number assignments must be done by the Appearance Agent.
The Appearance Agent SHOULD still include appearance information in The Appearance Agent SHOULD still include appearance information in
NOTIFYs - this UA will simply ignore this extra information. This NOTIFYs -- this UA will simply ignore this extra information. This
type of UA will also ignore appearance number limitations and may type of UA will also ignore appearance number limitations and may
attempt to Join or Replace dialogs marked exclusive. As a result, attempt to join or replace dialogs marked exclusive. As a result,
the Proxy or UAs need to reject such requests or the dialogs will get the Proxy or UAs need to reject such requests or the dialogs will be
joined or taken. joined or taken.
10. Provisioning Considerations 10. Provisioning Considerations
UAs can automatically discover if this feature is active for an AOR UAs can automatically discover if this feature is active for an AOR
by looking for the 'shared' Event header field parameter in a by looking for the 'shared' Event header field parameter in a
response to a dialog package SUBSCRIBE to the AOR, so no provisioning response to a dialog package SUBSCRIBE to the AOR, so no provisioning
for this is needed. for this is needed.
The registrar will need to be provisioned to accept either first or The registrar will need to be provisioned to accept either first or
third party registrations for the shared AOR. First party third party registrations for the shared AOR. First party
registration means the To and From URIs in the REGISTER request are registration means the To and From URIs in the REGISTER request are
the shared AOR URI. Third party registration means the To URI is the the shared AOR URI. Third-party registration means the To URI is the
shared AOR URI and the From URI is a different AOR, perhaps that of shared AOR URI and the From URI is a different AOR, perhaps that of
the individual user. Either the credentials of the shared AOR or the the individual user. Either the credentials of the shared AOR or the
user MUST be accepted by the registrar and the Appearance Agent, user MUST be accepted by the registrar and the Appearance Agent,
depending on the authorization policy in place for the domain. depending on the authorization policy in place for the domain.
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.
In some cases, UAs in the shared appearance group might have a UI In some cases, UAs in the shared appearance group might have a UI
limitation on the number of appearances that can be rendered. limitation on the number of appearances that can be rendered.
Typically this will be hard phones with buttons/lamps instead of more
flexible UIs. In this case, it can be useful for the Appearance Typically, this will be hard-phones with buttons/lamps instead of
more flexible UIs. In this case, it can be useful for the Appearance
Agent to know this maximum number. This can allow the Appearance Agent to know this maximum number. This can allow the Appearance
Agent to apply policy when this limit is reached, e.g. deny a call. Agent to apply policy when this limit is reached, e.g., deny a call.
However, this mechanism does not provide any way to discover this by However, this mechanism does not provide any way to discover this by
protocol means. protocol means.
11. Example Message Flows 11. Example Message Flows
The next section shows call flow and message examples. The flows and The next section shows call flow and message examples. The flows and
descriptions are non-normative. Note that in these examples, all descriptions are non-normative. Note that, in these examples, all
INVITEs sent by a UA in the group will be From the shared AOR INVITEs sent by a UA in the group will be From the shared AOR
(sip:HelpDesk@example.com in this case), and all INVITES sent to the (sip:HelpDesk@example.com in this case), and all INVITES sent to the
group will have a Request-URI of the shared AOR. Any other requests group will have a Request-URI of the shared AOR. Any other requests
would not apply to this feature and would be handled using normal SIP would not apply to this feature and would be handled using normal SIP
mechanisms. mechanisms.
Note that the first twelve examples assume the Appearance Agent is Note that the first 12 examples assume the Appearance Agent is aware
aware of dialog state events. The example in Section 11.13 shows the of dialog state events. The example in Section 11.13 shows the case
case where this is not the case and as a result the Appearance Agent 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 initiates a subscription to users of the shared AOR. Any of the
other call flow examples could have shown this mode of operation as other call flow examples could have shown this mode of operation as
it is equally valid. it is equally valid.
11.1. Registration and Subscription 11.1. Registration and Subscription
Bob and Alice are in an appearance group identified by the shared Bob and Alice are in a shared appearance group identified by the
appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact shared appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using
sip:bob@ua2.example.com. Alice REGISTERs with contact 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 UAs for Alice and Bob subscribe to the dialog package for the
appearance AOR and publish dialog state to the Appearance Agent. appearance AOR and publish dialog state to the Appearance Agent.
Message exchanges between the Registrar, Appearance Agent, Alice, and Message exchanges between the Registrar, Appearance Agent, Alice, and
Bob are shown below. The call flow examples below do not show the Bob are shown below. The call flow examples below do not show the
authentication of subscriptions, publications, and notifications. It authentication of subscriptions, publications, and notifications. It
should be noted that for security purposes, all publications and should be noted that for security purposes, all publications and
subscriptions must be authorized before they are accepted. subscriptions must be authorized before they are accepted.
Also note that registrations and subscriptions must all be refreshed Also note that registrations and subscriptions must all be refreshed
by Alice at intervals determined by the expiration intervals returned by Alice at intervals determined by the expiration intervals returned
by the Registrar or Appearance Agent. by the Registrar or Appearance Agent.
skipping to change at page 29, line 29 skipping to change at page 29, line 27
| | | | | | | |
| |<---------------------- SUBSCRIBE F9<| | |<---------------------- SUBSCRIBE F9<|
| | | | | | | |
| |>F10 200 OK ------------------------>| | |>F10 200 OK ------------------------>|
| | | | | | | |
| |>F11 NOTIFY ------------------------>| | |>F11 NOTIFY ------------------------>|
| | | | | | | |
| |<------------------------ 200 OK F12<| | |<------------------------ 200 OK F12<|
| | | | | | | |
Figure 1. Figure 1. Registration and Subscription Example
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>
skipping to change at page 30, line 12 skipping to change at page 30, line 10
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb Call-ID: d3281184-518783de-cc23d6bb
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:HelpDesk@example.com>;tag=1664573879820199 To: <sip:HelpDesk@example.com>;tag=1664573879820199
Contact: <sip:alice@ua1.example.com>;expires=3600 Contact: <sip:alice@ua1.example.com>;expires=3600
Content-Length: 0 Content-Length: 0
F3 to F6: Alice also subscribes to the events associated with the F3 to F6: Alice also subscribes to the events associated with the
Appearance AOR. Appearance Agent notifies Alice of the status. Appearance AOR. Appearance Agent notifies Alice of the status.
F3 Alice ----> Appearance Agent F3 Alice ----> Appearance Agent
SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 SUBSCRIBE sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:HelpDesk@example.com> To: <sip:HelpDesk@example.com>
CSeq: 91 SUBSCRIBE CSeq: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
skipping to change at page 31, line 9 skipping to change at page 31, line 7
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=1636248422222257 From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
CSeq: 232 NOTIFY CSeq: 232 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active;expires=3000 Subscription-State: active;expires=3000
Contact: <appearanceagent.example.com> Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="40" version="40"
state="full" state="full"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
</dialog-info> </dialog-info>
F6 Alice ----> Appearance Agent F6 Alice ----> Appearance Agent
skipping to change at page 32, line 12 skipping to change at page 32, line 10
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
11.2. Appearance Selection for Incoming Call 11.2. Appearance Selection for Incoming Call
In the call flow below Bob and Alice are in an appearance group. In the call flow below, Bob and Alice are in a shared appearance
Carol places a call to the appearance group AOR. The Appearance group. Carol places a call to the shared appearance group AOR. The
Agent sends NOTIFYs to Alice and Bob telling them what appearance the Appearance Agent sends NOTIFYs to Alice and Bob telling them what
call is using. Both Alice and Bob's devices are alerted of the appearance the call is using. Both Alice and Bob's devices are
incoming call. Bob answers the call. alerted of the 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
a BYE to terminate one of the dialogs. As a result, either Alice or a BYE to terminate one of the dialogs. As a result, either Alice or
Bob will receive the BYE and publish that their dialog is over. Bob will receive the BYE and publish that their dialog is over.
However, if Carol answers both Alice and Bob and keeps both dialogs However, if Carol answers both Alice and Bob and keeps both dialogs
active, then the Appearance Agent will need to resolve the situation active, then the Appearance Agent will need to resolve the situation
by moving either Alice or Bob's dialog to a different appearance. by moving either Alice or Bob's dialog to a different appearance.
All NOTIFY messages in the call flow below carry dialog events and All NOTIFY messages in the call flow below carry dialog events and
only dialog states are mentioned for simplicity. For brevity, the only dialog states are mentioned for simplicity. For brevity, the
details of some messages are not shown below. Note that the order of details of some messages are not shown below. Note that the order of
skipping to change at page 33, line 35 skipping to change at page 33, line 33
| | | | | | | | | |
| | |>F21 NOTIFY >| | | | |>F21 NOTIFY >| |
| | | | | | | | | |
| | |<- 200 F22 -<| | | | |<- 200 F22 -<| |
| | | | | | | | | |
| | |>F23 NOTIFY ---------->| | | |>F23 NOTIFY ---------->|
| | | | | | | | | |
| | |<F24 200 OK ----------<| | | |<F24 200 OK ----------<|
| | | | | | | |
Figure 2. Figure 2. Appearance Selection for Incoming Call Example
F4 Appearance Agent ----> Alice F4 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937 From: <sip:HelpDesk@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sip:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4 Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 12 NOTIFY CSeq: 12 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active;expires=2800 Subscription-State: active;expires=2800
Contact: <appearanceagent.example.com> Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="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"
skipping to change at page 35, line 13 skipping to change at page 35, line 12
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937 From: <sip:HelpDesk@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE To: <sip:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4 Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 13 NOTIFY CSeq: 13 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active;expires=2500 Subscription-State: active;expires=2500
Contact: <appearanceagent.example.com> Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="17" version="17"
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"
skipping to change at page 36, line 43 skipping to change at page 36, line 42
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |<- NOTIFY F18<| | | | |<- NOTIFY F18<| |
| | | | | | | | | |
| | |>F19 200 OK ->| | | | |>F19 200 OK ->| |
| | | |------ NOTIFY F20>| | | | |------ NOTIFY F20>|
| | | | | | | | | |
| | | |<F21 200 OK -----<| | | | |<F21 200 OK -----<|
| | | | | | | | | |
Figure 3. Figure 3. Outgoing Call without Appearance Seizure Example
F1 Bob ----> Proxy F1 Bob ----> Proxy
INVITE sip:carol@example.com SIP/2.0 INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com> To: <sip:carol@example.com>
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
skipping to change at page 37, line 34 skipping to change at page 37, line 33
NOTIFY sip:alice@ua1.example.com SIP/2.0 NOTIFY sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62
From: <sip:HelpDesk@example.com>;tag=1636248422222257 From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94 Call-ID: ef4704d9-bb68aa0b-474c9d94
CSeq: 233 NOTIFY CSeq: 233 NOTIFY
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active;expires=2200 Subscription-State: active;expires=2200
Contact: <appearanceagent.example.com> Contact: <sip:appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
skipping to change at page 38, line 48 skipping to change at page 38, line 48
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
11.4. Outgoing Call with Appearance Seizure 11.4. Outgoing Call with Appearance Seizure
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) selecting/seizing an appearance number before sending state (trying) selecting/seizing an appearance number before sending
the INVITE. After receiving the 200 OK from the Appearance Agent the INVITE. After receiving the 200 (OK) from the Appearance Agent
confirming the appearance number, Bob's UA sends the INVITE to Carol confirming the appearance number, Bob's UA sends the INVITE to Carol
and establishes a session. For brevity, details of some of the and establishes a session. For brevity, details of some of the
messages are not included in the message flows. Bob's UA puts as messages are not included in the message flows. Bob's UA puts as
much of the dialog information from F7 as can be determined in much of the dialog information from F7 as can be determined in
advance. In this case, the minimum of the Contact URI is included advance. In this case, the minimum of the Contact URI is included,
which allows the Appearance Agent to correlate the INVITE with the which allows the Appearance Agent to correlate the INVITE with the
PUBLISH. PUBLISH.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| | | | |<----- PUBLISH F1<|
| | | | | | | | | |
| | | |>F2 200 OK ------>| | | | |>F2 200 OK ------>|
| | | | | | | | | |
| | |<-- NOTIFY F3<| | | | |<-- NOTIFY F3<| |
skipping to change at page 40, line 12 skipping to change at page 40, line 11
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |<- NOTIFY F22<| | | | |<- NOTIFY F22<| |
| | | | | | | | | |
| | |>F23 200 OK ->| | | | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>| | | | |------ NOTIFY F24>|
| | | | | | | | | |
| | | |<F25 200 OK -----<| | | | |<F25 200 OK -----<|
| | | | | | | | | |
Figure 4. Figure 4. Outgoing Call with Appearance Seizure Example
F1 to F4: Bob uses the shared appearance of the Help Desk on his UA F1 to F4: Bob uses the shared appearance of the Help Desk on his UA
to place an outgoing call (e.g., he goes off-hook). Before sending to place an outgoing call (e.g., he goes off-hook). Before sending
the outgoing INVITE request, Bob publishes to the Appearance Agent the outgoing INVITE request, Bob publishes to the Appearance Agent
reserving appearance number 1. The Appearance Agent notifies Alice reserving appearance number 1. The Appearance Agent notifies Alice
(and all other UAs, including Bob) of the event by sending NOTIFYs. (and all other UAs, including Bob) of the event by sending NOTIFYs.
F1 Bob ----> Appearance Agent F1 Bob ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 PUBLISH sip:HelpDesk@example.com SIP/2.0
skipping to change at page 42, line 26 skipping to change at page 42, line 26
<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>
11.5. Outgoing Call without using an Appearance Number 11.5. Outgoing Call without Using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' Event header field appearance element but does have the 'shared' Event header field
parameter. As a result, the Appearance Agent knows the UA does not parameter. As a result, the Appearance Agent knows the UA does not
wish to use an appearance number for this call. If the Appearance wish to use an appearance number for this call. If the Appearance
Agent does not wish to allow this, it would reject the PUBLISH with a Agent does not wish to allow this, it would reject the PUBLISH with a
400 (Bad Request) response and the UA would know to re-PUBLISH 400 (Bad Request) response and the UA would know to re-PUBLISH
selecting/seizing an appearance number. selecting/seizing an appearance number.
skipping to change at page 43, line 40 skipping to change at page 43, line 40
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |<- NOTIFY F22<| | | | |<- NOTIFY F22<| |
| | | | | | | | | |
| | |>F23 200 OK ->| | | | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>| | | | |------ NOTIFY F24>|
| | | | | | | | | |
| | | |<F25 200 OK -----<| | | | |<F25 200 OK -----<|
| | | | | | | | | |
Figure 5. Figure 5. Outgoing Call without using an Appearance Number Example
F1 Bob ----> Appearance Agent F1 Bob ----> Appearance Agent
PUBLISH sip:appearanceagent.example.com SIP/2.0 PUBLISH sip:appearanceagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=4415df82k39sf From: <sip:bob@example.com>;tag=4415df82k39sf
To: <sip:HelpDesk@example.com> To: <sip:HelpDesk@example.com>
CSeq: 7 PUBLISH CSeq: 7 PUBLISH
Call-ID: 44fwF144-F12893K38424 Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
skipping to change at page 45, line 4 skipping to change at page 45, line 4
| |<------------------------------------ 200 OK F24<| | |<------------------------------------ 200 OK F24<|
|<--200 OK F25<| | | | |<--200 OK F25<| | | |
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |<- NOTIFY F26<| | | | |<- NOTIFY F26<| |
| | | | | | | | | |
| | |>F27 200 OK ->| | | | |>F27 200 OK ->| |
| | | |------ NOTIFY F28>| | | | |------ NOTIFY F28>|
| | | | | | | | | |
| | | |<F29 200 OK -----<| | | | |<F29 200 OK -----<|
Figure 6. Figure 6. Appearance Release Example
F28 Appearance Agent ----> Bob F28 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=497585728578386 From: <sip:HelpDesk@example.com>;tag=497585728578386
To: <sip:bob@example.com> To: <sip:bob@example.com>
Call-ID: a7d559db-d6d7dcad-311c9e3a Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK759878512309 ;branch=z9hG4bK759878512309
skipping to change at page 45, line 46 skipping to change at page 45, line 46
<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>
11.7. Appearance Pickup 11.7. Appearance Pickup
In this scenario, Bob has an established dialog with Carol created In this scenario, Bob has an established dialog with Carol created
using the call flows of Figure 1 or Figure 2. Bob then places Carol using the call flows of Figures 1 or 2. Bob then places Carol on
on hold. Alice receives a notification of this and renders this on hold. Alice receives a notification of this and renders this on
Alice's UI. Alice subsequently picks up the held call and has a Alice's UI. Alice subsequently picks up the held call and has a
established session with Carol. Finally, Carol hangs up. Alice must established session with Carol. Finally, Carol hangs up. Alice must
PUBLISH F32 to indicate that the INVITE F38 will be an attempt to PUBLISH F32 to indicate that the INVITE F38 will be an attempt to
pickup the dialog between Carol and Bob, and hence may use the same pickup the dialog between Carol and Bob and, hence, may use the same
appearance number. This example also shows Secure SIP (sips) being appearance number. This example also shows Secure SIP (sips) being
used. used.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| |<------------------------------(hold) INVITE F22<| | |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | | |<- INVITE F23<| | | |
| | | | | | | | | |
skipping to change at page 47, line 29 skipping to change at page 47, line 29
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |<- NOTIFY F52<| | | | |<- NOTIFY F52<| |
| | | | | | | | | |
| | |>F53 200 OK ->| | | | |>F53 200 OK ->| |
| | | | | | | | | |
| | | |>F54 NOTIFY ----->| | | | |>F54 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F55<| | | | |<----- 200 OK F55<|
Figure 7. Figure 7. Appearance Pickup Example
F28 Appearance ----> Alice F28 Appearance ----> Alice
NOTIFY sips:alice@ua1.example.com SIP/2.0 NOTIFY sips:alice@ua1.example.com SIP/2.0
From: <sips:HelpDesk@example.com>;tag=151702541050937 From: <sips:HelpDesk@example.com>;tag=151702541050937
To: <sips:alice@example.com>;tag=18433323-C3D237CE To: <sips:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4 Call-ID: 1e361d2f-a9f51109-bafe31d4
CSeq: 12 NOTIFY CSeq: 12 NOTIFY
Via: SIP/2.0/TLS appearanceagent.example.com Via: SIP/2.0/TLS appearanceagent.example.com
;branch=z9hG4bK1403 ;branch=z9hG4bK1403
skipping to change at page 50, line 5 skipping to change at page 50, line 5
o=- 1102980497 1102980497 IN IP4 ua1.example.com o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA s=IP SIP UA
c=IN IP4 ua1.example.com c=IN IP4 ua1.example.com
t=0 0 t=0 0
a=sendrecv a=sendrecv
m=audio 2238 RTP/AVP 0 8 101 m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
11.8. Calls between UAs within the Group 11.8. Call between UAs within the Group
In this scenario, Bob calls Alice who is also in the Appearance In this scenario, Bob calls Alice who is also in the shared
group. Only one appearance number is used for this dialog. This appearance group. Only one appearance number is used for this
example also shows the use of the 'exclusive' tag to indicate that dialog. This example also shows the use of the 'exclusive' tag to
other UAs in the group can not join or take this dialog. indicate that other UAs in the group can not join or take this
dialog.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| |<-------------------- INVITE (to Alice's UA) F1<| | |<-------------------- INVITE (to Alice's UA) F1<|
| | | | | | | | | |
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | | | | | | | | |
| | |<-- NOTIFY F2<| | | | |<-- NOTIFY F2<| |
| | | | | | | | | |
skipping to change at page 51, line 11 skipping to change at page 51, line 12
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |<- NOTIFY F17<| | | | |<- NOTIFY F17<| |
| | | | | | | | | |
| | |>F18 200 OK ->| | | | |>F18 200 OK ->| |
| | | |>F19 NOTIFY ----->| | | | |>F19 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F24<| | | | |<----- 200 OK F24<|
| | | | | | | | | |
Figure 8. Figure 8. Call between UAs within the Group Example
F19 Appearance Agent ----> Bob F19 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0 NOTIFY sip:bob@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=497585728578386 From: <sip:HelpDesk@example.com>;tag=497585728578386
To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a Call-ID: a7d559db-d6d7dcad-311c9e3a
CSeq: 7 NOTIFY CSeq: 7 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com Via: SIP/2.0/UDP appearanceagent.example.com
;branch=z9hG4bK1711759878512309 ;branch=z9hG4bK1711759878512309
skipping to change at page 51, line 50 skipping to change at page 52, line 4
<sa:exclusive>true</sa:exclusive> <sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<state>confirmed</state> <state>confirmed</state>
<local> <local>
<target uri="sip: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</sa:exclusive> <sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<state>confirmed</state> <state>confirmed</state>
skipping to change at page 52, line 32 skipping to change at page 52, line 33
</dialog> </dialog>
</dialog-info> </dialog-info>
11.9. Consultation Hold with Appearances 11.9. Consultation Hold with Appearances
In this scenario, Bob has a call with Carol. Bob makes a In this scenario, Bob has a call with Carol. Bob makes a
consultation call to Alice by putting Carol on hold and calling consultation call to Alice by putting Carol on hold and calling
Alice. Bob's UA chooses not to have an appearance number for the Alice. Bob's UA chooses not to have an appearance number for the
call to Alice since it is treating it as part of the call to Carol. call to Alice since it is treating it as part of the call to Carol.
He indicates this in the PUBLISH F32 which contains the 'shared' He indicates this in the PUBLISH F32, which contains the 'shared'
Event header field parameter but no <appearance> element. The Event header field parameter but no <appearance> element. The
PUBLISH is sent before the INVITE to Alice to ensure no appearance PUBLISH is sent before the INVITE to Alice to ensure no appearance
number is assigned by the Appearance Agent. Finally, Bob hangs up number is assigned by the Appearance Agent. Finally, Bob hangs up
with Alice and resumes the call with Carol. Dialog notifications of with Alice and resumes the call with Carol. Dialog notifications of
the consultation call are not shown, as they are not used. the consultation call are not shown, as they are not used.
Note that if Carol hangs up while Bob is consulting with Alice, Bob Note that if Carol hangs up while Bob is consulting with Alice, Bob
can decide if he wants to reuse the appearance number used with Carol can decide if he wants to reuse the appearance number used with Carol
for the call with Alice. If not, Bob publishes the termination of for the call with Alice. If not, Bob publishes the termination of
the dialog with Carol and the Appearance Agent will re-allocate the the dialog with Carol and the Appearance Agent will re-allocate the
appearance. If he wants to keep the appearance, Bob will publish the appearance. If he wants to keep the appearance, Bob will publish the
termination of the dialog with Carol and also publish the appearance termination of the dialog with Carol and also publish the appearance
with the dialog with Alice. This will result in Bob keeping the with the dialog with Alice. This will result in Bob keeping the
appearance number until he reports the dialog with Alice terminated. appearance number until he reports the dialog with Alice terminated.
Note that the call flow would be similar if Bob called a music on Note that the call flow would be similar if Bob called a music on
hold server instead of Alice to implement a music on hold service as hold server instead of Alice to implement a music on hold service as
described in [I-D.worley-service-example]. described in [RFC7088].
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| |<------------------------------(hold) INVITE F22<| | |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | | |<- INVITE F23<| | | |
| | | | | | | | | |
|>F24 200 OK ->| | | | |>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>| | |>F25 200 OK ------------------------------------>|
skipping to change at page 54, line 26 skipping to change at page 54, line 27
| | |<- NOTIFY F50<| | | | |<- NOTIFY F50<| |
| | | | | | | | | |
| | |>F51 200 OK ->| | | | |>F51 200 OK ->| |
| | | |>F52 NOTIFY ----->| | | | |>F52 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F53<| | | | |<----- 200 OK F53<|
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
Figure 9. Figure 9. Consultation Hold with Appearances Example
F32 Bob ----> Appearance Agent F32 Bob ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 PUBLISH sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:HelpDesk@example.com>;tag=428765950880801 To: <sip:HelpDesk@example.com>;tag=428765950880801
CSeq: 11 PUBLISH CSeq: 11 PUBLISH
Call-ID: 44fwF144-F12893K38424 Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
skipping to change at page 56, line 28 skipping to change at page 56, line 29
| | | | | | | | | |
| | |>F40 NOTIFY >| | | | |>F40 NOTIFY >| |
| | | | | | | | | |
| | |< 200 OK F41<| | | | |< 200 OK F41<| |
| | | | | | | | | |
| | |>F42 NOTIFY ---------->| | | |>F42 NOTIFY ---------->|
| | | | | | | | | |
| | |<F43 200 OK ----------<| | | |<F43 200 OK ----------<|
| | | | | | | | | |
Figure 10. Figure 10. Joining or Bridging an Appearance Example
F22 Alice ----> Appearance Agent F22 Alice ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 PUBLISH sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:alice@example.com>;tag=44150CC6-A7B7919D From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
To: <sip:HelpDesk@example.com>;tag=428765950880801 To: <sip:HelpDesk@example.com>;tag=428765950880801
CSeq: 11 PUBLISH CSeq: 11 PUBLISH
Call-ID: 87837Fkw87asfds Call-ID: 87837Fkw87asfds
Contact: <sip:alice@ua2.example.com> Contact: <sip:alice@ua2.example.com>
skipping to change at page 58, line 5 skipping to change at page 58, line 5
o=- 1103061265 1103061265 IN IP4 ua1.example.com o=- 1103061265 1103061265 IN IP4 ua1.example.com
s=IP SIP UA s=IP SIP UA
c=IN IP4 ua1.example.com c=IN IP4 ua1.example.com
t=0 0 t=0 0
a=sendrecv a=sendrecv
m=audio 2236 RTP/AVP 0 8 101 m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
11.11. Appearance Allocation - Loss of Appearance 11.11. Loss of Appearance during Allocation
Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol,
then becomes unreachable. When he fails to refresh his publication then becomes unreachable. When he fails to refresh his publication
to the appearance agent, the Appearance Agent declares the dialog to the appearance agent, the Appearance Agent declares the dialog
terminated and frees up the appearance using NOTIFYs F14 and F16. terminated and frees up the appearance using NOTIFYs F14 and F16.
After retransmitting the NOTIFY to Bob (in not shown messages F17, After retransmitting the NOTIFY to Bob (in not shown messages F17,
F18, etc.), the subscription is terminated. F18, etc.), the subscription is terminated.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
skipping to change at page 58, line 49 skipping to change at page 58, line 49
| | | | | | | | | |
| | | Appearance selection times out | | | | Appearance selection times out |
| | | | | | | | | |
| | |<- NOTIFY F14<| | | | |<- NOTIFY F14<| |
| | | | | | | | | |
| | |>F15 200 OK ->| | | | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>| | | | |------ NOTIFY F16>|
| | | | | | | | | |
| | | NOTIFY is retransmitted | | | | NOTIFY is retransmitted |
Figure 11. Figure 11. Loss of Appearance during Allocation Example
11.12. Appearance Seizure Contention Race Condition 11.12. Appearance Seizure Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the Bob and Alice both try to reserve appearance 2 by publishing at the
same time. The Appearance Agent allocates the appearance to Bob by same time. The Appearance Agent allocates the appearance to Bob by
sending a 200 OK and denies it to Alice by sending a 400 (Bad sending a 200 OK and denies it to Alice by sending a 400 (Bad
Request) response. After the NOTIFY F5, Alice learns that Bob is Request) response. After the NOTIFY F5, Alice learns that Bob is
using appearance 2. Alice then attempts to reserve appearance 3 by using appearance 2. Alice then attempts to reserve appearance 3 by
publishing, which is then accepted. publishing, which is then accepted.
skipping to change at page 60, line 36 skipping to change at page 60, line 36
| | | |<---- PUBLISH F12<| | | | |<---- PUBLISH F12<|
| | | | (appearance=2) | | | | (appearance=2)
| | | |>F13 200 OK ----->| | | | |>F13 200 OK ----->|
| | |>F14 PUBLISH->| | | | |>F14 PUBLISH->| |
| | | (appearance=3) | | | | (appearance=3) |
| | | | | | | | | |
| | |<--- F15 200 <| | | | |<--- F15 200 <| |
| | | | | | | | | |
| | |<- NOTIFY F16<| | | | |<- NOTIFY F16<| |
| | | | | | | | | |
| |>F17 200 OK ->| | | | |>F17 200 OK ->| |
Dave | | |------ NOTIFY F18>| Dave | | |------ NOTIFY F18>|
| | | | | | | | | |
| | | |<F19 200 OK -----<| | | | |<F19 200 OK -----<|
| |<-- INVITE F20<| | | | |<-- INVITE F20<| | |
| | | | | | | | | |
| |>F21 100 ----->| | | | |>F21 100 ----->| | |
|<- INVITE F22<| | | | |<- INVITE F22<| | | |
Figure 12. Figure 12. Appearance Seizure Contention Race Condition Example
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, Bob's UA sends a NOTIFY to the Appearance Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance
Agent which then notifies the other other UAs in the group. Agent which then notifies the 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 62, line 33 skipping to change at page 62, line 33
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
| | |<- NOTIFY F36<| | | | |<- NOTIFY F36<| |
| | | | | | | | | |
| | |>F37 200 OK ->| | | | |>F37 200 OK ->| |
| | | |------ NOTIFY F38>| | | | |------ NOTIFY F38>|
| | | | | | | | | |
| | | |<F39 200 OK -----<| | | | |<F39 200 OK -----<|
| | | | | | | | | |
Figure 13. Figure 13. Appearance Agent Subscription to UAs Example
11.14. Appearance Pickup Race Condition Failure 11.14. Appearance Pickup Race Condition Failure
In this scenario, Bob has an established dialog with Carol created In this scenario, Bob has an established dialog with Carol created
using the call flows of Figure 1 or Figure 2. Bob then places Carol using the call flows of Figure 1 or Figure 2. Bob then places Carol
on hold. Alice receives a notification of this and renders this on on hold. Alice receives a notification of this and renders this on
Alice's UI. Alice attempts to pick up the call but Carol hangs up Alice's UI. Alice attempts to pick up the call but Carol hangs up
before the pickup can complete. Alice cancels the pickup attempt before the pickup can complete. Alice cancels the pickup attempt
with the PUBLISH F48. Note that the call flow for a failed Join with the PUBLISH F48. Note that the call flow for a failed Join
would be almost identical. would be almost identical.
skipping to change at page 64, line 8 skipping to change at page 64, line 8
| | | | | | | | | |
| | |<- 200 OK F49<| | | | |<- 200 OK F49<| |
| | | | | | | | | |
| | |<- NOTIFY F50<| | | | |<- NOTIFY F50<| |
| | | | | | | | | |
| | |>F51 200 OK ->| | | | |>F51 200 OK ->| |
| | | |>F52 NOTIFY ----->| | | | |>F52 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F53<| | | | |<----- 200 OK F53<|
Figure 14. Figure 14. Appearance Pickup Race Condition Failure Example
F48 Alice ----> Appearance Agent F48 Alice ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 PUBLISH sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:alice@example.com>;tag=44150CC6-A7B7919D From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
To: <sip:HelpDesk@example.com>;tag=428765950880801 To: <sip:HelpDesk@example.com>;tag=428765950880801
CSeq: 11 PUBLISH CSeq: 11 PUBLISH
Call-ID: 87837Fkw87asfds Call-ID: 87837Fkw87asfds
Contact: <sip:alice@ua2.example.com> Contact: <sip:alice@ua2.example.com>
skipping to change at page 65, line 52 skipping to change at page 66, line 42
| | | | | | | | | |
| |>F13 200 OK ->| | | |>F13 200 OK ->| |
Dave | | |------ NOTIFY F14>| Dave | | |------ NOTIFY F14>|
| | | | | | | | | |
| | | |<F15 200 OK -----<| | | | |<F15 200 OK -----<|
| |<-- INVITE F16<| | | | |<-- INVITE F16<| | |
| | | | | | | | | |
| |>F17 100 ----->| | | | |>F17 100 ----->| | |
|<- INVITE F18<| | | | |<- INVITE F18<| | | |
Figure 15. Figure 15. Appearance Seizure Incoming/Outgoing Contention
Race Condition Example
12. Security Considerations 12. Security Considerations
Since multiple line appearance features are implemented using Since multiple line appearance features are implemented using
semantics provided by SIP [RFC3261], the SIP Event Package for Dialog semantics provided by SIP [RFC3261], the SIP Event Package for Dialog
State [RFC4235], and the SIP Event Framework State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903],
[I-D.ietf-sipcore-rfc3265bis] and [RFC3903], security considerations security considerations in these documents apply to this document as
in these documents apply to this document as well. well.
To provide confidentiality, NOTIFY or PUBLISH message bodies that To provide confidentiality, NOTIFY or PUBLISH message bodies that
provide the dialog state information and the dialog identifiers MAY provide the dialog state information and the dialog identifiers MAY
be encrypted end-to-end using the standard mechanisms such as S/MIME be encrypted end-to-end using the standard mechanisms such as S/MIME
described in [RFC3261]. Alternatively, sending the NOTIFY and described in [RFC3261]. Alternatively, sending the NOTIFY and
PUBLISH requests over TLS also provides confidentiality, although on PUBLISH requests over TLS also provides confidentiality, although on
a hop-by-hop basis. All SUBSCRIBES and PUBLISHES between the UAs and a hop-by-hop basis. All SUBSCRIBEs and PUBLISHes between the UAs and
the Appearance Agent MUST be authenticated. Without proper the Appearance Agent MUST be authenticated. Without proper
authentication and confidentiality, a third party could learn authentication and confidentiality, a third party could learn
information about dialogs associated with a AOR and could try to use information about dialogs associated with a AOR and could try to use
this information to hijack or manipulate those dialogs using SIP call this information to hijack or manipulate those dialogs using SIP call
control primitives. control primitives.
This feature relies on standard SIP call control primitives such as This feature relies on standard SIP call control primitives such as
Replaces and Join. Proper access controls on their use MUST be used Replaces and Join. Proper access controls on their use MUST be used
so that only members of the appearance group can use these so that only members of the shared appearance group can use these
mechanisms. All INVITEs with Replaces or Join header fields MUST mechanisms. All INVITEs with Replaces or Join header fields MUST
only be accepted if the peer requesting dialog replacement or joining only be accepted if the peer requesting dialog replacement or joining
has been properly authenticated using a standard SIP mechanism (such has been properly authenticated using a standard SIP mechanism (such
as Digest or S/MIME), and authorized to request a replacement. as Digest or S/MIME), and authorized to request a replacement.
Otherwise, a third party could disrupt or hijack existing dialogs in Otherwise, a third party could disrupt or hijack existing dialogs in
the appearance group. the shared appearance group.
For an emergency call, a UA MUST NOT wait for a confirmed seizure of For an emergency call, a UA MUST NOT wait for a confirmed seizure of
an appearance before sending an INVITE. Waiting for confirmation an appearance before sending an INVITE. Waiting for confirmation
could inadvertently delay or block the emergency call, which by its could inadvertently delay or block the emergency call, which by its
nature needs to be placed as expeditiously as possible. Instead, a nature needs to be placed as expeditiously as possible. Instead, a
emergency call MUST proceed regardless of the status of the PUBLISH emergency call MUST proceed regardless of the status of the PUBLISH
transaction. transaction.
13. IANA Considerations 13. IANA Considerations
This section registers the SIP Event header field parameter 'shared', This section registers the SIP Event header field parameter 'shared',
the SIP Alert-Info header field parameter 'appearance' and the XML the 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 Header Field Parameter: shared 13.1. SIP Event Header Field Parameter: shared
This document defines the 'shared' header field parameter to the This document defines the 'shared' header field parameter in the
Event header field in the "SIP Header Field Parameters and Parameter Event header field in the "Header Field Parameters and Parameter
Values" registry defined by [RFC3968]. Values" registry defined by [RFC3968].
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------------- ------------------ ---------- --------- ---------------------------- ------------------ ---------- ---------
Event shared No [RFC-to-be] Event shared No RFC 7463
13.2. SIP Alert-Info Header Field Parameter: appearance 13.2. SIP Alert-Info Header Field Parameter: appearance
This document defines the 'appearance' parameter to the Alert-Info This document defines the 'appearance' parameter in the Alert-Info
header in the "SIP Header Field Parameters and Parameter Values" header in the "Header Field Parameters and Parameter Values" registry
registry defined by [RFC3968]. defined by [RFC3968].
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------- --------------- --------- --------- ---------------------- --------------- --------- ---------
Alert-Info appearance No [RFC-to-be] Alert-Info appearance No RFC 7463
13.3. URN Sub-Namespace Registration: sa-dialog-info 13.3. URN Sub-Namespace Registration: sa-dialog-info
This section registers a new XML namespace per the procedures This section registers a new XML namespace per the procedures in
in [RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:sa-dialog-info. URI: urn:ietf:params:xml:ns:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com> Alan Johnston <alan.b.johnston@gmail.com>
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 68, line 30 skipping to change at page 68, line 41
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Shared Appearance Dialog Information Namespace</title> <title>Shared Appearance Dialog Information Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Shared Appearance Dialog Information</h1> <h1>Namespace for Shared Appearance Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:sa-dialog-info</h2> <h2>urn:ietf:params:xml:ns:sa-dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfcXXXX.txt"> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7463.txt">
RFCXXXX</a>.</p> RFC 7463</a>.</p>
</body> </body>
</html> </html>
END END
13.4. XML Schema Registration 13.4. XML Schema Registration
This section registers an XML schema per the procedures in This section registers an XML schema per the procedures in [RFC3688].
[RFC3688].
URI: urn:ietf:params:xml:schesa:sa-dialog-info. URI: urn:ietf:params:xml:schesa:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com> Alan Johnston <alan.b.johnston@gmail.com>
The XML for this schema can be found in Section 6. The XML for this schema can be found in Section 6.
14. Acknowledgements 14. References
The following individuals were part of the shared appearance Design
team and have provided input and text to the document (in
alphabetical order):
Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
MacDonald, Bill Mitchell, Michael Procter, Theo Zourzouvillys.
Thanks to Chris Boulton for helping with the XML schema.
Much of the material has been drawn from previous work by Mohsen
Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar,
who in turn received assistance from:
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
Towlson, and Michael Procter of Citel Technologies, Rob Harder and
Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
Inc.
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
comments.
Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji
Chinnappa, and Harsh Mendiratta for their detailed review of the
document.
15. References
15.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://www.rfc-editor.org/info/rfc3261>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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,
<http://www.rfc-editor.org/info/rfc3515>.
[I-D.ietf-sipcore-rfc3265bis] [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
Roach, A., "SIP-Specific Event Notification", January 2004, <http://www.rfc-editor.org/info/rfc3688>.
draft-ietf-sipcore-rfc3265bis-09 (work in progress),
April 2012.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
for Event State Publication", RFC 3903, October 2004. "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[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
September 2004. 2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004,
<http://www.rfc-editor.org/info/rfc3903>.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004,
<http://www.rfc-editor.org/info/rfc3911>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, December
2004, <http://www.rfc-editor.org/info/rfc3968>.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005. Protocol (SIP)", RFC 4235, November 2005,
<http://www.rfc-editor.org/info/rfc4235>.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
(SIP) "Join" Header", RFC 3911, October 2004. Specifications: ABNF", STD 68, RFC 5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
"Indicating User Agent Capabilities in the Session July 2012, <http://www.rfc-editor.org/info/rfc6665>.
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and
January 2004. P. Kyzivat, "URNs for the Alert-Info Header Field of the
Session Initiation Protocol (SIP)", RFC 7462, March 2015,
<http://www.rfc-editor.org/info/rfc7462>.
[I-D.ietf-salud-alert-info-urns] 14.2. Informative References
Liess, L., Jesske, R., Johnston, A., Worley, D., and P.
Kyzivat, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-ietf-salud-alert-info-urns-07 (work
in progress), October 2012.
15.2. Informative References [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004,
<http://www.rfc-editor.org/info/rfc3680>.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", BCP
119, RFC 4579, August 2006,
<http://www.rfc-editor.org/info/rfc4579>.
[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,
<http://www.rfc-editor.org/info/rfc5359>.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC7088] Worley, D., "Session Initiation Protocol Service Example
(SIP) Call Control - Conferencing for User Agents", -- Music on Hold", RFC 7088, February 2014,
BCP 119, RFC 4579, August 2006. <http://www.rfc-editor.org/info/rfc7088>.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Acknowledgements
Package for Registrations", RFC 3680, March 2004.
[I-D.worley-service-example] The following individuals were part of the shared appearance design
Worley, D., "Session Initiation Protocol Service Example team and have provided input and text to the document (in
-- Music on Hold", draft-worley-service-example-10 (work alphabetical order):
in progress), August 2012.
Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
MacDonald, Bill Mitchell, Michael Procter, and Theo Zourzouvillys.
Thanks to Chris Boulton for helping with the XML schema.
Much of the material has been drawn from previous work by Mohsen
Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, and Anil Kumar,
who in turn received assistance from:
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems;
Steve Towlson and Michael Procter of Citel Technologies; Rob
Harder and Hong Chen of Polycom, Inc.; John Elwell and JD Smith of
Siemens Communications; Dale R. Worley of Pingtel; and Graeme
Dollar of Yahoo, Inc.
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
comments.
Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji
Chinnappa, and Harsh Mendiratta for their detailed review of the
document.
Authors' Addresses Authors' Addresses
Alan Johnston (editor) Alan Johnston (editor)
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO
United States
Email: alan.b.johnston@gmail.com
Mohsen Soroushnejad EMail: alan.b.johnston@gmail.com
Sylantro Systems Corp
Email: msoroush@gmail.com Mohsen Soroushnejad (editor)
Sylantro Systems Corp.
EMail: msoroush@gmail.com
Venkatesh Venkataramanan Venkatesh Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp.
Email: vvenkatar@gmail.com EMail: vvenkatar@gmail.com
 End of changes. 225 change blocks. 
596 lines changed or deleted 629 lines changed or added

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