draft-ietf-bliss-shared-appearances-08.txt   draft-ietf-bliss-shared-appearances-09.txt 
BLISS A. Johnston, Ed. BLISS A. Johnston, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261, 4235 (if approved) M. Soroushnejad Updates: 3261, 4235 (if approved) M. Soroushnejad
Intended status: Standards Track V. Venkataramanan Intended status: Standards Track V. Venkataramanan
Expires: December 5, 2011 Sylantro Systems Corp Expires: July 2, 2012 Sylantro Systems Corp
June 3, 2011 December 30, 2011
Shared Appearances of a Session Initiation Protocol (SIP) Address of Shared Appearances of a Session Initiation Protocol (SIP) Address of
Record (AOR) Record (AOR)
draft-ietf-bliss-shared-appearances-08 draft-ietf-bliss-shared-appearances-09
Abstract Abstract
This document describes the requirements and implementation of a This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as shared appearances of an Address Protocol (SIP), it is referred to as shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. This of Record (AOR) since SIP does not have the concept of lines. This
feature is commonly offered in IP Centrex services and IP-PBX feature is commonly offered in IP Centrex services and IP-PBX
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2011. This Internet-Draft will expire on July 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 7
3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements and Implementation . . . . . . . . . . . . . . . 7 4. Requirements and Implementation . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9
5. Normative Description . . . . . . . . . . . . . . . . . . . . 11 5. Normative Description . . . . . . . . . . . . . . . . . . . . 11
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 12
5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12 5.2.1. The <appearance> element . . . . . . . . . . . . . . . 12
5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 13 5.2.2. The <exclusive> element . . . . . . . . . . . . . . . 12
5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13 5.2.3. The <joined-dialog> element . . . . . . . . . . . . . 13
5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 14 5.2.4. The <replaced-dialog> element . . . . . . . . . . . . 14
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 14
5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 17
5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17
5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 18 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 19
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21
7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23 7. Alert-Info Appearance Parameter Definition . . . . . . . . . . 23
8. User Interface Considerations . . . . . . . . . . . . . . . . 24 8. User Interface Considerations . . . . . . . . . . . . . . . . 24
8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24
8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24
8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24
8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 24 8.1.3. Shared Appearance UAs with Fixed Appearance Number . . 24
8.1.4. Shared Appearance UAs with Variable Appearance 8.1.4. Shared Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 25 Number . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1.5. Example User Interface Issues . . . . . . . . . . . . 25 8.1.5. Example User Interface Issues . . . . . . . . . . . . 25
skipping to change at page 5, line 31 skipping to change at page 5, line 31
popular advanced features expected of SIP IP telephony devices in a popular advanced features expected of SIP IP telephony devices in a
business environment. Other names for this feature include Shared business environment. Other names for this feature include Shared
Call/Line Appearance (SCA), Shared Call Status and Multiple Call Call/Line Appearance (SCA), Shared Call Status and Multiple Call
Appearance (MCA). A variant of this feature is known as Single Line Appearance (MCA). A variant of this feature is known as Single Line
Extension. Extension.
This document looks at how this feature can be implemented using This document looks at how this feature can be implemented using
standard SIP [RFC3261] in conjunction with SIP events standard SIP [RFC3261] in conjunction with SIP events
[I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] (carrying the [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] (carrying the
SIP dialog state event package [RFC4235]) for exchanging status among SIP dialog state event package [RFC4235]) for exchanging status among
user agents. Different approaches will be discussed including the user agents.
use of URI parameters, feature tags, and dialog package extensions
along with the strengths and weaknesses of the various approaches.
In traditional telephony, the line is physical. A common scenario in In traditional telephony, the line is physical. A common scenario in
telephony is for a number of business telephones to share a single or telephony is for a number of business telephones to share a single or
a small number of lines. The sharing or appearance of these lines a small number of lines. The sharing or appearance of these lines
between a number of phones is what gives this feature its name. A between a number of phones is what gives this feature its name. A
common scenario in SIP is for a number of business telephones to common scenario in SIP is for a number of business telephones to
share a single or a small number of Address of Record (AOR) URIs. share a single or a small number of Address of Record (AOR) URIs.
In addition, an AOR can have multiple appearances on a single UA in In addition, an AOR can have multiple appearances on a single UA in
terms of the user interface. The appearance number relates to the terms of the user interface. The appearance number relates to the
skipping to change at page 8, line 14 skipping to change at page 8, line 14
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) should be assigned
common "appearance" number from a managed pool administered for the a 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 status of all REQ-7 Each UA in the group must be able to learn the status of all
appearances of the group. appearances of the group.
REQ-8 There must be mechanisms to resolve appearance contention among REQ-8 There must be mechanisms to resolve appearance contention among
the UAs in the group. the UAs in the group.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
3. A forking proxy server that can communicate with the State Agent 3. A forking proxy server that can communicate with the State Agent
4. A registrar that supports the registration event package. 4. A registrar that supports the registration event package.
The behavior of these elements is described normatively in the The behavior of these elements is described normatively in the
following sections after the definitions of the dialog package following sections after the definitions of the dialog package
extensions. extensions.
5.2. Shared Appearance Dialog Package Extensions 5.2. Shared Appearance Dialog Package Extensions
This specification defines four new elements as extensions to the SIP This specification defines four new elements as extensions to the SIP
Dialog Event package [I-D.ietf-sipcore-rfc3265bis]. The schema is Dialog Event package [RFC4235]. The schema is defined in Section 6.
defined in Section 6. The elements are <appearance>, <exclusive>, The elements are <appearance>, <exclusive>, <joined-dialog>, and
<joined-dialog>, and <replaced-dialog> which are sub-elements of the <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, a child of the <dialog> element, is used to The <appearance> element, a child of the <dialog> element, is used to
convey the appearance number of the dialog described by the parent convey the appearance number of the dialog described by the parent
<dialog> element. When sent by a UA in a PUBLISH with parent <dialog> element. When sent by a UA in a PUBLISH with parent
<dialog> with state attribute "trying" to the Appearance Agent, the <dialog> with state attribute "trying" to the Appearance Agent, the
UA is requesting assignment of the given appearance number to the UA is requesting assignment of the given appearance number to the
current or future dialog with the given dialog identifiers. When an current or future dialog with the given dialog identifiers. When an
<appearance> element is sent by the Appearance Agent in a NOTIFY, it <appearance> element is sent by the Appearance Agent in a NOTIFY, it
skipping to change at page 13, line 38 skipping to change at page 13, line 33
If the proxy knows which dialogs are marked exclusive, the proxy MAY If the proxy knows which dialogs are marked exclusive, the proxy MAY
enforce this exclusivity by rejecting INVITE Join and INVITE Replaces enforce this exclusivity by rejecting INVITE Join and INVITE Replaces
requests containing those dialog identifiers with a 403 Forbidden requests containing those dialog identifiers with a 403 Forbidden
response. response.
Note that exclusivity has nothing to do with appearance number Note that exclusivity has nothing to do with appearance number
selection or seizing - instead, it is about call control selection or seizing - instead, it is about call control
operations that can be performed on a dialog. operations that can be performed on a dialog.
If the <exclusive> element is not present, it is assumed to be false. If the <exclusive> element is not present, it is assumed to be true.
5.2.3. The <joined-dialog> element 5.2.3. The <joined-dialog> element
The <joined-dialog> element, a child of the <dialog> element, is used The <joined-dialog> element, a child of the <dialog> element, is used
to convey dialog identifiers of any other dialogs which are joined to convey dialog identifiers of any other dialogs which are joined
(mixed or bridged) with the dialog. Only the UA which is the common (mixed or bridged) with the dialog. Only the UA which is the common
endpoint of the mixed dialogs (and thus controlling the mixing endpoint of the mixed dialogs (and thus controlling the mixing
operation) should include this element in publications to the operation) should include this element in publications to the
Appearance Agent. Note that this element should still be used even Appearance Agent. Note that this element should still be used even
when the Join header field was not used to join the dialogs. For when the Join header field was not used to join the dialogs. For
skipping to change at page 14, line 43 skipping to change at page 14, line 40
The presence of the 'shared' Event package parameter tells the The presence of the 'shared' Event package parameter tells the
Appearance Agent that this UA supports this specification. Appearance Agent that this UA supports this specification.
Upon initialization, the UA MUST subscribe to the dialog event Upon initialization, the UA MUST subscribe to the dialog event
package of the AOR and refresh the subscription per the SIP Events package of the AOR and refresh the subscription per the SIP Events
Framework. If the SUBSCRIBE request fails, then no Appearance Agent Framework. If the SUBSCRIBE request fails, then no Appearance Agent
may be present and this feature is not active for this AOR. The UA may be present and this feature is not active for this AOR. The UA
MAY periodically retry the subscription to see if conditions have MAY periodically retry the subscription to see if conditions have
changed at intervals no shorter than 4 hours. changed at intervals no shorter than 4 hours.
User Agents which implement call pickup, joining and bridging MUST Four hours was chosen to limit the subscription test to 6 per day
support sending an INVITE with Replaces [RFC3891] or Join [RFC3911]. per UA. Increading this interval would reduce this failure
The User Agent Client needs to include the to-tag and from-tag traffic but take longer for a newly activated Appearance Agent to
information in the Replaces or Join header so that the correct dialog be discovered.
will be matched by the User Agent Server per the rules in RFC 3891
and RFC 3911. All User Agents supporting INVITE MUST support User Agents which implement the shared appearances feature and call
receiving an INVITE with a Replaces [RFC3891] or a Join [RFC3911] pickup, joining and bridging MUST support sending an INVITE with
header field. Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to
include the to-tag and from-tag information in the Replaces or Join
header so that the correct dialog will be matched by the User Agent
Server per the rules in RFC 3891 and RFC 3911.
All User Agents which implement the shared appearances feature and
support INVITE MUST support receiving an INVITE with a Replaces
[RFC3891] or a Join [RFC3911] header field.
When publishing or notifying dialog package information, a UA MUST When publishing or notifying dialog package information, a UA MUST
include all dialog identification available at the time of include all dialog identification available at the time of
publication, with the exception that a UA may omit information if it publication, with the exception that a UA may omit information if it
wishes to prevent other UAs from joining or picking up a call. wishes to prevent other UAs from joining or picking up a call.
Dialog identification includes local and remote target URIs, call-id, Dialog identification includes local and remote target URIs, call-id,
to-tag, and from-tag. When calls are placed on hold, the to-tag, and from-tag. When calls are placed on hold, the
"+sip.rendering=no" feature tag MUST be included in dialog package "+sip.rendering=no" feature tag MUST be included in dialog package
notifications. notifications.
skipping to change at page 17, line 5 skipping to change at page 17, line 9
call (go back on hook). In this case, the UA MUST free up the call (go back on hook). In this case, the UA MUST free up the
appearance number by removing the event state with a PUBLISH as appearance number by removing the event state with a PUBLISH as
described in [RFC3903]. described in [RFC3903].
A UA SHOULD register against the AOR only if it is likely the UA will A UA SHOULD register against the AOR only if it is likely the UA will
be answering incoming calls. If the UA is mainly going to be be answering incoming calls. If the UA is mainly going to be
monitoring the status of the shared appearance group calls and monitoring the status of the shared appearance group calls and
picking or joining calls, the UA SHOULD only subscribe to the AOR and picking or joining calls, the UA SHOULD only subscribe to the AOR and
not register against the AOR. not register against the AOR.
All subscribed UAs will receive dialog package NOTIFYs of Trying All subscribed UAs will receive dialog package NOTIFYs of trying
state for incoming INVITEs. state for incoming INVITEs.
5.3.1. Appearance Numbers and Call Context 5.3.1. Appearance Numbers and Call Context
There are cases where two separate dialogs at a UA are not mixed but There are cases where two separate dialogs at a UA are not mixed but
share the same 'context'. That is, they relate to each other and share the same 'context'. That is, they relate to each other and
should not be treated the same as any other two dialogs within the should not be treated the same as any other two dialogs within the
group. One example of this is a 'consultation call' where a user group. One example of this is a 'consultation call' where a user
puts an existing dialog on hold, then calls another user, before puts an existing dialog on hold, then calls another user, before
switching back to the original dialog. Another case, described switching back to the original dialog. Another case, described
skipping to change at page 17, line 35 skipping to change at page 17, line 39
assigned publishes before sending the INVITE without an 'appearance' assigned publishes before sending the INVITE without an 'appearance'
element but with the 'shared' event package parameter present. If element but with the 'shared' event package parameter present. If
the Appearance Agent policy does not allow calls without an assigned the Appearance Agent policy does not allow calls without an assigned
appearance number, a 400 response is sent by the Appearance Agent and appearance number, a 400 response is sent by the Appearance Agent and
the UA will republish either selecting/seizing an appearance number the UA will republish either selecting/seizing an appearance number
or send the INVITE without publishing, in which case the Appearance or 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 Note that if an Appearance Agent rejects calls without an
appearance number, certain operations such as consultation calls, appearance number, certain operations such as consultation calls,
transfer, and music on hold may be impacted. transfer, and music on hold may be negatively impacted.
5.3.2. Appearance Numbers and Call Control 5.3.2. Appearance Numbers and Call Control
When an INVITE is generated to attempt to bridge or take a call (i.e. When an INVITE is generated to attempt to bridge or take a call (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 UA MUST first send a PUBLISH to in the shared appearance group), the UA MUST first send a PUBLISH to
the Appearance Agent. This PUBLISH will contain: the Appearance Agent. This PUBLISH will contain:
1. The appearance number of the joined or replaced call in the 1. The appearance number of the joined or replaced call in the
<appearance> element <appearance> element
skipping to change at page 35, line 19 skipping to change at page 35, line 19
Max-Forwards: 70 Max-Forwards: 70
Content-Type: application/dialog-info+xml Content-Type: application/dialog-info+xml
Event: dialog;shared Event: dialog;shared
Subscription-State: active;expires=2500 Subscription-State: active;expires=2500
Contact: <appearanceagent.example.com> Contact: <appearanceagent.example.com>
Content-Length: ... Content-Length: ...
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13" version="17"
state="partial" state="partial"
entity="sip:HelpDesk@example.com"> entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c" <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345" call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42" remote-tag="44BAD75D-E3128D42"
local-tag="7349dsfjkFD03s" local-tag="7349dsfjkFD03s"
direction="recipient"> direction="recipient">
<sa:appearance>1</sa:appearance> <sa:appearance>1</sa:appearance>
<state>confirmed</state> <state>confirmed</state>
<local> <local>
skipping to change at page 42, line 31 skipping to change at page 42, line 31
</dialog-info> </dialog-info>
11.5. Outgoing Call without using an Appearance Number 11.5. Outgoing Call without using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' dialog event parameter. appearance element but does have the 'shared' dialog event parameter.
As a result, the Appearance Agent knows the UA does not wish to use As a result, the Appearance Agent knows the UA does not wish to use
an appearance number for this call. If the Appearance Agent does not an appearance number for this call. If the Appearance Agent does not
wish to allow this, it would reject the PUBLISH with a 409 Conflict wish to allow this, it would reject the PUBLISH with a 400 response
response and the UA would know to re-PUBLISH selecting/seizing an and the UA would know to re-PUBLISH selecting/seizing an appearance
appearance number. number.
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 58, line 49 skipping to change at page 58, line 49
| | | |------ NOTIFY F16>| | | | |------ NOTIFY F16>|
| | | | | | | | | |
| | | NOTIFY is retransmitted | | | | NOTIFY is retransmitted |
Figure 11. Figure 11.
11.12. Appearance Seizure Contention Race Condition 11.12. Appearance Seizure Contention Race Condition
Bob and Alice both try to reserve appearance 2 by publishing at the Bob and Alice both try to reserve appearance 2 by publishing at the
same time. The Appearance Agent allocates the appearance to Bob by same time. The Appearance Agent allocates the appearance to Bob by
sending a 200 OK and denies it to Alice by sending a 409 Conflict. sending a 200 OK and denies it to Alice by sending a 400 response.
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 then attempts to reserve appearance 3 by publishing, which is Alice then attempts to reserve appearance 3 by publishing, which is
then accepted. 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 400 <| |
| | | | | | | | | |
| | |<-- NOTIFY F5<| | | | |<-- NOTIFY F5<| |
| | | | | | | | | |
| | |>F6 200 OK -->| | | | |>F6 200 OK -->| |
| | | |------- NOTIFY F7>| | | | |------- NOTIFY F7>|
| | | | | | | | | |
| | | |<F8 200 OK ------<| | | | |<F8 200 OK ------<|
| | | | | | | | | |
| |<------------------------------------- INVITE F9<| | |<------------------------------------- INVITE F9<|
| | | | | | | | | |
skipping to change at page 64, line 12 skipping to change at page 64, line 12
<target uri="sip:carol@ua3.example.com" /> <target uri="sip:carol@ua3.example.com" />
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition
Alice tries to seize appearance 2 at the same time appearance 2 is Alice tries to seize appearance 2 at the same time appearance 2 is
allocated to an incoming call. The Appearance Agent resolves the allocated to an incoming call. The Appearance Agent resolves the
conflict by sending a 409 Conflict to Alice. After the NOTIFY F6, conflict by sending a 400 to Alice. After the NOTIFY F6, Alice
Alice learns that the incoming call is using appearance 2. Alice learns that the incoming call is using appearance 2. Alice
republishes for appearance 3, which is accepted. Note that this republishes for appearance 3, which is accepted. Note that this
example shows the INVITE being received before the NOTIFY from the example shows the INVITE being received before the NOTIFY from the
Appearance Agent. Appearance Agent.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
|>-- INVITE F1>| | | | |>-- INVITE F1>| | | |
| |< - - - - - - - - - - - - - ->| | | |< - - - - - - - - - - - - - ->| |
| | | | | | | | | |
| | |>F2 PUBLISH ->| | | | |>F2 PUBLISH ->| |
| | | (appearance=2) | | | | (appearance=2) |
| | | | | | | | | |
| |>F3 INVITE (appearance=2) ---------------------->| | |>F3 INVITE (appearance=2) ---------------------->|
| | | | | | | | | |
| |>F4 INVITE | | | | |>F4 INVITE | | |
| |(appearance=2)>| | | | |(appearance=2)>| | |
| | |<---- F5 409 <| | | | |<---- F5 400 <| |
| | | | | | | | | |
| | |<-- NOTIFY F6<| | | | |<-- NOTIFY F6<| |
| | | | | | | | | |
| | |>F7 200 OK -->| | | | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>| | | | |------- NOTIFY F8>|
| | | | | | | | | |
| | | |<F9 200 OK ------<| | | | |<F9 200 OK ------<|
| | | | | | | | | |
| | |>F10 PUBLISH->| | | | |>F10 PUBLISH->| |
| | | (appearance=3) | | | | (appearance=3) |
skipping to change at page 68, line 51 skipping to change at page 68, line 51
[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-02 (work in progress), draft-ietf-sipcore-rfc3265bis-04 (work in progress),
August 2010. October 2011.
[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.
[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
skipping to change at page 69, line 28 skipping to change at page 69, line 28
(SIP) "Join" Header", RFC 3911, October 2004. (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[I-D.ietf-salud-alert-info-urns] [I-D.ietf-salud-alert-info-urns]
Liess, L., Alexeitsev, D., Jesske, R., Johnston, A., and Liess, L., Jesske, R., Johnston, A., Worley, D., and P.
A. Siddiqui, "Alert-Info URNs for the Session Initiation Kyzivat, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-ietf-salud-alert-info-urns-02 (work Protocol (SIP)", draft-ietf-salud-alert-info-urns-04 (work
in progress), May 2011. in progress), December 2011.
15.2. Informative References 15.2. Informative References
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008. Examples", BCP 144, RFC 5359, October 2008.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", (SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006. BCP 119, RFC 4579, August 2006.
[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.worley-service-example] [I-D.worley-service-example]
Worley, D., "Session Initiation Protocol Service Example Worley, D., "Session Initiation Protocol Service Example
-- Music on Hold", draft-worley-service-example-06 (work -- Music on Hold", draft-worley-service-example-08 (work
in progress), December 2010. in progress), August 2011.
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
 End of changes. 21 change blocks. 
43 lines changed or deleted 47 lines changed or added

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