draft-ietf-bliss-shared-appearances-11.txt   draft-ietf-bliss-shared-appearances-12.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 10, 2012 Sylantro Systems Corp Expires: January 14, 2013 Sylantro Systems Corp
June 8, 2012 July 13, 2012
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-11 draft-ietf-bliss-shared-appearances-12
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 46 skipping to change at page 1, line 46
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 10, 2012. This Internet-Draft will expire on January 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 4, line 15 skipping to change at page 4, line 15
11.9. Consultation Hold with Appearances . . . . . . . . . . . 52 11.9. Consultation Hold with Appearances . . . . . . . . . . . 52
11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 55 11.10. Joining or Bridging an Appearance . . . . . . . . . . . . 55
11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58
11.12. Appearance Seizure Contention Race Condition . . . . . . 59 11.12. Appearance Seizure Contention Race Condition . . . . . . 59
11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60
11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62
11.15. Appearance Seizure Incoming/Outgoing Contention Race 11.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . . 65 Condition . . . . . . . . . . . . . . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 66 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 66 13.1. SIP Event Header Field Parameter: shared . . . . . . . . 66
13.2. SIP Alert-Info Header Field Parameter: appearance . . . . 66 13.2. SIP Alert-Info Header Field Parameter: appearance . . . . 67
13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 67 13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 67
13.4. XML Schema Registration . . . . . . . . . . . . . . . . . 68 13.4. XML Schema Registration . . . . . . . . . . . . . . . . . 68
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
15.1. Normative References . . . . . . . . . . . . . . . . . . 69 15.1. Normative References . . . . . . . . . . . . . . . . . . 69
15.2. Informative References . . . . . . . . . . . . . . . . . 70 15.2. Informative References . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
skipping to change at page 9, line 15 skipping to change at page 9, line 15
REQ-15 The mechanism should support a way for a UA to seize a REQ-15 The mechanism should support a way for a UA to seize a
particular appearance number for outgoing requests prior to sending particular appearance number for outgoing requests prior to sending
the actual request. This is often called seizure. the actual request. This is often called seizure.
REQ-16 The mechanism should support a way for a UA to seize a REQ-16 The mechanism should support a way for a UA to seize a
particular appearance number and also send the request at the same particular appearance number and also send the request at the same
time. This is needed when an automatic ringdown feature (a telephone time. This is needed when an automatic ringdown feature (a telephone
configured to immediately dial a phone number when it goes off hook) configured to immediately dial a phone number when it goes off hook)
is combined with shared appearances - in this case, seizing the line is combined with shared appearances - in this case, seizing the line
is the same thing as dialing. is integrated with dialing.
4.2. Implementation 4.2. Implementation
This section non-normatively discusses the implementation of the This section non-normatively discusses the implementation of the
shared appearance feature. The normative description is in shared appearance feature. The normative description is in
Section 5. Many of the requirements for this service can be met Section 5. Many of the requirements for this service can be met
using standard SIP mechanisms such as: using standard SIP mechanisms such as:
- A SIP Forking Proxy and Registrar/Location Service meets REQ-1. - A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
needs to be contained in the INVITE, in addition to being delivered needs to be contained in the INVITE, in addition to being delivered
in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or
lost, a UA in the group might receive an incoming INVITE but might lost, a UA in the group might receive an incoming INVITE but might
not know which appearance number to render during alerting. not know which appearance number to render during alerting.
This specification defines an extension parameter for the Alert-Info This specification defines an extension parameter for the Alert-Info
header field in RFC 3261 to carry the appearance number: header field in RFC 3261 to carry the appearance number:
Alert-Info: <urn:alert:service:normal>;appearance=1 Alert-Info: <urn:alert:service:normal>;appearance=1
The next section discusses the operations used to implement parts of The following list describes the operation of the shared appearance
the shared appearance feature. feature.
1. A UA is configured with the AOR of a shared appearance group. It 1. A UA is configured with the AOR of a shared appearance group. It
registers against the AOR, then attempts a dialog state registers against the AOR, then attempts a dialog state
subscription to the AOR. If the subscription fails, loops back subscription to the AOR. If the subscription fails, loops back
to itself, or returns an error, it knows there is no State Agent, to itself, or returns an error, it knows there is no State Agent,
and hence no Appearance Agent and this feature is not and hence no Appearance Agent and this feature is not
implemented. implemented.
2. If the subscription receives a 200 OK, the UA knows there is a 2. If the subscription receives a 200 OK, the UA knows there is a
State Agent and that the feature is implemented. The UA then State Agent and that the feature is implemented. The UA then
follows the steps in this list. follows the steps in this list.
skipping to change at page 14, line 21 skipping to change at page 14, line 21
Replaces would include this element for the replacing dialog. Replaces would include this element for the replacing dialog.
Replaced dialogs will share the same appearance number. Replaced dialogs will share the same appearance number.
If the <replaced-dialog> element is not present, it is assumed that If the <replaced-dialog> element is not present, it is assumed that
the dialog has not replaced or is not to replace to any other dialog. the dialog has not replaced or is not to replace to any other dialog.
5.3. Shared Appearance User Agents 5.3. Shared Appearance User Agents
User Agents that support the Shared Appearance feature MUST support User Agents that support the Shared Appearance feature MUST support
the dialog state package [RFC4235] with the shared appearance the dialog state package [RFC4235] with the shared appearance
extensions and the 'shared' dialog event package parameter defined in extensions and the 'shared' Event header field parameter defined in
Section 13. Section 13.
User Agents MUST support the dialog package extensions in Section 5.2 User Agents MUST support the dialog package extensions in Section 5.2
along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and
PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the
dialog event package include the 'shared' Event header field dialog event package include the 'shared' Event header field
parameter as required by this specification. parameter as required by this specification.
The presence of the 'shared' Event package parameter tells the The presence of the 'shared' Event header field parameter tells
Appearance Agent that the UA supports this specification. the Appearance Agent that the UA supports this specification.
Upon initialization, the UA MUST subscribe to the dialog event Upon initialization, the UA MUST subscribe to the dialog event
package of the AOR and refresh the subscription per the SIP Events package of the AOR and refresh the subscription per the SIP Events
Framework. If the SUBSCRIBE request fails, then no Appearance Agent Framework. 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.
Four hours was chosen to limit the subscription test to 6 per day Four hours was chosen to limit the subscription test to 6 per day
per UA. Increading this interval would reduce this failure per UA. Increading this interval would reduce this failure
traffic but take longer for a newly activated Appearance Agent to traffic but take longer for a newly activated Appearance Agent to
be discovered. be discovered.
UAs can also use the presence of the 'shared' dialog event package UAs can also use the presence of the 'shared' Event header field
parameter in NOTIFYs to discover the presence of an Appearance Agent parameter in NOTIFYs to discover the presence of an Appearance Agent
for the AOR. for the AOR.
User Agents which implement the shared appearances feature and call User Agents which implement the shared appearances feature and call
pickup, joining and bridging MUST support sending an INVITE with pickup, joining and bridging MUST support sending an INVITE with
Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to Replaces [RFC3891] or Join [RFC3911]. The User Agent Client needs to
include the to-tag and from-tag information in the Replaces or Join include the to-tag and from-tag information in the Replaces or Join
header so that the correct dialog will be matched by the User Agent header so that the correct dialog will be matched by the User Agent
Server per the rules in RFC 3891 and RFC 3911. Server per the rules in RFC 3891 and RFC 3911.
skipping to change at page 17, line 37 skipping to change at page 17, line 37
switching back to the original dialog. Another case, described switching back to the original dialog. Another case, described
below, occurs during transfer operations, where for a transient below, occurs during transfer operations, where for a transient
period, a UA is involved in dialogs with two other UAs, but the period, a UA is involved in dialogs with two other UAs, but the
dialogs are related, and should not be treated as independent dialogs are related, and should not be treated as independent
dialogs. These cases are best handled by not assigning an appearance dialogs. These cases are best handled by not assigning an appearance
number to a newly-created dialog when it shares a context with an number to a newly-created dialog when it shares a context with an
existing dialog. But if the pre-existing dialog is terminated, its existing dialog. But if the pre-existing dialog is terminated, its
appearance number should be reassigned to the newly-created dialog. appearance number should be reassigned to the newly-created dialog.
A UA wanting to place a call but not have an appearance number A UA wanting to place a call but not have an appearance number
assigned publishes before sending the INVITE without an 'appearance' assigned sends a PUBLISH before sending the INVITE. The PUBLISH does
element but with the 'shared' event package parameter present. If not have an 'appearance' element present, but does have the 'shared'
the Appearance Agent policy does not allow calls without an assigned Event header field parameter present. If the Appearance Agent policy
appearance number, a 400 response is sent by the Appearance Agent and does not allow calls without an assigned appearance number, a 400
the UA will republish either selecting/seizing an appearance number (Bad Request) response is sent by the Appearance Agent and the UA
or send the INVITE without publishing, in which case the Appearance will republish either selecting/seizing an appearance number or send
Agent will assign one. the INVITE without publishing, in which case the Appearance Agent
will assign one.
Note that if an Appearance Agent rejects calls without an Note that if an Appearance Agent rejects calls without an
appearance number, certain operations such as consultation calls, appearance number, certain operations such as consultation calls,
transfer, and music on hold may be negatively impacted. transfer, and music on hold may be negatively impacted.
5.3.2. Appearance Numbers and Call Control 5.3.2. Appearance Numbers and Call Control
When an INVITE is generated to attempt to bridge or take a call (i.e. When an INVITE is generated to attempt to bridge or take a call (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
skipping to change at page 18, line 26 skipping to change at page 18, line 26
3. If the dialog is being replaced, the <replaced-dialog> element 3. If the dialog is being replaced, the <replaced-dialog> element
will contain the dialog information from the Replaces header will contain the dialog information from the Replaces header
field field
Note that this information is provided to the Appearance Agent so Note that this information is provided to the Appearance Agent so
that it can provide proper appearance assignment behavior. If the that it can provide proper appearance assignment behavior. If the
INVITE Join or Replaces was sent without publishing first, the INVITE Join or Replaces was sent without publishing first, the
Appearance Agent might assign a new appearance number to this Appearance Agent might assign a new appearance number to this
INVITE, which would be a mistake. With Join, the publication has INVITE, which would be a mistake. With Join, the publication has
the <joined-dialog> element to prevent the Appearance Agent from the <joined-dialog> element to prevent the Appearance Agent from
generating a 400 response due to the reuse of an appearance generating a 400 (Bad Request) response due to the reuse of an
number. For Replaces, the purpose of the <replaced-dialog> is to appearance number. For Replaces, the purpose of the <replaced-
prevent a race condition where the BYE could cause the appearance dialog> is to prevent a race condition where the BYE could cause
number to be released when it should stay with the replacing the appearance number to be released when it should stay with the
dialog. replacing dialog.
5.3.3. Appearance Numbers and Transfer 5.3.3. Appearance Numbers and Transfer
During a transfer operation, it is important that the appearance During a transfer operation, it is important that the appearance
number not change during the operation. Consider the example of number not change during the operation. Consider the example of
Alice, a member of an appearance group, who is talking to Carol, who Alice, a member of an appearance group, who is talking to Carol, who
is outside the appearance group. Carol transfers Alice to David, who is outside the appearance group. Carol transfers Alice to David, who
is also outside the appearance group. For example, if Alice is using is also outside the appearance group. For example, if Alice is using
appearance 3 for the session with Carol, the resulting session with appearance 3 for the session with Carol, the resulting session with
David should also use appearance number 3. Otherwise, an appearance David should also use appearance number 3. Otherwise, an appearance
skipping to change at page 19, line 18 skipping to change at page 19, line 18
header field. As a result, the Appearance Agent will have reused the header field. As a result, the Appearance Agent will have reused the
appearance number of the dialog with Carol, and this appearance appearance number of the dialog with Carol, and this appearance
number will continue to be used after the dialog with Carol has been number will continue to be used after the dialog with Carol has been
terminated. terminated.
5.4. Appearance Agent 5.4. Appearance Agent
An Appearance Agent defined in this specification MUST implement a An Appearance Agent defined in this specification MUST implement a
dialog package state agent for the UAs registered against the AOR. dialog package state agent for the UAs registered against the AOR.
The Appearance Agent MUST support the appearance dialog package The Appearance Agent MUST support the appearance dialog package
extensions defined in Section 5.2 and use the 'shared' event extensions defined in Section 5.2 and use the 'shared' Event header
parameter. The Appearance Agent MUST support publications and field parameter. The Appearance Agent MUST support publications and
subscriptions for this event package. subscriptions for this event package.
The Appearance Agent MUST have a way of discovering the state of all The Appearance Agent MUST have a way of discovering the state of all
dialogs associated with the AOR. If this information is not dialogs associated with the AOR. If this information is not
available from a call stateful proxy or B2BUA, the Appearance Agent available from a call stateful proxy or Back-to-Back User Agent
MAY use the registration event package [RFC3680] to learn of UAs (B2BUA), the Appearance Agent MAY use the registration event package
associated with the AOR and MAY subscribe to their dialog event [RFC3680] to learn of UAs associated with the AOR and MAY subscribe
state. Also, an Appearance Agent MAY subscribe to a UAs dialog event to their dialog event state. Also, an Appearance Agent MAY subscribe
state in order to reconstruct state. As a result, the registrar MUST to a UAs dialog event state in order to reconstruct state. As a
support the registration event package. Dialog package notifications result, the registrar MUST support the registration event package.
are recommended by RFC 4235 to "only contain information on the Dialog package notifications are recommended by RFC 4235 to "only
dialogs whose state or participation information has changed." This contain information on the dialogs whose state or participation
specification extends RFC 4235 as follows. The Appearance Agent information has changed." This specification extends RFC 4235 as
SHOULD send dialog event state notifications whenever the following follows. The Appearance Agent SHOULD send dialog event state
events happen to UAs in the AOR group: notifications whenever the following events happen to UAs in the AOR
group:
1. A call is received, placed, answered, or terminated. 1. A call is received, placed, answered, or terminated.
2. A call is placed on or off hold. 2. A call is placed on or off hold.
3. A call is joined or replaced. 3. A call is joined or replaced.
4. An appearance number is reserved or released. 4. An appearance number is reserved or released.
The Appearance Agent MUST allocate an appearance number for all The Appearance Agent MUST allocate an appearance number for all
incoming calls and send immediate notifications to the UAs subscribed incoming calls and send immediate notifications to the UAs subscribed
to the shared group AOR. A new appearance number is allocated except to the shared group AOR. A new appearance number is allocated except
for an incoming INVITE with a Join or Replaces header field. For for an incoming INVITE with a Join or Replaces header field. For
skipping to change at page 20, line 28 skipping to change at page 20, line 28
particular appearance number. particular appearance number.
Note that if the appearance group has appearance-unaware UAs Note that if the appearance group has appearance-unaware UAs
making calls, the Appearance Agent will still allocate appearance making calls, the Appearance Agent will still allocate appearance
numbers for INVITEs sent by those UAs. numbers for INVITEs sent by those UAs.
An Appearance Agent receiving a PUBLISH with an appearance number An Appearance Agent receiving a PUBLISH with an appearance number
checks to make sure the publication is valid. An appearance number checks to make sure the publication is valid. An appearance number
can be assigned to only one dialog unless there is a <joined-dialog> can be assigned to only one dialog unless there is a <joined-dialog>
or <replaced-dialog> element indicating that the dialog will be/has or <replaced-dialog> element indicating that the dialog will be/has
been replaced or joined. A 400 response is returned if the chosen been replaced or joined. A 400 (Bad Request) response is returned if
appearance number is invalid, and an immediate NOTIFY should be sent the chosen appearance number is invalid, and an immediate NOTIFY
to the UA containing full dialog event state. should be sent to the UA containing full dialog event state.
An Appearance Agent receiving a PUBLISH without an appearance number An Appearance Agent receiving a PUBLISH without an appearance number
but with the 'shared' event package parameter present interprets this but with the 'shared' Event header field parameter present interprets
as a request by the UA to not assign an appearance number. If the this as a request by the UA to not assign an appearance number. If
Appearance Agent policy does not allow this, a 400 response is the Appearance Agent policy does not allow this, a 400 (Bad Request)
returned. If policy does allow this, a 200 OK response is returned response is returned. If policy does allow this, a 200 OK response
and no appearance number is allocated. An Appearance Agent does not is returned and no appearance number is allocated. An Appearance
have to share this dialog information (i.e. send a NOTIFY) with other Agent does not have to share this dialog information (i.e. send a
UAs in the group as the information will not be rendered by the other NOTIFY) with other UAs in the group as the information will not be
UAs. rendered by the other UAs.
The Appearance Agent allocates an apperance number to a dialog from The Appearance Agent allocates an apperance number to a dialog from
the time the appearance is requested via a PUBLISH or from the the time the appearance is requested via a PUBLISH or from the
receipt of an INVITE, to the time when the last dialog associated receipt of an INVITE, to the time when the last dialog associated
with the appearance is terminated, including all dialogs which are with the appearance is terminated, including all dialogs which are
joined or replaced. During the early dialog state, the Appearance joined or replaced. During the early dialog state, the Appearance
Agent controls the rate of dialog state publication using the Expires Agent controls the rate of dialog state publication using the Expires
header field in 200 OK responses to PUBLISH requests. An interval of header field in 200 OK responses to PUBLISH requests. An interval of
3 minutes is RECOMMENDED. After the dialog associated with the 3 minutes is RECOMMENDED. After the dialog associated with the
publication has been confirmed, the expiration of the publication publication has been confirmed, the expiration of the publication
skipping to change at page 24, line 38 skipping to change at page 24, line 38
The following guidelines suggest how the appearance number should be The following guidelines suggest how the appearance number should be
handled in three typical user interface implementations. handled in three typical user interface implementations.
8.1.1. Single Appearance UAs 8.1.1. Single Appearance UAs
These devices are constrained by only having the capability of These devices are constrained by only having the capability of
displaying status indications for a single appearance. The UA should displaying status indications for a single appearance. The UA should
still send messages annotated with appearance number "1". Any call still send messages annotated with appearance number "1". Any call
indications for appearances other than for number "1" should be indications for appearances other than for number "1" should be
rejected with a 486 or 480 response. rejected with a 486 or 480 response. Note that this means that a
single appearance UA cannot answer its own call to the shared AOR,
since this call would use a second appearance number.
8.1.2. Dual Appearance UAs 8.1.2. Dual Appearance UAs
These devices are essentially single appearance phones that implement These devices are essentially single appearance phones that implement
call waiting. They have a very simple user interface that allows call waiting. They have a very simple user interface that allows
them to switch between two appearances (toggle or flash hook) and them to switch between two appearances (toggle or flash hook) and
perhaps audible tones to indicate the status of the other appearance. perhaps audible tones to indicate the status of the other appearance.
Only appearance numbers "1" and "2" will be used by these UAs. Only appearance numbers "1" and "2" will be used by these UAs.
8.1.3. Shared Appearance UAs with Fixed Appearance Number 8.1.3. Shared Appearance UAs with Fixed Appearance Number
skipping to change at page 26, line 46 skipping to change at page 26, line 46
First, a UA which does not support dialog events or the shared First, a UA which does not support dialog events or the shared
appearance feature will be discussed. Then, a UA which does support appearance feature will be discussed. Then, a UA which does support
dialog events but not the shared appearance feature will be dialog events but not the shared appearance feature will be
discussed. discussed.
9.1. Appearance Assignment 9.1. Appearance Assignment
A UA that has no knowledge of appearances must will only have A UA that has no knowledge of appearances must will only have
appearance numbers for outgoing calls if assigned by the Appearance appearance numbers for outgoing calls if assigned by the Appearance
Agent. If the non-shared appearance UA does not support Join or Agent. If the non-shared appearance UA does not support Join or
Replaces, all dialogs could be marked "exclusive" to indicate that Replaces, all dialogs SHOULD be marked "exclusive" to indicate that
these options are not available. these options are not available. Marking these dialogs "exclusive"
provides a better user experience and avoids extra SIP messaging
failures.
9.2. Appearance Release 9.2. Appearance Release
In all cases the Appearance Agent must be aware of dialog lifetime to In all cases the Appearance Agent must be aware of 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
non-end-to-end-encrypted INVITE and re-INVITE messages and added to non-end-to-end-encrypted INVITE and re-INVITE messages and added to
the dialog information conveyed to other UAs. the dialog information conveyed to other UAs.
9.3. UAs Supporting Dialog Events but Not Shared Appearance 9.3. UAs Supporting Dialog Events but Not Shared Appearance
Interoperability with UAs which support dialog events but not the Interoperability with UAs 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.
The Appearance Agent can include appearance information in NOTIFYs - The Appearance Agent SHOULD still include appearance information in
this UA will simply ignore this extra information. This type of UA NOTIFYs - this UA will simply ignore this extra information. This
will ignore appearance number limitations and may attempt to Join or type of UA will also ignore appearance number limitations and may
Replace dialogs marked exclusive. As a result, the Proxy or UAs need attempt to Join or Replace dialogs marked exclusive. As a result,
to reject such requests or the dialogs will get joined or taken. the Proxy or UAs need to reject such requests or the dialogs will get
joined or taken.
10. Provisioning Considerations 10. Provisioning Considerations
UAs can automatically discover if this feature is active for an AOR UAs can automatically discover if this feature is active for an AOR
by looking for the 'shared' Event header parameter in a response to a by looking for the 'shared' Event header field parameter in a
dialog package SUBSCRIBE to the AOR, so no provisioning for this is response to a dialog package SUBSCRIBE to the AOR, so no provisioning
needed. for this is needed.
The registrar will need to be provisioned to accept either first or The registrar will need to be provisioned to accept either first or
third party registrations for the shared AOR. First party third party registrations for the shared AOR. First party
registration means the To and From URIs in the REGISTER request are registration means the To and From URIs in the REGISTER request are
the shared AOR URI. Third party registration means the To URI is the the shared AOR URI. Third party registration means the To URI is the
shared AOR URI and the From URI is a different AOR, perhaps that of shared AOR URI and the From URI is a different AOR, perhaps that of
the individual user. Either the credentials of the shared AOR or the the individual user. Either the credentials of the shared AOR or the
user MUST be accepted by the registrar and the Appearance Agent, user MUST be accepted by the registrar and the Appearance Agent,
depending on the authorization policy in place for the domain. depending on the authorization policy in place for the domain.
skipping to change at page 42, line 31 skipping to change at page 42, line 31
</identity> </identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
11.5. Outgoing Call without using an Appearance Number 11.5. Outgoing Call without using an Appearance Number
In this scenario, Bob's UA sends out a dialog event PUBLISH with In this scenario, Bob's UA sends out a dialog event PUBLISH with
state (trying) indicating that he does not want to utilize an state (trying) indicating that he does not want to utilize an
appearance number for this dialog. The PUBLISH does not have an appearance number for this dialog. The PUBLISH does not have an
appearance element but does have the 'shared' dialog event parameter. appearance element but does have the 'shared' Event header field
As a result, the Appearance Agent knows the UA does not wish to use parameter. As a result, the Appearance Agent knows the UA does not
an appearance number for this call. If the Appearance Agent does not wish to use an appearance number for this call. If the Appearance
wish to allow this, it would reject the PUBLISH with a 400 response Agent does not wish to allow this, it would reject the PUBLISH with a
and the UA would know to re-PUBLISH selecting/seizing an appearance 400 (Bad Request) response and the UA would know to re-PUBLISH
number. selecting/seizing an appearance 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 52, line 33 skipping to change at page 52, line 33
</dialog-info> </dialog-info>
11.9. Consultation Hold with Appearances 11.9. Consultation Hold with Appearances
In this scenario, Bob has a call with Carol. Bob makes a In this scenario, Bob has a call with Carol. Bob makes a
consultation call to Alice by putting Carol on hold and calling consultation call to Alice by putting Carol on hold and calling
Alice. Bob's UA chooses not to have an appearance number for the Alice. Bob's UA chooses not to have an appearance number for the
call to Alice since it is treating it as part of the call to Carol. call to Alice since it is treating it as part of the call to Carol.
He indicates this in the PUBLISH F32 which contains the 'shared' He indicates this in the PUBLISH F32 which contains the 'shared'
Event parameter but no <appearance> element. The PUBLISH is sent Event header field parameter but no <appearance> element. The
before the INVITE to Alice to ensure no appearance number is assigned PUBLISH is sent before the INVITE to Alice to ensure no appearance
by the Appearance Agent. Finally, Bob hangs up with Alice and number is assigned by the Appearance Agent. Finally, Bob hangs up
resumes the call with Carol. Dialog notifications of the with Alice and resumes the call with Carol. Dialog notifications of
consultation call are not shown, as they are not used. the consultation call are not shown, as they are not used.
Note that if Carol hangs up while Bob is consulting with Alice, Bob Note that if Carol hangs up while Bob is consulting with Alice, Bob
can decide if he wants to reuse the appearance number used with Carol can decide if he wants to reuse the appearance number used with Carol
for the call with Alice. If not, Bob publishes the termination of for the call with Alice. If not, Bob publishes the termination of
the dialog with Carol and the Appearance Agent will re-allocate the the dialog with Carol and the Appearance Agent will re-allocate the
appearance. If he wants to keep the appearance, Bob will publish the appearance. If he wants to keep the appearance, Bob will publish the
termination of the dialog with Carol and also publish the appearance termination of the dialog with Carol and also publish the appearance
with the dialog with Alice. This will result in Bob keeping the with the dialog with Alice. This will result in Bob keeping the
appearance number until he reports the dialog with Alice terminated. appearance number until he reports the dialog with Alice terminated.
skipping to change at page 59, line 9 skipping to change at page 59, line 9
| | | |------ 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 400 response. sending a 200 OK and denies it to Alice by sending a 400 (Bad
After the NOTIFY F5, Alice learns that Bob is using appearance 2. Request) response. After the NOTIFY F5, Alice learns that Bob is
Alice then attempts to reserve appearance 3 by publishing, which is using appearance 2. Alice then attempts to reserve appearance 3 by
then accepted. publishing, which is then accepted.
Carol Proxy Alice Appearance Agent Bob Carol Proxy Alice Appearance Agent Bob
| | | | | | | | | |
| | | |<----- PUBLISH F1<| | | | |<----- PUBLISH F1<|
| | | | (appearance=2) | | | | (appearance=2)
| | |>F2 PUBLISH ->| | | | |>F2 PUBLISH ->| |
| | | (appearance=2) | | | | (appearance=2) |
| | | | | | | | | |
| | | |>F3 200 OK ------>| | | | |>F3 200 OK ------>|
| | |<---- F4 400 <| | | | |<---- F4 400 <| |
skipping to change at page 65, line 9 skipping to change at page 65, line 9
<remote> <remote>
<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 400 to Alice. After the NOTIFY F6, Alice conflict by sending a 400 (Bad Request) to Alice. After the NOTIFY
learns that the incoming call is using appearance 2. Alice F6, 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 ->| |
skipping to change at page 66, line 13 skipping to change at page 66, line 13
Figure 15. Figure 15.
12. Security Considerations 12. Security Considerations
Since multiple line appearance features are implemented using Since multiple line appearance features are implemented using
semantics provided by [RFC3261], Event Package for Dialog State as semantics provided by [RFC3261], Event Package for Dialog State as
define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis], define in , and Event Notification [I-D.ietf-sipcore-rfc3265bis],
[RFC3903], security considerations in these documents apply to this [RFC3903], security considerations in these documents apply to this
draft as well. draft as well.
NOTIFY or PUBLISH message bodies that provide the dialog state To provide privacy, NOTIFY or PUBLISH message bodies that provide the
information and the dialog identifiers MAY be encrypted end-to-end dialog state information and the dialog identifiers MAY be encrypted
using the standard mechanisms. All SUBSCRIBES and PUBLISHES between end-to-end using the standard mechanisms such as S/MIME described in
the UAs and the Appearance Agent MUST be authenticated. [RFC3261]. All SUBSCRIBES and PUBLISHES between the UAs and the
Appearance Agent MUST be authenticated. Without proper
authentication, a third party could learn information about dialogs
associated with a AOR and could try to use this information to hijack
or manipulate those dialogs using SIP call control primitives.
All INVITEs with Replaces or Join header fields MUST only be accepted All INVITEs with Replaces or Join header fields MUST only be accepted
if the peer requesting dialog replacement or joining has been if the peer requesting dialog replacement or joining has been
properly authenticated using a standard SIP mechanism (such as Digest properly authenticated using a standard SIP mechanism (such as Digest
or S/MIME), and authorized to request a replacement. or S/MIME), and authorized to request a replacement. Otherwise, a
third party could disrupt or hijack existing dialogs in the
appearance group.
For an emergency call, a UA MUST never wait for a confirmed seizure For an emergency call, a UA MUST never wait for a confirmed seizure
of an appearance before sending an INVITE. Instead, the emergency of an appearance before sending an INVITE. Instead, the emergency
call MUST proceed regardless of the status of the PUBLISH call MUST proceed regardless of the status of the PUBLISH
transaction. transaction.
13. IANA Considerations 13. IANA Considerations
This section registers the SIP event package parameter 'shared', the This section registers the SIP Event header field parameter 'shared',
SIP Alert-Info header field parameter "appearance" and the XML the SIP Alert-Info header field parameter 'appearance' and the XML
namespace extensions to the SIP Dialog Package. namespace extensions to the SIP Dialog Package.
13.1. SIP Event Package Parameter: shared 13.1. SIP Event Header Field Parameter: shared
This specification defines a new event parameter 'shared' for the This document defines the 'shared' header field parameter to the
Dialog Package. When used in a NOTIFY, it indicates that the Event header field in the "SIP Header Field Parameters and Parameter
notifier supports the shared appearance feature. When used in a Values" registry defined by [RFC3968]
PUBLISH, it indicates that the publisher has explicit appearance Predefined
information contained in the message body. If not present in a Header Field Parameter Name Values Reference
PUBLISH, the Appearance Agent MAY assign an appearance number to any ---------------------------- ------------------ ---------- ---------
new dialogs in the message body. Event shared No [RFC-to-be]
13.2. SIP Alert-Info Header Field Parameter: appearance 13.2. SIP Alert-Info Header Field Parameter: appearance
This document defines the 'appearance' parameter to the Alert-Info This document defines the 'appearance' parameter to the Alert-Info
header in the SIP Parameters registry. header in the SIP Parameters registry.
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------- --------------- --------- --------- ---------------------- --------------- --------- ---------
Alert-Info appearance No [RFC3261] Alert-Info appearance No [RFC-to-be]
13.3. URN Sub-Namespace Registration: sa-dialog-info 13.3. URN Sub-Namespace Registration: sa-dialog-info
This section registers a new XML namespace per the procedures This section registers a new XML namespace per the procedures
in [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.b.johnston@gmail.com> Alan Johnston <alan.b.johnston@gmail.com>
skipping to change at page 70, line 34 skipping to change at page 70, line 34
Alan Johnston (editor) Alan Johnston (editor)
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Mohsen Soroushnejad Mohsen Soroushnejad
Sylantro Systems Corp Sylantro Systems Corp
Email: mohsen.soroush@sylantro.com Email: msoroush@gmail.com
Venkatesh Venkataramanan Venkatesh Venkataramanan
Sylantro Systems Corp Sylantro Systems Corp
Email: vvenkatar@gmail.com Email: vvenkatar@gmail.com
 End of changes. 30 change blocks. 
94 lines changed or deleted 107 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/