draft-ietf-bliss-shared-appearances-05.txt   draft-ietf-bliss-shared-appearances-06.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Expires: September 8, 2010 M. Soroushnejad Intended status: Standards Track M. Soroushnejad
V. Venkataramanan Expires: January 13, 2011 V. Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
March 7, 2010 July 12, 2010
Shared Appearances of a Session Initiation Protocol (SIP) Address of Shared Appearances of a Session Initiation Protocol (SIP) Address of
Record (AOR) Record (AOR)
draft-ietf-bliss-shared-appearances-05 draft-ietf-bliss-shared-appearances-06
Abstract Abstract
This document describes the requirements and implementation of a This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as shared appearances of an Address Protocol (SIP), it is referred to as shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. This of Record (AOR) since SIP does not have the concept of lines. This
feature is commonly offered in IP Centrex services and IP-PBX feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment. This feature SIP feature servers used in a business environment. This feature
allows several user agents (UAs) to share a common AOR, learn about allows several user agents (UAs) to share a common AOR, learn about
calls placed and received by other UAs in the group, and pick up or calls placed and received by other UAs in the group, and pick up or
join calls within the group. This document discusses use cases, join calls within the group. This document discusses use cases,
lists requirements and defines extensions to implement this feature. lists requirements and defines extensions to implement this feature.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 6
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements and Implementation . . . . . . . . . . . . . . . 7 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9
5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12 5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12
5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 12 5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 12
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 12 5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 12 5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 13
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 16
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 17 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 18
7. User Interface Considerations . . . . . . . . . . . . . . . . 19 7. User Interface Considerations . . . . . . . . . . . . . . . . 20
7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 19 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 20
7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 19 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 20
7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 19 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 20
7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 19 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 20
7.1.4. Shared Appearance UAs with Variable Appearance 7.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 20 Number . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 20 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 21
8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 21 8. Interop with non-Shared Appearance UAs . . . . . . . . . . . . 22
8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 21 8.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 22
8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 21 8.2. Appearance Release . . . . . . . . . . . . . . . . . . . 22
8.3. UAs Supporting Dialog Events but Not Shared Appearance . 22 8.3. UAs Supporting Dialog Events but Not Shared Appearance . 23
9. Provisioning Considerations . . . . . . . . . . . . . . . . . 22 9. Provisioning Considerations . . . . . . . . . . . . . . . . . 23
10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 22 10. Example Message Flows . . . . . . . . . . . . . . . . . . . . 23
10.1. Registration and Subscription . . . . . . . . . . . . . . 23 10.1. Registration and Subscription . . . . . . . . . . . . . . 24
10.2. Appearance Selection for Incoming Call . . . . . . . . . 26 10.2. Appearance Selection for Incoming Call . . . . . . . . . 27
10.3. Outgoing Call without Appearance Seizure . . . . . . . . 30 10.3. Outgoing Call without Appearance Seizure . . . . . . . . 31
10.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 33 10.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 34
10.5. Outgoing Call without using an Appearance Number . . . . 37 10.5. Outgoing Call without using an Appearance Number . . . . 38
10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 39 10.6. Appearance Release . . . . . . . . . . . . . . . . . . . 40
10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 40 10.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 41
10.8. Calls between UAs within the Group . . . . . . . . . . . 44 10.8. Calls between UAs within the Group . . . . . . . . . . . 45
10.9. Consultation Hold with Appearances . . . . . . . . . . . 47 10.9. Consultation Hold with Appearances . . . . . . . . . . . 48
10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 49 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 50
10.11. Appearance Allocation - Loss of Appearance . . . . . . . 52 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 53
10.12. Appearance Seizure Contention Race Condition . . . . . . 53 10.12. Appearance Seizure Contention Race Condition . . . . . . 54
10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 54 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 55
10.14. Appearance Pickup Race Condition Failure . . . . . . . . 56 10.14. Appearance Pickup Race Condition Failure . . . . . . . . 57
10.15. Appearance Seizure Incoming/Outgoing Contention Race 10.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . . 59 Condition . . . . . . . . . . . . . . . . . . . . . . . . 60
11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 60 11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 61
12. Security Considerations . . . . . . . . . . . . . . . . . . . 60 12. Security Considerations . . . . . . . . . . . . . . . . . . . 62
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 61 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 62
13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 62 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 63
13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 62 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 63
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64
15. Informative References . . . . . . . . . . . . . . . . . . . . 63 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 15.1. Normative References . . . . . . . . . . . . . . . . . . 64
15.2. Informative References . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
The feature and functionality requirements for SIP user agents (UAs) The feature and functionality requirements for SIP user agents (UAs)
supporting business telephony applications differ greatly from basic supporting business telephony applications differ greatly from basic
SIP user agents, both in terms of services and end user experience. SIP user agents, both in terms of services and end user experience.
In addition to basic SIP support [RFC3261], many of the services in a In addition to basic SIP support [RFC3261], many of the services in a
business environment require the support for SIP extensions such as business environment require the support for SIP extensions such as
REFER [RFC3515], SUBSCRIBE/NOTIFY primitives REFER [RFC3515], SUBSCRIBE/NOTIFY primitives
[I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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
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
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
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 of an AOR feature.
4.1. Requirements 4.1. Requirements
The basic requirements of the shared appearance feature can be The basic requirements of the shared appearance feature can be
summarized as follows: summarized as follows:
skipping to change at page 8, line 12 skipping to change at page 8, line 20
REQ-5 The mechanism must scale for large numbers of appearances, n, REQ-5 The mechanism must scale for large numbers of appearances, n,
and large numbers of UAs, N, without introducing excessive messaging and large numbers of UAs, N, without introducing excessive messaging
traffic. traffic.
REQ-6 Each call or session (incoming or outgoing) must be assigned a REQ-6 Each call or session (incoming or outgoing) must be assigned a
common "appearance" number from a managed pool administered for the common "appearance" number from a managed pool administered for the
AOR group. Once the session has terminated, the appearance number is AOR group. Once the session has terminated, the appearance number is
released back into the pool and can be reused by another incoming or released back into the pool and can be reused by another incoming or
outgoing session. outgoing session.
REQ-7 Each UA in the group must be able to learn the appearance REQ-7 Each UA in the group must be able to learn the status of all
status 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 among
the UAs in the group. the UAs in the group.
REQ-9 The mechanism must allow all UAs receiving an incoming session REQ-9 The mechanism must allow all UAs receiving an incoming session
request to utilize the same appearance number at the time of request to utilize the same appearance number at the time of
alerting. alerting.
REQ-10 The mechanism must have a way of reconstructing appearance REQ-10 The mechanism must have a way of reconstructing appearance
state after an outage that does not result in excessive traffic and state after an outage that does not result in excessive traffic and
skipping to change at page 9, line 5 skipping to change at page 9, line 12
be accepted or rejected by the entity providing the shared appearance be accepted or rejected by the entity providing the shared appearance
service. Therefore, the mechanism must provide a way of service. Therefore, the mechanism must provide a way of
communicating the result back to the requester UA. communicating the result back to the requester UA.
REQ-15 The mechanism should support a way for a UA to seize a REQ-15 The mechanism should support a way for a UA to seize a
particular appearance number for outgoing requests prior to sending particular appearance number for outgoing requests prior to sending
the actual request. This is often called seizure. the actual request. This is often called seizure.
REQ-16 The mechanism should support a way for a UA to seize a REQ-16 The mechanism should support a way for a UA to seize a
particular appearance number and also send the request at the same particular appearance number and also send the request at the same
time. This is needed when a ringdown feature is combined with shared time. This is needed when an automatic ringdown feature (a telephone
appearances - in this case, seizing the line is the same thing as configured to immediately dial a phone number when it goes off hook)
dialing. is combined with shared appearances - in this case, seizing the line
is the same thing as dialing.
4.2. Implementation 4.2. Implementation
Many of the requirements for this service can be met using standard Many of the requirements for this service can be met using standard
SIP mechanisms such as: SIP mechanisms such as:
- A SIP Forking Proxy and Registrar/Location Service meets REQ-1. - A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
- The SIP Dialog Package meets REQ-2. - The SIP Dialog Package meets REQ-2.
skipping to change at page 10, line 5 skipping to change at page 10, line 12
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 for the Alert-Info This specification defines an extension parameter for the Alert-Info
header field in RFC 3261 to carry the appearance number: header field in RFC 3261 to carry the appearance number:
Alert-Info: <urn:alert:tone:normal>;appearance=0 Alert-Info: <urn:alert:service:normal>;appearance=1
The next section discusses the operations used to implement parts of The next section discusses the operations used to implement parts of
the shared appearance feature. An analysis of other mechanisms has the shared appearance feature. An analysis of other mechanisms has
been performed, with the mechanism described here best meeting the been performed, with the mechanism described here best meeting the
requirements of Section 4.1. requirements of Section 4.1.
1. A UA is configured with the AOR of a shared appearance group. It 1. A UA is configured with the AOR of a shared appearance group. It
registers against the AOR, then attempts a dialog state registers against the AOR, then attempts a dialog state
subscription to the AOR. If the subscription fails, loops back subscription to the AOR. If the subscription fails, loops back
to itself, or returns an error, it knows there is no State Agent, to itself, or returns an error, it knows there is no State Agent,
skipping to change at page 10, line 38 skipping to change at page 10, line 45
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 this information and waits for a 200 OK before the UA publishes this information and waits for a 200 OK 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 wish to seize an 7. For outgoing calls, if the user does not wish to seize an
appearance (such as during a consultation call), the UA also appearance (such as during a consultation call or if a UA is
publishes this prior to sending the INVITE. fetching 'service media' such as music on hold
[I-D.worley-service-example]), the UA also publishes this prior
to sending the INVITE.
8. Established calls within the group may be joined (bridged) or 8. Established calls within the group may be joined (bridged) or
taken (picked) by another UA. Information in the dialog package taken (picked) by another UA. Information in the dialog package
notifications can be used to construct Join or Replaces header notifications can be used to construct Join or Replaces header
fields. Since the same appearance number is used for these types fields. Since the same appearance number is used for these types
of operations, this information is published prior to sending the of operations, this information is published prior to sending the
INVITE Join or INVITE Replaces. INVITE Join or INVITE Replaces.
9. In some cases, the Appearance Agent may not have full access to 9. In some cases, the Appearance Agent may not have full access to
the complete dialog state of some or all of the UAs in the group. the complete dialog state of some or all of the UAs in the group.
If this is the case, the Appearance Agent will subscribe to the If this is the case, the Appearance Agent will subscribe to the
dialog state of individual UAs in the group to obtain this dialog state of individual UAs in the group to obtain this
skipping to change at page 12, line 8 skipping to change at page 12, line 18
This specification defines four new elements as extensions to the SIP This specification defines four new elements as extensions to the SIP
Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is
defined in Section 6. The elements are <appearance>, <exclusive>, defined in Section 6. The elements are <appearance>, <exclusive>,
<joined-dialog>, and <replaced-dialog> which are sub-elements of the <joined-dialog>, and <replaced-dialog> which are sub-elements of the
<dialog> element. <dialog> element.
5.2.1. The <appearance> element 5.2.1. The <appearance> element
The <appearance> element is used to convey the appearance number. The <appearance> element is used to convey the appearance number.
The appearance number is a non-negative integer. When sent in a The appearance number is a positive integer. When sent in a
publication in state Trying to the Appearance Agent, it is used to publication in state Trying to the Appearance Agent, it is used to
request an appearance number. When sent by the Appearance Agent, it request an appearance number. When sent by the Appearance Agent, it
indicates that the appearance number is associated with a dialog. indicates that the appearance number is associated with a dialog.
5.2.2. The <exclusive> element 5.2.2. The <exclusive> element
The <exclusive> element is a boolean used to indicate whether the UA The <exclusive> element is a boolean used to indicate whether the UA
will accept Join or Replaces INVITEs for this dialog. For example, will accept Join or Replaces INVITEs for this dialog. For example,
some shared appearance systems only allow call pickup when the call some shared appearance systems only allow call pickup when the call
is on hold. In this case, the <exclusive> element should be used to is on hold. In this case, the <exclusive> element should be used to
skipping to change at page 12, line 36 skipping to change at page 12, line 46
to the Appearance Agent for calls set to exclusive. If these dialog to the Appearance Agent for calls set to exclusive. If these dialog
identifiers have already been shared with the Appearance Agent, the identifiers have already been shared with the Appearance Agent, the
UA could send an INVITE Replaces to change them and then not report UA could send an INVITE Replaces to change them and then not report
the new ones to the Appearance Agent. the new ones to the Appearance Agent.
If the proxy knows which dialogs are marked exclusive, the proxy MAY If the proxy knows which dialogs are marked exclusive, the proxy MAY
enforce this exclusivity by rejecting INVITE Join and INVITE 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
selection or seizing - instead, it is about call control
operations that can be performed on a dialog.
5.2.3. The <joined-dialog> element 5.2.3. The <joined-dialog> element
The <joined-dialog> element is used to convey dialog identifiers of The <joined-dialog> element is used to convey dialog identifiers of
any other dialogs which are joined (mixed or bridged) with the any other dialogs which are joined (mixed or bridged) with the
dialog. Only the UA which is performing the actual media mixing dialog. Only the UA which is performing the actual media mixing
should include this element in publications to the Appearance Agent. should include this element in publications to the Appearance Agent.
Note that this element should still be used even when the Join header Note that this element should still be used even when the Join header
field was not used to join the dialogs. For example, two separate field was not used to join the dialogs. For example, two separate
dialogs on a UA could be joined without any SIP call control dialogs on a UA could be joined without any SIP call control
operations. Joined dialogs will share the same appearance number. operations. Joined dialogs will share the same appearance number.
skipping to change at page 14, line 9 skipping to change at page 14, line 25
other UAs in the group is an important part of the shared other UAs in the group is an important part of the shared
appearance feature. appearance feature.
A UA MUST send dialog package PUBLISH requests in the following A UA MUST send dialog package PUBLISH requests in the following
situations: situations:
1. When the user seizes a particular appearance number for an 1. When the user seizes a particular appearance number for an
outgoing call (i.e. seizing the appearance and going "off-hook", outgoing call (i.e. 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 or for a for an outgoing call (i.e. during a consultation call, a 'service
call not considered part of the shared appearance group). media' call such as for music on hold
[I-D.worley-service-example] or for a call not considered part of
the shared appearance group).
3. When the user has selected to join (or bridge) an existing call. 3. When the user has selected to join (or bridge) an existing call.
4. When the user has selected to replace (or take) an existing call. 4. When the user has selected to replace (or take) an existing call.
In all these cases, the INVITE SHOULD NOT be sent until the 200 OK In all these cases, the INVITE SHOULD NOT be sent until the 200 OK
response to the PUBLISH has been received, except for an emergency response to the PUBLISH has been received, except for an emergency
call, when a UA MUST never wait for a confirmed seizure before call, when a UA MUST never wait for a confirmed seizure before
sending an INVITE. Instead, the emergency call MUST proceed sending an INVITE. Instead, the emergency call MUST proceed
regardless of the status of PUBLISH transaction. regardless of the status of PUBLISH transaction.
Note that when a UA seizes an appearance prior to establishment of a Note that when a UA seizes an appearance prior to establishment of a
skipping to change at page 14, line 42 skipping to change at page 15, line 11
have any dialog identifiers (e.g. Call-ID, or local tag) the have any dialog identifiers (e.g. Call-ID, or local tag) the
Appearance Agent cannot assign the appearance number to a Appearance Agent cannot assign the appearance number to a
particular dialog of the UA until the second publication which particular dialog of the UA until the second publication which
will contain some dialog identifiers. will contain some dialog identifiers.
This publication state SHOULD be refreshed during the early dialog This publication state SHOULD be refreshed during the early dialog
state or the Appearance Agent may reassign the appearance number. state or the Appearance Agent may reassign the appearance number.
Once the dialog has transitioned to the confirmed state, no Once the dialog has transitioned to the confirmed state, no
publication refreshes are necessary. publication refreshes are necessary.
UAs SHOULD render information about other appearances to the user. Appearance numbers are a shorthand label for active and pending
This includes the state (idle, active, busy, joined, etc.). UAs can dialogs related to an AOR. Many of the features and services built
using this extension rely on the correct rendering of this
information to the human user. In addition, the group nature of the
feature means that the rendering must be similar between different
vendors and different models. Failure to do so will greatly reduce
the value and usefulness of these protocol extensions. The
appearances number for each active and pending dialog SHOULD be
explicitly or implicitly rendered to the user. The far end identity
of each dialog (e.g. the remote party identity) MUST NOT be rendered
in place of the appearance number. The state of each appearance
SHOULD also be rendered (idle, active, busy, joined, etc.). UAs can
tell that a set of dialogs are joined (bridged or mixed) together by tell that a set of dialogs are joined (bridged or mixed) together by
the presence of one or more <joined-dialog> elements containing other the presence of one or more <joined-dialog> elements containing other
SIP dialog identifiers. A UA MUST render the appearance number to SIP dialog identifiers. Appearance numbers of dialogs can be learned
the user or display appearance status information to the user in a by dialog package notifications containing the <appearance> element
way that preserves the appearance order. Appearance numbers of from the Appearance Agent or from the 'appearance' Alert-Info
dialogs can be learned by dialog package notifications containing the parameter in an incoming INVITE. Should they conflict, the dialog
<appearance> element from the Appearance Agent or from the package notification takes precedence.
'appearance' Alert-Info parameter in an incoming INVITE. Should they
conflict, the dialog package notification takes precedence.
A UA that does not need to seize a particular appearance number (or A UA that does not need to seize a particular appearance number (or
doesn't care) would just send an INVITE as normal to place an doesn't care) would just send an INVITE as normal to place an
outbound call. outbound call.
A user may select an appearance number but then abandon placing a
call (go back on hook). In this case, the UA SHOULD free up the
appearance number by removing the event state with a PUBLISH as
described in [RFC3903].
A UA wanting to place a call but not have an appearance number A UA wanting to place a call but not have an appearance number
assigned publishes before sending the INVITE without an 'appearance' assigned publishes before sending the INVITE without an 'appearance'
element but with the 'shared' event package parameter present. If element but with the 'shared' event package parameter present. If
the Appearance Agent policy does not allow calls without an assigned the Appearance Agent policy does not allow calls without an assigned
appearance number, a 409 Conflict response will be received, and the appearance number, a 409 Conflict response will be received, and the
UA will republish either selecting/seizing an appearance number or UA will republish either selecting/seizing an appearance number or
send the INVITE without publishing, in which case the Appearance send the INVITE without publishing, in which case the Appearance
Agent will assign one. Agent will assign one.
Note that if an Appearance Agent rejects calls without an
appearance number, certain operations such as consultation calls
and music on hold may be impacted.
When an INVITE is generated to attempt to bridge or take a call (i.e. When an INVITE is generated to attempt to bridge or take a call (i.e.
contains Join or Replaces with a dialog identifier of another dialog contains Join or Replaces with a dialog identifier of another dialog
in the shared appearance group), the appearance number of the joined in the shared appearance group), the appearance number of the joined
or replaced call SHOULD be published. The publication MUST contain or replaced call SHOULD be published. The publication MUST contain
the appearance number of the dialog to be joined or replaced and the the appearance number of the dialog to be joined or replaced and the
dialog identifier in the 'joined-dialog' or 'replaced-dialog' dialog identifier in the 'joined-dialog' or 'replaced-dialog'
elements. elements.
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
skipping to change at page 16, line 11 skipping to change at page 16, line 47
dialog package state agent for the UAs registered against the AOR. dialog package state agent for the UAs registered against the AOR.
The Appearance Agent MUST support the appearance dialog package The Appearance Agent MUST support the appearance dialog package
extensions defined in Section 5.2. The Appearance Agent MUST support extensions defined in Section 5.2. The Appearance Agent MUST support
publications and subscriptions for this event package. publications and subscriptions for this event package.
The Appearance Agent MUST have a way of discovering the state of all The Appearance Agent MUST have a way of discovering the state of all
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 B2BUA, the Appearance Agent available from a call stateful proxy or B2BUA, the Appearance Agent
MAY use the registration event package [RFC3680] to learn of UAs MAY use the registration event package [RFC3680] to learn of UAs
associated with the AOR and MAY subscribe to their dialog event associated with the AOR and MAY subscribe to their dialog event
state. As a result, the registrar MUST support the registration state. Also, an Appearance Agent MAY subscribe to a UAs dialog event
event package. The Appearance Agent SHOULD send dialog event state state in order to reconstruct state. As a result, the registrar MUST
notifications whenever the following events happen to UAs in the AOR support the registration event package. The Appearance Agent SHOULD
group: 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. The Appearance Agent MUST be able to to the shared group AOR. The Appearance Agent MUST be able to
communicate with the forking proxy to learn about incoming calls and communicate with the forking proxy to learn about incoming calls and
also to pass the appearance number to the proxy to insert in the also to pass the appearance number to the proxy to insert in the
Alert-Info header field. Alert-Info header field.
Note that UAs need to be able to handle incoming INVITEs without
an appearance number assigned. This could be caused by a failure
of the Appearance Agent or other error condition. Although the
proper rendering of the INVITE may not be possible, this is better
than ignoring or failing the INVITE.
An Appearance Agent SHOULD assign an appearance number to an outgoing An Appearance Agent SHOULD assign an appearance number to an outgoing
dialog if a PUBLISH has not been received selecting/seizing a dialog if a PUBLISH has not been received selecting/seizing a
particular appearance number. particular appearance number.
Note that if the appearance group has appearance-unaware UAs Note that if the appearance group has appearance-unaware UAs
making calls, the Appearance Agent will still allocate appearance making calls, the Appearance Agent will still allocate appearance
numbers for INVITEs sent by those UAs. numbers for INVITEs sent by those UAs.
An Appearance Agent receiving a PUBLISH with an appearance number An Appearance Agent receiving a PUBLISH with an appearance number
checks to make sure the publication is valid. An appearance number checks to make sure the publication is valid. An appearance number
skipping to change at page 16, line 49 skipping to change at page 17, line 44
or 'replaced-dialog' element indicating that the dialog will be/has or 'replaced-dialog' element indicating that the dialog will be/has
been replaced or joined. A 409 Conflict response is returned if the been replaced or joined. A 409 Conflict response is returned if the
chosen appearance number is invalid, and an immediate NOTIFY should chosen appearance number is invalid, and an immediate NOTIFY should
be sent to the UA containing full dialog event state. 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 package parameter present interprets this but with the 'shared' event package parameter present interprets this
as a request by the UA to not assign an appearance number. If the as a request by the UA to not assign an appearance number. If the
Appearance Agent policy does not allow this, a 409 Conflict response Appearance Agent policy does not allow this, a 409 Conflict response
is returned. If policy does allow this, a 200 OK response is is returned. If policy does allow this, a 200 OK response is
returned and no appearance number is allocated. returned and no appearance number is allocated. An Appearance Agent
does not have to share this dialog information with other UAs in the
group as the information will not be rendered by the other UAs.
The Appearance Agent allocates an appearance 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 the appearance is terminted, including all dialogs which are with the appearance is terminated, including all dialogs which are
joined or replaced. During the early dialog state, the Appearance joined or replaced. During the early dialog state, the Appearance
Agent controls the rate of dialog state publication using the Expires Agent controls the rate of dialog state publication using the Expires
header field in 200 OK responses to PUBLISH requests. An interval of header field in 200 OK responses to PUBLISH requests. An interval of
3 minutes is RECOMMENDED. After the dialog associated with the 3 minutes is RECOMMENDED. After the dialog associated with the
publication has been confirmed, the expiration of the publication publication has been confirmed, the expiration of the publication
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 can not 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. can then be assigned to the particular dialog. A UA which has been
allocated an appearance number using a PUBLISH MAY free up the
appearance number by removing the event state with a PUBLISH as
described in [RFC3903].
During dynamic situations, such as during a call pickup or join During dynamic situations, such as during a call pickup or join
action, the Appearance Agent MAY choose to implement rate limiting to action, the Appearance Agent MAY choose to implement rate limiting to
reduce the amount of notification traffic. For example, an reduce the amount of notification traffic. For example, an
Appearance Agent may choose not to generate immediate NOTIFYs upon Appearance Agent may choose not to generate immediate NOTIFYs upon
receipt of PUBLISHes. Instead, a single NOTIFY can convey the receipt of PUBLISHes. Instead, a single NOTIFY can convey the
effects of a number of PUBLISHes, thus reducing the NOTIFY traffic effects of a number of PUBLISHes, thus reducing the NOTIFY traffic
within the group. within the group.
If an INVITE is sent 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 UA
associated with the group AOR is a participant. If an incoming
INVITE to the group AOR is forwarded to another AOR, the appearance
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:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info-info" targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info-info"
skipping to change at page 29, line 20 skipping to change at page 30, line 20
INVITE sip:bob@ua2.example.com SIP/2.0 INVITE sip:bob@ua2.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=44BAD75D-E3128D42 From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
To: <sip:HelpDesk@example.com> To: <sip:HelpDesk@example.com>
CSeq: 106 INVITE CSeq: 106 INVITE
Call-ID: 14-1541707345 Call-ID: 14-1541707345
Contact: <sip:carol@ua3.example.com> Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69 Max-Forwards: 69
Alert-Info: <urn:alert:tone:normal>;appearance=1 Alert-Info: <urn:alert:service:normal>;appearance=1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
v=0 v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com o=- 1102980499 1102980499 IN IP4 ua3.example.com
s= s=
c=IN IP4 ua3.example.com c=IN IP4 ua3.example.com
t=0 0 t=0 0
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
skipping to change at page 32, line 32 skipping to change at page 33, line 32
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator"> local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F6 Appearance Agent ----> Bob F6 Appearance Agent ----> Bob
skipping to change at page 33, line 21 skipping to change at page 34, line 21
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator"> local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.4. Outgoing Call with Appearance Seizure 10.4. Outgoing Call with Appearance Seizure
skipping to change at page 34, line 46 skipping to change at page 35, line 46
| | |>F23 200 OK ->| | | | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>| | | | |------ NOTIFY F24>|
| | | | | | | | | |
| | | |<F25 200 OK -----<| | | | |<F25 200 OK -----<|
| | | | | | | | | |
Figure 4. Figure 4.
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 state agent that the outgoing INVITE request, Bob publishes to the Appearance Agent
Alice line appearance is in (trying) state. The Appearance Agent reserving appearance number 1. The Appearance Agent notifies Alice
notifies Alice (and all other UAs, including Bob) of of the event by (and all other UAs, including Bob) of the event by sending NOTIFYs.
sending NOTIFYs. Note the shortened expiration interval in F2 of 60
seconds. As long as Bob is using the appearance number, he must
refresh the publication every 60 seconds or lose the appearance.
F1 Bob ----> Appearance Agent F1 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=z9hG4bK61314d6446383E79 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip: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>
Event: dialog;shared Event: dialog;shared
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
skipping to change at page 35, line 26 skipping to change at page 36, line 23
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6" version="6"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
F2 Appearance Agent ----> Bob F2 Appearance Agent ----> Bob
skipping to change at page 36, line 4 skipping to change at page 36, line 47
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
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>
Event: dialog;shared Event: dialog;shared
SIP-Etag: 482943245 SIP-Etag: 482943245
Allow-Events: dialog Allow-Events: dialog
Expires: 60 Expires: 60
Content-Length: 0 Content-Length: 0
F7 Bob ---> Proxy
F7 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=z9hG4bK342122 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122
Max-Forwards: 70 Max-Forwards: 70
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>
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
CSeq: 31 INVITE CSeq: 31 INVITE
Contact: <sip:bob@ua2.example.com> Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
skipping to change at page 36, line 43 skipping to change at page 37, line 41
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6" version="6"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
direction="initiator"> direction="initiator">
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
<remote> <remote>
<identity uri="sip:carol@example.com"> <identity uri="sip:carol@example.com">
</identity> </identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.5. Outgoing Call without using an Appearance Number 10.5. Outgoing Call without using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' dialog event parameter. appearance element but does have the 'shared' dialog event parameter.
skipping to change at page 40, line 18 skipping to change at page 41, line 16
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27" version="27"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" <dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator"> direction="initiator">
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>terminated</state> <state>terminated</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
10.7. Appearance Pickup 10.7. Appearance Pickup
skipping to change at page 42, line 42 skipping to change at page 43, line 39
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c" remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator"> direction="initiator">
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<state>active</state> <state>active</state>
<local> <local>
<target uri="sip:bob@ua2.example.com"> <target uri="sip:bob@ua2.example.com">
<param pname="+sip.rendering" pval="no"/> <param pname="+sip.rendering" pval="no"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity>sip:carol@example.com</identity> <identity>sip:carol@example.com</identity>
<target uri="sip:carol@ua3.example.com" /> <target uri="sip:carol@ua3.example.com" />
skipping to change at page 43, line 33 skipping to change at page 44, line 31
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6" call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" > local-tag="8C4183CB-BCEAB710" >
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog <sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5" call-id="f3b3cbd0-a2c5775e-5df9f8d5"
from-tag="15A3DE7C-9283203B" from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" /> to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sip:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="yes"/>
</target> </target>
</local> </local>
<remote> <remote>
<target uri="sip:carol@ua3.example.com" /> <target uri="sip:carol@ua3.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
F38 Alice ----> Proxy
F38 Alice ----> Proxy
INVITE sip:carol@example.com SIP/2.0 INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sip:HelpDesk@example.com>;tag=8C4183CB-BCEAB710 From: <sip:HelpDesk@example.com>;tag=8C4183CB-BCEAB710
To: <sip:carol@example.com:5075> To: <sip:carol@example.com:5075>
CSeq: 1 INVITE CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6 Call-ID: 3d57cd17-47deb849-dca8b6c6
Contact: <sip:alice@ua1.example.com> Contact: <sip:alice@ua1.example.com>
<all-one-line> <all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
skipping to change at page 44, line 35 skipping to change at page 45, line 33
t=0 0 t=0 0
a=sendrecv a=sendrecv
m=audio 2238 RTP/AVP 0 8 101 m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000
10.8. Calls between UAs within the Group 10.8. Calls between UAs within the Group
In this scenario, Bob calls Alice who is also in the Appearance In this scenario, Bob calls Alice who is also in the Appearance
group. group. Only one appearance number is used for this dialog. This
example also shows the use of the 'exclusive' tag to 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 47, line 27 skipping to change at page 48, line 27
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
hold server instead of Alice to implement a music on hold service as
described in [I-D.worley-service-example].
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 51, line 28 skipping to change at page 52, line 31
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com:5060"> entity="sip:HelpDesk@example.com:5060">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48" call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" > local-tag="605AD957-1F6305C2" >
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<sa:joined-dialog <sa:joined-dialog
call-id="14-1541707345" call-id="14-1541707345"
from-tag="44BAD75D-E3128D42" from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>trying</state> <state>trying</state>
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sip:alice@ua1.example.com">
</target> </target>
</local> </local>
skipping to change at page 53, line 48 skipping to change at page 54, line 48
| | | NOTIFY is retransmitted | | | | NOTIFY is retransmitted |
Figure 11. Figure 11.
10.12. Appearance Seizure Contention Race Condition 10.12. Appearance Seizure Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the Bob and Alice both try to reserve appearance 2 by publishing at the
same time. The Appearance Agent allocates the appearance to Bob by same time. The Appearance Agent allocates the appearance to Bob by
sending a 200 OK and denies it to Alice by sending a 409 Conflict. sending a 200 OK and denies it to Alice by sending a 409 Conflict.
After the NOTIFY F5, Alice learns that Bob is using appearance 2. After the NOTIFY F5, Alice learns that Bob is using appearance 2.
Alice republishes for appearance 3 which is accepted. Alice then attempts to reserve appearance 3 by publishing, which is
then accepted.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| | | | |<----- PUBLISH F1<|
| | | | (appearance=2) | | | | (appearance=2)
| | |>F2 PUBLISH ->| | | | |>F2 PUBLISH ->| |
| | | (appearance=2) | | | | (appearance=2) |
| | | | | | | | | |
| | | |>F3 200 OK ------>| | | | |>F3 200 OK ------>|
| | |<---- F4 409 <| | | | |<---- F4 409 <| |
skipping to change at page 58, line 33 skipping to change at page 59, line 33
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" <dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48" call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" > local-tag="605AD957-1F6305C2" >
<sa:appearance>0</sa:appearance> <sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive> <sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog <sa:replaced-dialog
call-id="14-1541707345" call-id="14-1541707345"
from-tag="44BAD75D-E3128D42" from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>terminated</state> <state>terminated</state>
<local> <local>
<target uri="sip:alice@ua1.example.com"> <target uri="sip:alice@ua1.example.com">
</target> </target>
</local> </local>
skipping to change at page 60, line 10 skipping to change at page 61, line 10
| |>F17 100 ----->| | | | |>F17 100 ----->| | |
|<- INVITE F18<| | | | |<- INVITE F18<| | | |
Figure 15. Figure 15.
11. Incoming Appearance Assignment 11. Incoming Appearance Assignment
A proxy inserting an 'appearance' Alert-Info parameter follows normal A proxy inserting an 'appearance' Alert-Info parameter follows normal
policies Alert-Info policies. If an Alert-Info is already present, policies Alert-Info policies. If an Alert-Info is already present,
the proxy either removes the Alert-Info if it is not trusted, or adds the proxy either removes the Alert-Info if it is not trusted, or adds
the 'appearance' parameter to the Alert-Info header field. If no the 'appearance' parameter to the Alert-Info header field. If an
special ringtone is desired, a normal ringtone should be indicated appearance number parameter is already present (associated with
using the urn:alert:tone:normal in the Alert-Info, as per another AOR or by mistake), the value is rewritten adding the new
[I-D.liess-dispatch-alert-info-urns]. appearance number. There MUST NOT be more than one appearance
parameter in an Alert-Info header field.
If no special ringtone is desired, a normal ringtone should be
indicated using the urn:alert:service:normal in the Alert-Info, as
per [I-D.liess-dispatch-alert-info-urns]. The appearance number
present in an Alert-Info header field SHOULD be rendered by the UA to
the user, following the guidelines in Section 5.3. If the INVITE is
forwarded to another AOR, the appearance parameter in the Alert-Info
SHOULD be removed 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 are a variety of ways the proxy can use to determine what
value it should use to populate this parameter. For example, the value it should use to populate this parameter. For example, the
proxy could fetch this information by initiating a SUBSCRIBE proxy could fetch this information by initiating a SUBSCRIBE
request with Expires: 0 to the Appearance Agent for the AOR to request with Expires: 0 to the Appearance Agent for the AOR to
fetch the list of lines that are in use. Alternatively, it could fetch the list of lines that are in use. Alternatively, it could
skipping to change at page 62, line 13 skipping to change at page 63, line 13
new dialogs in the message body. new dialogs in the message body.
13.2. URN Sub-Namespace Registration: sa-dialog-info 13.2. 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 [RFC3688]. in [RFC3688].
URI: urn:ietf:params:xml:ns:sa-dialog-info. URI: urn:ietf:params:xml:ns:sa-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan@sipstation.com> Alan Johnston <alan.b.johnston@gmail.com>
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"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"
skipping to change at page 62, line 44 skipping to change at page 63, line 44
END END
13.3. XML Schema Registration 13.3. 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@sipstation.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. Acknowledgements
The following individuals were part of the shared appearance Design The following individuals were part of the shared appearance Design
team and have provided input and text to the document (in team and have provided input and text to the document (in
alphabetical order): alphabetical order):
Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
skipping to change at page 63, line 34 skipping to change at page 64, line 34
Inc. Inc.
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
comments. comments.
Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji
Chinnappa, and Harsh Mendiratta for their detailed review of the Chinnappa, and Harsh Mendiratta for their detailed review of the
document. document.
15. Informative References 15. References
15.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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
skipping to change at page 64, line 12 skipping to change at page 65, line 13
draft-ietf-sipcore-rfc3265bis-01 (work in progress), draft-ietf-sipcore-rfc3265bis-01 (work in progress),
February 2010. February 2010.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004. September 2004.
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005. Protocol (SIP)", RFC 4235, November 2005.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004. (SIP) "Join" Header", RFC 3911, October 2004.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[I-D.liess-dispatch-alert-info-urns]
Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and
A. Siddiqui, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-liess-dispatch-alert-info-urns-02
(work in progress), July 2010.
15.2. Informative References
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004. Package for Registrations", RFC 3680, March 2004.
[I-D.liess-dispatch-alert-info-urns] [I-D.worley-service-example]
Alexeitsev, D., Liess, L., Jesske, R., Johnston, A., and Worley, D., "Session Initiation Protocol Service Example
A. Siddiqui, "Alert-Info URNs for the Session Initiation -- Music on Hold", draft-worley-service-example-05 (work
Protocol (SIP)", draft-liess-dispatch-alert-info-urns-01 in progress), July 2010.
(work in progress), February 2010.
Authors' Addresses Authors' Addresses
Alan Johnston (editor) Alan Johnston (editor)
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Mohsen Soroushnejad Mohsen Soroushnejad
Sylantro Systems Corp Sylantro Systems Corp
Email: mohsen.soroush@sylantro.com Email: mohsen.soroush@sylantro.com
Venkatesh Venkataramanan Venkatesh Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
Email: vvenkatar@gmail.com Email: vvenkatar@gmail.com
 End of changes. 60 change blocks. 
126 lines changed or deleted 197 lines changed or added

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