draft-ietf-bliss-shared-appearances-14.txt   draft-ietf-bliss-shared-appearances-15.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: June 24, 2013 Sylantro Systems Corp Expires: July 20, 2013 Sylantro Systems Corp
December 21, 2012 January 16, 2013
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-14 draft-ietf-bliss-shared-appearances-15
Abstract Abstract
This document describes the requirements and implementation of a This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as shared appearances of an Address Protocol (SIP), it is referred to as shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. This of Record (AOR) since SIP does not have the concept of lines. This
feature is commonly offered in IP Centrex services and IP-PBX feature is commonly offered in IP Centrex services and IP-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 June 24, 2013. This Internet-Draft will expire on July 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 14, line 22 skipping to change at page 14, line 22
or have been replaced with this dialog. For example, a UA in the or have been replaced with this dialog. For example, a UA in the
group picking up a call on another UA by sending an INVITE with group picking up a call on another UA by sending an INVITE with
Replaces would include this element for the replacing dialog. Replaces would include this element for the replacing dialog.
Replaced dialogs will share the same appearance number. Replaced dialogs will share the same appearance number.
If the <replaced-dialog> element is not present, it is assumed that If the <replaced-dialog> element is not present, it is assumed that
the dialog has not replaced or is not to replace to any other dialog. the dialog has not replaced or is not to replace to any other dialog.
5.3. Shared Appearance User Agents 5.3. Shared Appearance User Agents
User Agents that support the Shared Appearance feature MUST support User Agents that support the Shared Appearance feature use the dialog
the dialog state package [RFC4235] with the shared appearance state package [RFC4235] with the shared appearance extensions and the
extensions and the 'shared' Event header field parameter defined in '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 use the dialog package extensions in Section 5.2 along
along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and PUBLISH
PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog
dialog event package include the 'shared' Event header field event package include the 'shared' Event header field parameter as
parameter as required by this specification. required by this specification.
The presence of the 'shared' Event header field parameter tells The presence of the 'shared' Event header field parameter tells
the Appearance Agent that the UA supports this specification. the Appearance Agent that the UA supports this specification.
Upon initialization, the UA MUST subscribe to the dialog event Upon initialization, the UA MUST subscribe to the dialog event
package of the AOR and refresh the subscription per the SIP Events package of the AOR and refresh the subscription per the SIP Events
Framework. If the SUBSCRIBE request fails, then no Appearance Agent Framework. 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.
skipping to change at page 15, line 14 skipping to change at page 15, line 13
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.
All User Agents which implement the shared appearances feature and All User Agents which implement the shared appearances feature and
support INVITE MUST support receiving an INVITE with a Replaces support INVITE MUST support receiving an INVITE with a Replaces
[RFC3891] or a Join [RFC3911] header field. [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
include all dialog identification available at the time of includes the largest set of dialog identification available at the
publication, with the exception that a UA may omit information if it time of publication, with the exception that a UA may omit
wishes to prevent other UAs from joining or picking up a call. information if it wishes to prevent other UAs from joining or picking
Dialog identification includes local and remote target URIs, call-id, up a call. Dialog identification includes local and remote target
to-tag, and from-tag. When placing calls on hold, use the URIs, call-id, to-tag, and from-tag. While this dialog
"+sip.rendering=no" feature tag to indicate this in dialog package identification information is optional in [RFC4235], it is essential
notifications. Using the full SDP session description instead forces in the shared appearance feature, allowing call control operations.
the endpoint to do a lot of extra parsing, unnecessarily complicating When placing calls on hold, use the "+sip.rendering=no" feature tag
the code and inviting errors. to indicate this in dialog package notifications. Using the full SDP
session description instead forces the endpoint to do a lot of extra
parsing, unnecessarily complicating the code and inviting errors.
The accurate rendering of the idle/active/alerting/hold state of The accurate rendering of the idle/active/alerting/hold state of
other UAs in the group is an important part of the shared other UAs in the group is an important part of the shared
appearance feature. appearance feature.
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
outbound call.
If the call is an emergency call, a UA MUST never wait for a If the call is an emergency call, a UA MUST never wait for a
confirmed seizure before sending an INVITE. Instead, the emergency confirmed seizure before sending an INVITE. Instead, the emergency
call MUST proceed without waiting for the PUBLISH transaction. call MUST proceed without waiting for the PUBLISH transaction.
Otherwise, in the following cases, before sending the INVITE, a UA If a UA requires a particular appearance number, the a UA MUST send a
MUST send a dialog package PUBLISH request and wait for a 2xx dialog package PUBLISH request and wait for a 2xx response before
response before proceeding: sending the INVITE. This is required in the following situations:
1. When the user seizes a particular appearance number for an 1. When the user seizes a particular appearance number for an
outgoing call (e.g. seizing the appearance and going "off-hook", outgoing call (e.g. seizing the appearance and going "off-hook",
if the UA's user interface uses this metaphor). if the UA's user interface uses this metaphor).
2. When the user has requested that an appearance number not be used 2. When the user has requested that an appearance number not be used
for an outgoing call (i.e. during a consultation call, a 'service for an outgoing call (i.e. during a consultation call, a 'service
media' call such as for music on hold media' call such as for music on hold
[I-D.worley-service-example] or for a call not considered part of [I-D.worley-service-example] or for a call not considered part of
the shared appearance group). the shared appearance group).
3. When the user has selected to join (or bridge) an existing call. 3. When the user has selected to join (or bridge) an existing call.
4. When the user has selected to replace (or take) an existing call. 4. When the user has selected to replace (or take) an existing call.
Note that when a UA seizes an appearance prior to establishment of a Note that when a UA seizes an appearance prior to establishment of a
dialog (#1 and #2 in above list), not all dialog information will be dialog (#1 and #2 in above list), not all dialog information will be
available. In particular, when a UA publishes an attempt to seize an available. In particular, when a UA publishes an attempt to seize an
appearance prior to knowing the destination URI, minimal or no dialog appearance prior to knowing the destination URI, minimal or no dialog
information may be available. For example, in some cases, only the information may be available. For example, in some cases, only the
local target URI for the call will be known and no dialog local target URI for the call will be known and no dialog
information. If the From tag and Call-ID were not present in the information. If the From tag and Call-ID were not present in the
skipping to change at page 16, line 51 skipping to change at page 17, line 10
identity) is not a useful replacement for the appearance number. The identity) is not a useful replacement for the appearance number. The
state of each appearance is also be rendered (idle, active, busy, state of each appearance is also be rendered (idle, active, busy,
joined, etc.). UAs can tell that a set of dialogs are joined joined, etc.). UAs can tell that a set of dialogs are joined
(bridged or mixed) together by the presence of one or more <joined- (bridged or mixed) together by the presence of one or more <joined-
dialog> elements containing other SIP dialog identifiers. Appearance dialog> elements containing other SIP dialog identifiers. Appearance
numbers of dialogs can be learned by dialog package notifications numbers of dialogs can be learned by dialog package notifications
containing the <appearance> element from the Appearance Agent or from containing the <appearance> element from the Appearance Agent or from
the 'appearance' Alert-Info parameter in an incoming INVITE. Should the 'appearance' Alert-Info parameter in an incoming INVITE. Should
they conflict, the dialog package notification takes precedence. they conflict, the dialog package notification takes precedence.
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
outbound call.
A user may select an appearance number but then abandon placing a A user may select an appearance number but then abandon placing a
call (go back on hook). In this case, the UA frees up the appearance call (go back on hook). In this case, the UA frees up the appearance
number by removing the event state with a PUBLISH as described in number by removing the event state with a PUBLISH as described in
[RFC3903]. A failure to do this will require extra unnecessary [RFC3903]. A failure to do this will require extra unnecessary
operations by the Appearance Agent, and also tie up appearance operations by the Appearance Agent, and also tie up appearance
numbers which could otherwise be used by other UAs in the appearance numbers which could otherwise be used by other UAs in the appearance
group. group.
A UA SHOULD register against the AOR only if it is likely the UA will A UA SHOULD register against the AOR only if it is likely the UA will
be answering incoming calls. If the UA is mainly going to be be answering incoming calls. If the UA is mainly going to be
 End of changes. 11 change blocks. 
31 lines changed or deleted 33 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/