draft-ietf-bliss-shared-appearances-04.txt   draft-ietf-bliss-shared-appearances-05.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Expires: April 29, 2010 M. Soroushnejad Expires: September 8, 2010 M. Soroushnejad
V. Venkataramanan V. Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
October 26, 2009 March 7, 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-04 draft-ietf-bliss-shared-appearances-05
Abstract
This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation
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
feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment. This feature
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
join calls within the group. This document discusses use cases,
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document describes the requirements and implementation of a This document may contain material from IETF Documents or IETF
group telephony feature commonly known as Bridged Line Appearance Contributions published or made publicly available before November
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line 10, 2008. The person(s) controlling the copyright in some of this
Appearance (SCA). When implemented using the Session Initiation material may not have granted the IETF Trust the right to allow
Protocol (SIP), it is referred to as shared appearances of an Address modifications of such material outside the IETF Standards Process.
of Record (AOR) since SIP does not have the concept of lines. This Without obtaining an adequate license from the person(s) controlling
feature is commonly offered in IP Centrex services and IP-PBX the copyright in such materials, this document may not be modified
offerings and is likely to be implemented on SIP IP telephones and outside the IETF Standards Process, and derivative works of it may
SIP feature servers used in a business environment. This document not be created outside the IETF Standards Process, except to format
discusses use cases, lists requirements and defines SIP extensions to it for publication as an RFC or to translate it into languages other
implement this feature. 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 . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
4. Requirements and Implementation . . . . . . . . . . . . . . . 7 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9
5. Normative Description . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . 11
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 11 5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12
5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 11 5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 12
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 12 5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 12
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 12 5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 12
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 12 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 15
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 17 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 17
7. User Interface Considerations . . . . . . . . . . . . . . . . 19 7. User Interface Considerations . . . . . . . . . . . . . . . . 19
7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 19 7.1. Appearance Number Rendering . . . . . . . . . . . . . . . 19
7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 19 7.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 19
7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 19 7.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 19
7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 19 7.1.3. Shared Appearance UAs with Fixed Appearance Number . . 19
7.1.4. Shared Appearance UAs with Variable Appearance 7.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 20 Number . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 20 7.2. Call State Rendering . . . . . . . . . . . . . . . . . . 20
skipping to change at page 4, line 8 skipping to change at page 4, line 8
10.8. Calls between UAs within the Group . . . . . . . . . . . 44 10.8. Calls between UAs within the Group . . . . . . . . . . . 44
10.9. Consultation Hold with Appearances . . . . . . . . . . . 47 10.9. Consultation Hold with Appearances . . . . . . . . . . . 47
10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 49 10.10. Joining or Bridging an Appearance . . . . . . . . . . . . 49
10.11. Appearance Allocation - Loss of Appearance . . . . . . . 52 10.11. Appearance Allocation - Loss of Appearance . . . . . . . 52
10.12. Appearance Seizure Contention Race Condition . . . . . . 53 10.12. Appearance Seizure Contention Race Condition . . . . . . 53
10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 54 10.13. Appearance Agent Subscription to UAs . . . . . . . . . . 54
10.14. Appearance Pickup Race Condition Failure . . . . . . . . 56 10.14. Appearance Pickup Race Condition Failure . . . . . . . . 56
10.15. Appearance Seizure Incoming/Outgoing Contention Race 10.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . . 59 Condition . . . . . . . . . . . . . . . . . . . . . . . . 59
11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 60 11. Incoming Appearance Assignment . . . . . . . . . . . . . . . . 60
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 12. Security Considerations . . . . . . . . . . . . . . . . . . . 60
12.1. SIP Event Package Parameter: shared . . . . . . . . . . . 61 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
12.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 62 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 61
12.3. XML Schema Registration . . . . . . . . . . . . . . . . . 62 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 62
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 62
14. Security Considerations . . . . . . . . . . . . . . . . . . . 63 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
15. Informative References . . . . . . . . . . . . . . . . . . . . 64 15. Informative References . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
The feature and functionality requirements for SIP user agents (UAs) The feature and functionality requirements for SIP user agents (UAs)
supporting business telephony applications differ greatly from basic supporting business telephony applications differ greatly from basic
SIP user agents, both in terms of services and end user experience. SIP user agents, both in terms of services and end user experience.
In addition to basic SIP support [RFC3261], many of the services in a In addition to basic SIP support [RFC3261], many of the services in a
business environment require the support for SIP extensions such as business environment require the support for SIP extensions such as
REFER [RFC3515], SUBSCRIBE/NOTIFY primitives REFER [RFC3515], SUBSCRIBE/NOTIFY primitives
[I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces [I-D.ietf-sipcore-rfc3265bis] PUBLISH [RFC3903], the SIP Replaces
skipping to change at page 5, line 41 skipping to change at page 5, line 41
package [RFC4235] to exchange dialog state information to achieve the package [RFC4235] to exchange dialog state information to achieve the
same. Different approaches will be discussed including the use of same. Different approaches will be discussed including the use of
URI parameters, feature tags, and dialog package extensions along URI parameters, feature tags, and dialog package extensions along
with the strengths and weaknesses of the various approaches. with the strengths and weaknesses of the various approaches.
In traditional telephony, the line is physical. A common scenario in In traditional telephony, the line is physical. A common scenario in
telephony is for a number of business telephones to share a single or telephony is for a number of business telephones to share a single or
a small number of lines. The sharing or appearance of these lines a small number of lines. The sharing or appearance of these lines
between a number of phones is what gives this feature its name. A between a number of phones is what gives this feature its name. A
common scenario in SIP is for a number of business telephones to common scenario in SIP is for a number of business telephones to
share a single or a small number of Address of Record (AOR) URIs. In share a single or a small number of Address of Record (AOR) URIs.
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 or an user interface for the telephone - typically each appearance of an
AOR has a visual display (lamp that can change color or blink or a AOR has a visual display (lamp that can change color or blink or a
screen icon) and a button (used to select the appearance). The screen icon) and a button (used to select the appearance). The
telephony concept of line appearance is still relevant to SIP due to telephony concept of line appearance is still relevant to SIP due to
the user interface considerations. It is important to keep the the user interface considerations. It is important to keep the
appearance number construct because: appearance number construct because:
1. Human users are used to the concept and will expect it in 1. Human users are used to the concept and will expect it in
replacement systems (e.g. an overhead page announcement says "Joe replacement systems (e.g. an overhead page announcement says "Joe
pickup line 3"). pickup line 3").
2. It is a useful structure for user interface representation. 2. It is a useful structure for user interface representation.
In this document, we will use the term "appearance" rather than "line The purpose of the appearance number is to identify active calls to
appearance" since SIP does not have the concept of lines. Note that facilitate sharing between users (e.g. passing a call from one user
this does not mean that a conventional telephony user interface to another). If a telephone has enough buttons/lamps, calls could be
(lamps and buttons) must be used - implementations may use another presented on the nth button. If not, it may still be desirable to
metaphor as long as the appearance number is readily apparent to the present the call state, but the appearance number should be displayed
user. Each AOR has a separate appearance numbering space. As a so that users know which call, for example, is on hold on which key.
result, a given UA user interface may have multiple occurrences of
the same appearance number, but they will be for different AORs. In this document, except for the usage scenarios in the next section,
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
that a conventional telephony user interface (lamps and buttons) must
be used - implementations may use another metaphor as long as the
appearance number is readily apparent to the user. Each AOR has a
separate appearance numbering space. As a result, a given UA user
interface may have multiple occurrences of the same appearance
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] and
indicate requirement levels for compliant mechanisms. 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 differences relate to the feature described in this document. The main differences relate to
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 the line appearances of each other on each specific groups and share an AOR. For example, an IT department
others SIP telephony devices. For example, an IT department staff of staff of five might answer a help line which has three appearances on
five might answer a help line which has three appearances on each each phone in the IT work area. A call answered on one phone can be
phone in the IT work area. A call answered on one phone can be put put on hold and picked up on another phone. A shout or an IM to
on hold and picked up on another phone. A shout or an IM to another another staff member can result in them taking over a call on a
staff member can result in them taking over a call on a particular particular appearance. Another phone can request to be added/joined/
appearance. Another phone can request to be added, joined, or
bridged to an existing appearance resulting in a conference call. bridged to an existing appearance resulting in a conference call.
3.3. Single Line Extension 3.3. Single Line Extension
In this scenario, incoming calls are offered to a group of UAs. When In this scenario, incoming calls are offered to a group of UAs. When
one answers, the other UAs are informed. If another UA in the group one answers, the other UAs are informed. If another UA in the group
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.
skipping to change at page 7, line 32 skipping to change at page 7, line 41
The basic requirements of the shared appearance feature can be The basic requirements of the shared appearance feature can be
summarized as follows: summarized as follows:
REQ-1 Incoming calls to the AOR must be offered to a group of UAs and REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
can be answered by any of them. can be answered by any of them.
REQ-2 Each UA in the group must be able to learn the call status of REQ-2 Each UA in the group must be able to learn the call status of
the others in the group for the purpose of rendering this information the others in the group for the purpose of rendering this information
to the user. to the user.
REQ-3 Calls can be joined (also called bridged or conferenced REQ-3 A UA must be able to join (also called bridge or conference
together) or can be picked up (taken) by another UA in the group in a together) or pick up (take) an active call of another UA in the group
secure way. 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 be able
to participate in the appearance group without manual configuration to participate in the appearance group without manual configuration
of group members. of group members.
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 appearance
status of the the group. status 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 39 skipping to change at page 9, line 43
While the appearance resource could be managed co-operatively by a While the appearance resource could be managed co-operatively by a
group of UAs without any central control, this is outside the scope group of UAs without any central control, this is outside the scope
of this draft. It is also possible that the Appearance Agent logic of this draft. It is also possible that the Appearance Agent logic
could be distributed in all UAs in the group. For example, rules could be distributed in all UAs in the group. For example, rules
that govern assigning appearance numbers for incoming requests (e.g. that govern assigning appearance numbers for incoming requests (e.g.
lowest available appearance number) and rules for contention handling lowest available appearance number) and rules for contention handling
(e.g. when two UAs request the use of the same appearance number, (e.g. when two UAs request the use of the same appearance number,
hash dialog identifiers and compare with the lowest hash winning) hash dialog identifiers and compare with the lowest hash winning)
would need to be defined and implemented. would need to be defined and implemented.
To best meet REQ-9, the appearance number for an incoming INVITE
needs to be contained in the INVITE, in addition to being delivered
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
not know which appearance number to render during alerting.
This specification defines an extension parameter for the Alert-Info
header field in RFC 3261 to carry the appearance number:
Alert-Info: <urn:alert:tone:normal>;appearance=0
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,
and hence no Appearance Agent and this feature is not and hence no Appearance Agent and this feature is not
skipping to change at page 12, line 25 skipping to change at page 12, line 41
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.
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 notifications 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.
5.2.4. The <replaced-dialog> element 5.2.4. The <replaced-dialog> element
The <replaced-dialog> element is used to convey dialog identifiers of The <replaced-dialog> element is used to convey dialog identifiers of
any other dialogs which will be or have been replaced with this any other dialogs which will be or have been replaced with this
dialog. For example, a UA in the group picking up a call on another dialog. For example, a UA in the group picking up a call on another
skipping to change at page 14, line 28 skipping to change at page 14, line 46
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. UAs SHOULD render information about other appearances to the user.
This includes the state (idle, active, busy, joined, etc.). UAs can This includes the state (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 SHOULD render the appearance number to SIP dialog identifiers. A UA MUST render the appearance number to
the user or display appearance status information to the user in a the user or display appearance status information to the user in a
way that preserves the appearance order. Appearance numbers of way that preserves the appearance order. Appearance numbers of
dialogs can be learned by dialog package notifications containing the dialogs can be learned by dialog package notifications containing the
<appearance> element from the Appearance Agent or from the <appearance> element from the Appearance Agent or from the
'appearance' Alert-Info parameter in an incoming INVITE. Should they 'appearance' Alert-Info parameter in an incoming INVITE. Should they
conflict, the dialog package notification takes precedence. conflict, the dialog package notification takes precedence.
A UA that does not need to 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 UA wanting to place a call but not have an appearance number A UA wanting to place a call but not have an appearance number
assigned publishes before sending the INVITE without an 'appearance' assigned publishes before sending the INVITE without an 'appearance'
element but with the 'shared' event package parameter present. If element but with the 'shared' event package parameter present. If
the Appearance Agent policy does not allow calls without an assigned the Appearance Agent policy does not allow calls without an assigned
appearance number, a 409 Conflict response will be received, and the appearance number, a 409 Conflict response will be received, and the
UA will republish either selecting/seizing an appearance number or UA will republish either selecting/seizing an appearance number or
without one, in which case the Appearance Agent will assign one. send the INVITE without publishing, in which case the Appearance
Agent will assign one.
When an INVITE is generated to attempt to bridge or take a call (i.e. When an INVITE is generated to attempt to bridge or take a call (i.e.
contains Join or Replaces with a dialog identifier of another dialog contains Join or Replaces with a dialog identifier of another dialog
in the shared appearance group), the appearance number of the joined in the shared appearance group), the appearance number of the joined
or replaced call SHOULD be used. The publication MUST contain the or replaced call SHOULD be published. The publication MUST contain
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. With that it can provide proper appearance assignment behavior. If the
Join, the goal is to prevent the Appearance Agent from generating INVITE Join or Replaces was sent without publishing first, the
a 409 Conflict response due to the reuse of an appearance number. Appearance Agent might assign a new appearance number to this
For Replaces, the goal is to prevent a race condition where the INVITE, which would be a mistake. With Join, the publication has
BYE could cause the appearance number to be released when it the 'joined-dialog' element to prevent the Appearance Agent from
should stay with the replacing dialog. generating a 409 Conflict response due to the reuse of an
appearance number. For Replaces, the purpose of the 'replaced-
dialog' is to prevent a race condition where the BYE could cause
the appearance number to be released when it should stay with the
replacing dialog.
A UA SHOULD register against the AOR only if it is likely the UA will A UA SHOULD register against the AOR only if it is likely the UA will
be answering incoming calls. If the UA is mainly going to be be answering incoming calls. If the UA is mainly going to be
monitoring the status of the shared appearance group calls and monitoring the status of the shared appearance group calls and
picking or joining calls, the UA SHOULD only subscribe to the AOR and picking or joining calls, the UA SHOULD only subscribe to the AOR and
not register against the AOR. not register against the AOR.
All subscribed UAs will received NOTIFYs of Trying state for All subscribed UAs will received NOTIFYs of Trying state for
incoming INVITEs. incoming INVITEs.
skipping to change at page 16, line 8 skipping to change at page 16, line 29
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.
An Appearance Agent SHOULD assign an appearance number to an outgoing An Appearance Agent SHOULD assign an appearance number to an outgoing
INVITE 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 non-shared appearance UAs, Note that if the appearance group has appearance-unaware UAs
the Appearance Agent will still allocate appearance numbers for making calls, the Appearance Agent will still allocate appearance
INVITEs sent by those UAs. numbers for INVITEs sent by those UAs.
An Appearance Agent receiving a PUBLISH with an appearance number An Appearance Agent receiving a PUBLISH with an appearance number
checks to make sure the publication is valid. An appearance number checks to make sure the publication is valid. An appearance number
can be assigned to only one dialog unless there is a 'joined-dialog' can be assigned to only one dialog unless there is a 'joined-dialog'
or 'replaced-dialog' element indicating that the dialog will be/has or 'replaced-dialog' element indicating that the dialog will be/has
been replaced or joined. A 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. In general, the returned and no appearance number is allocated.
dialog state will not be shared with the other UAs in the group.
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 terminted, including all dialogs which are
joined or replaced. During the early dialog state, the Appearance joined or replaced. During the early dialog state, the Appearance
Agent controls the rate of dialog state publication using the Expires Agent controls the rate of dialog state publication using the Expires
header field in 200 OK responses to PUBLISH requests. An interval of header field in 200 OK responses to PUBLISH requests. An interval of
3 minutes is RECOMMENDED. After the dialog associated with the 3 minutes is RECOMMENDED. After the dialog associated with the
publication has been confirmed, the expiration of the publication publication has been confirmed, the expiration of the publication
skipping to change at page 17, line 7 skipping to change at page 17, line 27
can then be assigned to the particular dialog. can then be assigned to the particular dialog.
During dynamic situations, such as during a call pickup or join During dynamic situations, such as during a call pickup or join
action, the Appearance Agent MAY choose to implement rate limiting to action, the Appearance Agent MAY choose to implement rate limiting to
reduce the amount of notification traffic. For example, an reduce the amount of notification traffic. For example, an
Appearance Agent may choose not to generate immediate NOTIFYs upon Appearance Agent may choose not to generate immediate NOTIFYs upon
receipt of PUBLISHes. Instead, a single NOTIFY can convey the receipt of PUBLISHes. Instead, a single NOTIFY can convey the
effects of a number of PUBLISHes, thus reducing the NOTIFY traffic effects of a number of PUBLISHes, thus reducing the NOTIFY traffic
within the group. within the group.
If an INVITE is sent and no appearance number is available, the proxy If an INVITE is sent by a member of the group using the shared AOR or
MAY reject the INVITE with a 403 Forbidden response code. sent to the shared AOR and no appearance number is available, the
proxy MAY reject the INVITE with a 403 Forbidden response code.
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
skipping to change at page 20, line 13 skipping to change at page 20, line 13
before proceeding with calls. before proceeding with calls.
7.1.4. Shared Appearance UAs with Variable Appearance Number 7.1.4. Shared Appearance UAs with Variable Appearance Number
This UA is typically a soft-phone or graphically rich user interface This UA is typically a soft-phone or graphically rich user interface
hard-phone. In these cases, even the idea of an appearance index may hard-phone. In these cases, even the idea of an appearance index may
seem unnecessary. However, for these phones to be able to interwork seem unnecessary. However, for these phones to be able to interwork
successfully with other phone types, it is important that they still successfully with other phone types, it is important that they still
use the appearance index to govern the order of appearance of calls use the appearance index to govern the order of appearance of calls
in progress. No specific guidance on presentation is given except in progress. No specific guidance on presentation is given except
that the order should be consistent. Thought should also be given to that the order should be consistent. These devices can typically
how an appearance number that has no call associated with it should make calls without waiting for confirmation from the Appearance Agent
be rendered to the user. These devices can typically make calls on the appearance number.
without waiting for confirmation from the Appearance Agent on the
appearance number.
The problems faced by each style of user interface are readily seen The problems faced by each style of user interface are readily seen
in this example: in this example:
1. A call arrives at the shared appearance group, and is assigned an 1. A call arrives at the shared appearance group, and is assigned an
appearance number of 0. All UAs should be able to render to the appearance number of 0. All UAs should be able to render to the
user the arrival of this call. user the arrival of this call.
2. Another call arrives at the shared appearance group, and is 2. Another call arrives at the shared appearance group, and is
assigned an appearance number of 1. The single appearance UA assigned an appearance number of 1. The single appearance UA
should not present this call to the user. Other user agents should not present this call to the user. Other user agents
should have no problems presenting this call distinctly from the should have no problems presenting this call distinctly from the
first call. first call.
3. The first call clears, releasing appearance number "0". The 3. The first call clears, releasing appearance number "0". The
single appearance UA should now be indicating no calls since it single appearance UA should now be indicating no calls since it
is unable to manage calls other than on the first appearance. is unable to manage calls other than on the first appearance.
Both shared appearance UAs should clearly show that appearance Both shared appearance UAs should clearly show that appearance
number 0 is now free, but that there is still a call on number 0 is now free, but that there is still a call on
appearance number 1. appearance number 1.
4. A third call arrives, and is assigned the appearance number of 0. 4. A third call arrives, and is assigned the appearance number of 0.
All UAs should be able to render the arrival of this new call to All UAs should be able to render the arrival of this new call to
the user. Multiple appearnce UAs should continue to indicate the the user. Multiple appearance UAs should continue to indicate
presence of the second call, and should also ensure that the the presence of the second call, and should also ensure that the
presentation order is related to the appearance number and not presentation order is related to the appearance number and not
the order of call arrival. the order of call arrival.
7.2. Call State Rendering 7.2. Call State Rendering
UAs that implement the shared appearance feature typically have a UAs that implement the shared appearance feature typically have a
user interface that provides the state of other appearances in the user interface that provides the state of other appearances in the
group. As dialog state NOTIFYs from the Appearance Agent are group. As dialog state NOTIFYs from the Appearance Agent are
processed, this information can be rendered. Even the simplest user processed, this information can be rendered. Even the simplest user
interface typically has three states: idle, active, and hold. The interface typically has three states: idle, active, and hold. The
skipping to change at page 21, line 31 skipping to change at page 21, line 29
consequently shared appearance interop with non-shared appearance UAs consequently shared appearance interop with non-shared appearance UAs
will not be available in all shared appearance deployments. will not be available in all shared appearance deployments.
First, a UA which does not support dialog events or the shared First, a UA which does not support dialog events or the shared
appearance feature will be discussed. Then, a UA which does support appearance feature will be discussed. Then, a UA which does support
dialog events but not the shared appearance feature will be dialog events but not the shared appearance feature will be
discussed. discussed.
8.1. Appearance Assignment 8.1. Appearance Assignment
A UA that has no knowledge of appearances must have appearance A UA that has no knowledge of appearances must will only have
numbers assigned by the Appearance Agent for both incoming and appearance numbers for outgoing calls if assigned by the Appearance
outgoing calls. If the non-shared appearance UA does not support Agent. If the non-shared appearance UA does not support Join or
Join or Replaces, all dialogs could be marked "exclusive" to indicate Replaces, all dialogs could be marked "exclusive" to indicate that
that these options are not available. these options are not available.
8.2. Appearance Release 8.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 dialog lifetime to
release appearances back into the group. 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 which
Record-Routes for dialogs from the non-shared appearance aware UA, Record-Routes for dialogs from the non-shared appearance aware UA,
the Appearance Agent will know about the state of dialogs including the Appearance Agent will know about the state of dialogs including
hold, etc. This information could be determined from inspection of hold, etc. This information could be determined from inspection of
INVITE and re-INVITE messages and added to the dialog information INVITE and re-INVITE messages and added to the dialog information
conveyed to other UAs. conveyed to other UAs.
8.3. UAs Supporting Dialog Events but Not Shared Appearance 8.3. UAs Supporting Dialog Events but Not Shared Appearance
Interoperability with UAs which support dialog events but not the Interoperability with UAs which support dialog events but not the
shared appearance feature is more straightforward. As before, all shared appearance feature is more straightforward. As before, all
appearance number assignment must be done by the Appearance Agent. appearance number assignment must be done by the Appearance Agent.
This type of UA will be detected by the Appearance Agent by the The Appearance Agent can include appearance information in NOTIFYs -
absence of the 'shared' event parameter in SUBSCRIBE or PUBLISH this UA will simply ignore this extra information. This type of UA
messages. The Appearance Agent can include appearance information in will ignore appearance number limitations and may attempt to Join or
NOTIFYs - this UA will simply ignore this extra information. This Replace dialogs marked exclusive. As a result, the Proxy or UAs may
type of UA will ignore appearance number limitations and may attempt need to reject such requests.
to Join or Replace dialogs marked exclusive. As a result, the Proxy
or UAs may need to reject such requests.
The need for close cooperation between the Proxy and the Appearance
Agent is not needed as the Appearance Agent will learn about all
dialogs from the UA itself.
9. Provisioning Considerations 9. Provisioning Considerations
UAs can automatically discover if this feature is active for an AOR UAs can automatically discover if this feature is active for an AOR
by sending a SUBSCRIBE to the AOR, so no provisioning for this is by sending a SUBSCRIBE to the AOR, so no provisioning for this is
needed. needed.
The registrar will need to be provisioned to accept 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
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
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.
However, this mechanism does not provide any way to discover this by
protocol means.
10. Example Message Flows 10. Example Message Flows
The next section shows call flow and message examples. The flows and The next section shows call flow and message examples. The flows and
descriptions are non-normative. descriptions are non-normative. Note that in these examples, all
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
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
mechanisms.
Note that the first twelve examples assume the Appearance Agent is Note that the first twelve examples assume the Appearance Agent is
aware of dialog state events. Example 10.13 shows the case where aware of dialog state events. Example 10.13 shows the case where
this is not the case and as a result the Appearance Agent initiates a this is not the case and as a result the Appearance Agent initiates a
subscription to users of the shared AOR. Any of the other call flow subscription to users of the shared AOR. Any of the other call flow
examples could have shown this mode of operation as it is equally examples could have shown this mode of operation as it is equally
valid. valid.
10.1. Registration and Subscription 10.1. Registration and Subscription
skipping to change at page 24, line 35 skipping to change at page 24, line 44
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2
CSeq: 2 REGISTER CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb 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> Contact: <sip:alice@ua1.example.com>
Expires: 3600 Expires: 3600
Content-Length: 0 Content-Length: 0
F3 to F6: Alice also subscribes to the events associated with the F3 to F6: Alice also subscribes to the events associated with the
Appearance AOR. Appearance Agent also notifies Alice of the status. Appearance AOR. Appearance Agent 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 34, line 40 skipping to change at page 34, line 48
| | | | | | | | | |
| | | |<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 state agent that
Alice line appearance is in (trying) state. The Appearance Agent Alice line appearance is in (trying) state. The Appearance Agent
notifies Alice (and all other appearances) of the same event by notifies Alice (and all other UAs, including Bob) of of the event by
forwarding the NOTIFY payload provided by Bob. Since the Appearance sending NOTIFYs. Note the shortened expiration interval in F2 of 60
Agent is combining Bob's dialog status with statuses provided by
other appearances, it may have to change the dialog id attributes in
the XML to prevent values from being duplicated by different
appearances. Note the shortened expiration interval in F2 of 60
seconds. As long as Bob is using the appearance number, he must seconds. As long as Bob is using the appearance number, he must
refresh the publication every 60 seconds or loose the appearance. 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 39, line 4 skipping to change at page 39, line 6
version="6" version="6"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator"> <dialog id="id3d4f9c83" direction="initiator">
<sa:exclusive>false</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>
Note that F7 would be the same as the previous example. Note that F7 would be the same as the previous example.
10.6. Appearance Release 10.6. Appearance Release
Bob and Carol are in a dialog, created, for example as in Section Bob and Carol are in a dialog, created, for example as in Section
10.3. Carol sends a BYE to Bob to terminate the dialog. Bob 10.3. Carol sends a BYE to Bob to terminate the dialog and the
publishes the termination of the dialog and the Appearance Agent de- Appearance Agent de-allocates the appearance number used, sending
allocates the appearance number used. notifications out to the UAs in the shared group.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | | | | | | | |
|<================= Both way RTP established ===================>| |<================= Both way RTP established ===================>|
| | | | | | | | | |
|>F22 BYE ---->| | | | |>F22 BYE ---->| | | |
| |>F23 BYE --------------------------------------->| | |>F23 BYE --------------------------------------->|
| | | | | | | | | |
| |<------------------------------------ 200 OK F24<| | |<------------------------------------ 200 OK F24<|
skipping to change at page 45, line 39 skipping to change at page 45, line 41
| | |<- NOTIFY F17<| | | | |<- NOTIFY F17<| |
| | | | | | | | | |
| | |>F18 200 OK ->| | | | |>F18 200 OK ->| |
| | | |>F19 NOTIFY ----->| | | | |>F19 NOTIFY ----->|
| | | | | | | | | |
| | | |<----- 200 OK F24<| | | | |<----- 200 OK F24<|
| | | | | | | | | |
Figure 8. Figure 8.
F16 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
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
skipping to change at page 46, line 21 skipping to change at page 46, line 23
version="10" version="10"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="3xdsd4f9c83" <dialog id="3xdsd4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5" call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="34322kdfr234f" local-tag="34322kdfr234f"
remote-tag="3153DE7C-928203B" remote-tag="3153DE7C-928203B"
direction="initiator"> direction="initiator">
<sa:exclusive>true</sa:exclusive> <sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<state>connected</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>connected</state> <state>confirmed</state>
<local> <local>
<target uri="sip:alice@ua1.example.com" /> <target uri="sip:alice@ua1.example.com" />
</local> </local>
<remote> <remote>
<identity>sip:HelpDesk@example.com</identity> <identity>sip:HelpDesk@example.com</identity>
<target uri="sip:bob@ua2.example.com" /> <target uri="sip:bob@ua2.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
skipping to change at page 52, line 30 skipping to change at page 52, line 30
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
10.11. Appearance Allocation - Loss of Appearance 10.11. Appearance Allocation - Loss of Appearance
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 R24 and F26. terminated and frees up the appearance using NOTIFYs F14 and F16.
After retransmitting the NOTIFY F26 to Bob, the subscription is After retransmitting the NOTIFY to Bob (in not shown messages F17,
terminated. F18, etc.), the subscription is terminated.
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<| |
| | | | | | | | | |
| | |>F4 200 OK -->| | | | |>F4 200 OK -->| |
skipping to change at page 53, line 33 skipping to change at page 53, line 33
| | | | | | | | | |
| | | |>F11 200 OK ----->| | | | |>F11 200 OK ----->|
| | | | | | | | | |
|>F12 180 --->| | | | |>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->| | |>F13 180 Ringing ------------------------------->|
| | | | | | | | | |
| | | | Bob goes offline | | | | | Bob goes offline |
| | | | | | | | | |
| | | 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.
10.12. Appearance Seizure Contention Race Condition 10.12. Appearance Seizure Contention Race Condition
skipping to change at page 55, line 7 skipping to change at page 55, line 7
Figure 12. Figure 12.
10.13. Appearance Agent Subscription to UAs 10.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. Whenever Bob's dialog state changes, a NOTIFY is dialog event state using Event:dialog in the SUBSCRIBE. Whenever
sent to the Appearance Agent who then notifies the other other UAs in Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent
the group. who then notifies the other other UAs in the group.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| |<----------------------------------- REGISTER F1<| | |<----------------------------------- REGISTER F1<|
| | | | | | | | | |
| |>F2 200 OK ------------------------------------->| | |>F2 200 OK ------------------------------------->|
| | | | | | | | | |
| |>F3 NOTIFY ------------------>| | | |>F3 NOTIFY ------------------>| |
| | | | | | | | | |
| |<------------------ 200 OK F4<| | | |<------------------ 200 OK F4<| |
skipping to change at page 56, line 40 skipping to change at page 56, line 40
| | | |<F39 200 OK -----<| | | | |<F39 200 OK -----<|
| | | | | | | | | |
Figure 13. Figure 13.
10.14. Appearance Pickup Race Condition Failure 10.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 Bob 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.
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 60, line 7 skipping to change at page 60, line 7
| | | |<F15 200 OK -----<| | | | |<F15 200 OK -----<|
| |<-- INVITE F16<| | | | |<-- INVITE F16<| | |
| | | | | | | | | |
| |>F17 100 ----->| | | | |>F17 100 ----->| | |
|<- INVITE F18<| | | | |<- INVITE F18<| | | |
Figure 15. Figure 15.
11. Incoming Appearance Assignment 11. Incoming Appearance Assignment
To best meet REQ-9, the appearance number for an incoming INVITE
should be contained in the INVITE itself.
For the dialog package parameter approach, REQ-9 could be met in two
ways. When an incoming request is received, the Appearance Agent
could send out a NOTIFY with state trying and include the appearance
number to be used for this request. Upon receipt of this NOTIFY, the
UAs could begin alerting using the appearance number seized. This
approach is sub-optimal since the UAs could receive the INVITE but be
unable to begin alerting if the NOTIFY from the Appearance Agent is
delayed or lost
An alternative approach is to define an extension parameter for the
Alert-Info header field in RFC 3261 such as:
Alert-Info: <urn:alert:tone:normal>;appearance=0
This Alert-Info header would indicate to place the call on the first
line appearance instance.
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 no
special ringtone is desired, a normal ringtone should be indicated special ringtone is desired, a normal ringtone should be indicated
using the urn:alert:tone:normal in the Alert-Info, as per using the urn:alert:tone:normal in the Alert-Info, as per
[I-D.alexeitsev-bliss-alert-info-urns]. [I-D.liess-dispatch-alert-info-urns].
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 61, line 19 skipping to change at page 60, line 48
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.
The changes to RFC 3261 ABNF are: The changes to RFC 3261 ABNF are:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param / alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
appearance-param) ) appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT appearance-param = "appearance" EQUAL *DIGIT
12. IANA Considerations 12. Security Considerations
Since multiple line appearance features are implemented using
semantics provided by [RFC3261], Event Package for Dialog State as
define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
[RFC3903], security considerations in these documents apply to this
draft as well.
Specifically, since dialog state information and the dialog
identifiers are supplied by UA's in an appearance group to other
members, the same is prone to "call hijacks". For example, a rogue
UA could snoop for these identifiers and send an INVITE with Replaces
header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in [RFC3261]. before it
is accepted. NOTIFY or PUBLISH message bodies that provide the
dialog state information and the dialog identifiers MAY be encrypted
end-to-end using the standard mechanics. All SUBSCRIBES between the
UA's and the Appearance Agent MUST be authenticated.
13. IANA Considerations
This section registers the SIP event package parameter 'shared', the This section registers the SIP event package parameter 'shared', the
SIP Alert-Info header field parameter "appearance" and the XML SIP Alert-Info header field parameter "appearance" and the XML
namespace extensions to the SIP Dialog Package. namespace extensions to the SIP Dialog Package.
12.1. SIP Event Package Parameter: shared 13.1. SIP Event Package Parameter: shared
This specification defines a new event parameter 'shared' for the This specification defines a new event parameter 'shared' for the
Dialog Package. When used in a NOTIFY, it indicates that the Dialog Package. When used in a NOTIFY, it indicates that the
notifier supports the shared appearance feature. When used in a notifier supports the shared appearance feature. When used in a
PUBLISH, it indicates that the publisher has explicit appearance PUBLISH, it indicates that the publisher has explicit appearance
information contained in the message body. If not present in a information contained in the message body. If not present in a
PUBLISH, the Appearance Agent MAY assign an appearance number to any PUBLISH, the Appearance Agent MAY assign an appearance number to any
new dialogs in the message body. new dialogs in the message body.
12.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@sipstation.com>
XML: XML:
skipping to change at page 62, line 36 skipping to change at page 62, line 36
</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:dialog-info</h2> <h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfcXXXX.txt"> <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfcXXXX.txt">
RFCXXXX</a>.</p> RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
12.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@sipstation.com>
The XML for this schema can be found in Section 6. The XML for this schema can be found in Section 6.
13. 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
MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys. MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys.
Thanks to Chris Boulton for helping with the XML schema. Thanks to Chris Boulton for helping with the XML schema.
skipping to change at page 63, line 30 skipping to change at page 63, line 30
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
Towlson, and Michael Procter of Citel Technologies, Rob Harder and Towlson, and Michael Procter of Citel Technologies, Rob Harder and
Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
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 Francois Audet, Andy Hutton, Tim Ross, Raji Chinnappa, and Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji
Harsh Mendiratta for their detailed review of the document. Chinnappa, and Harsh Mendiratta for their detailed review of the
document.
14. Security Considerations
Since multiple line appearance features are implemented using
semantics provided by [RFC3261], Event Package for Dialog State as
define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
[RFC3903], security considerations in these documents apply to this
draft as well.
Specifically, since dialog state information and the dialog
identifiers are supplied by UA's in an appearance group to other
members, the same is prone to "call hijacks". For example, a rogue
UA could snoop for these identifiers and send an INVITE with Replaces
header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in [RFC3261]. before it
is accepted. NOTIFY or PUBLISH message bodies that provide the
dialog state information and the dialog identifiers MAY be encrypted
end-to-end using the standard mechanics. All SUBSCRIBES between the
UA's and the Appearance Agent MUST be authenticated.
15. Informative References 15. Informative 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
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[I-D.ietf-sipcore-rfc3265bis] [I-D.ietf-sipcore-rfc3265bis]
Roach, A., "SIP-Specific Event Notification", Roach, A., "SIP-Specific Event Notification",
draft-ietf-sipcore-rfc3265bis-00 (work in progress), draft-ietf-sipcore-rfc3265bis-01 (work in progress),
July 2009. 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 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
skipping to change at page 65, line 6 skipping to change at page 64, line 37
[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.
[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.alexeitsev-bliss-alert-info-urns] [I-D.liess-dispatch-alert-info-urns]
Alexeitsev, D., Liess, L., Jesske, R., Huelsemann, M., and Alexeitsev, D., Liess, L., Jesske, R., Johnston, A., and
A. Johnston, "Alert-Info URNs for the Session Initiation A. Siddiqui, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-alexeitsev-bliss-alert-info-urns-02 Protocol (SIP)", draft-liess-dispatch-alert-info-urns-01
(work in progress), July 2009. (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@sipstation.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. 
194 lines changed or deleted 206 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/