draft-ietf-bliss-shared-appearances-09.txt   draft-ietf-bliss-shared-appearances-10.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: July 2, 2012 Sylantro Systems Corp Expires: November 5, 2012 Sylantro Systems Corp
December 30, 2011 May 4, 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-09 draft-ietf-bliss-shared-appearances-10
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 July 2, 2012. This Internet-Draft will expire on November 5, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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 3, line 35 skipping to change at page 3, line 35
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 . . . . . . . . . . . . . . . . . . . . 19 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 . . 25
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
8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26
9. Interoperability with non-Shared Appearance UAs . . . . . . . 26 9. Interoperability with non-Shared Appearance UAs . . . . . . . 26
9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26
9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27
9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27
10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27
11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28
11.1. Registration and Subscription . . . . . . . . . . . . . . 28 11.1. Registration and Subscription . . . . . . . . . . . . . . 28
11.2. Appearance Selection for Incoming Call . . . . . . . . . 32 11.2. Appearance Selection for Incoming Call . . . . . . . . . 32
11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35
11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 38 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . . 38
11.5. Outgoing Call without using an Appearance Number . . . . 42 11.5. Outgoing Call without using an Appearance Number . . . . 42
11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44
11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 45 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . . 45
11.8. Calls between UAs within the Group . . . . . . . . . . . 49 11.8. Calls between UAs within the Group . . . . . . . . . . . 50
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 . . . . . . . 57 11.11. Appearance Allocation - Loss of Appearance . . . . . . . 58
11.12. Appearance Seizure Contention Race Condition . . . . . . 58 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 . . . . . . . . 61 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 . . . . . . . . . . . . . . . . . . . . . . . . 64 Condition . . . . . . . . . . . . . . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 66 13.1. SIP Event Package Parameter: shared . . . . . . . . . . . 66
13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 67 13.2. URN Sub-Namespace Registration: sa-dialog-info . . . . . 67
13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 67 13.3. XML Schema Registration . . . . . . . . . . . . . . . . . 67
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
15.1. Normative References . . . . . . . . . . . . . . . . . . 68 15.1. Normative References . . . . . . . . . . . . . . . . . . 68
15.2. Informative References . . . . . . . . . . . . . . . . . 69 15.2. Informative References . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
skipping to change at page 12, line 52 skipping to change at page 12, line 52
Appearance Agent. In particular, if the UA sent a request within the Appearance Agent. In particular, if the UA sent a request within the
described dialog, the To header field URI would match the <remote> described dialog, the To header field URI would match the <remote>
<identity> value and the to-tag parameter would match the remote-tag <identity> value and the to-tag parameter would match the remote-tag
attribute. Similarly, the From header field URI would match the attribute. Similarly, the From header field URI would match the
<local> <identity> value and the from-tag parameter would match the <local> <identity> value and the from-tag parameter would match the
local-tag attribute. local-tag attribute.
5.2.2. The <exclusive> element 5.2.2. The <exclusive> element
The <exclusive> element, a child of the <dialog> element, is a The <exclusive> element, a child of the <dialog> element, is a
boolean, which when true, indicates that the UA is willing to accept boolean, which when true, indicates that the UA is not willing to
an INVITE with a Join or Replaces header field targeted to the dialog accept an INVITE with a Join or Replaces header field targeted to the
described by the <dialog> element that is the parent of the dialog described by the <dialog> element that is the parent of the
<exclusive> element. For example, some shared appearance systems <exclusive> element. For example, some shared appearance systems
only allow call pickup when the call is on hold. In this case, the only allow call pickup when the call is on hold. In this case, the
<exclusive> element should be set to "true" when the call is held and <exclusive> element should be set to "false" when the call is held
"false" when the call is not held, rather than having the "exclusive" and "true" when the call is not held, rather than having the
value implied by the hold state. "exclusive" value implied by the hold state.
It is important to note that this element is a hint. In order to It is important to note that this element is a hint. In order to
prevent another UA from taking or joining a call, a UA can, in prevent another UA from taking or joining a call, a UA can, in
addition to setting the <exclusive> tag, not report full dialog addition to setting the <exclusive> tag, not report full dialog
information to the Appearance Agent. Not having the full dialog information to the Appearance Agent. Not having the full dialog
information (Call-ID, remote-tag, and local-tag) prevents another UA information (Call-ID, remote-tag, and local-tag) prevents another UA
from constructing a Join or Replaces header field. Although a UA may from constructing a Join or Replaces header field. Although a UA may
set exclusive to true, the UA must still be ready to reject an INVITE set exclusive to true, the UA must still be ready to reject an INVITE
Join relating to this dialog. If these dialog identifiers have Join relating to this dialog. If these dialog identifiers have
already been shared with the Appearance Agent, the UA could send an already been shared with the Appearance Agent, the UA could send an
skipping to change at page 13, line 33 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 true. If the <exclusive> element is not present, it is assumed to be false.
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 17, line 12 skipping to change at page 17, line 12
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.
A UA MUST NOT insert an 'appearance' parameter into an Alert-Info
header field in an INVITE or other request.
The Appearance Agent is solely responsible for doing this.
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
below, occurs during transfer operations, where for a transient below, occurs during transfer operations, where for a transient
period, a UA is invovled 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 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
skipping to change at page 20, line 50 skipping to change at page 20, line 51
state has no effect on the appearance allocation. If the publication state has no effect on the appearance allocation. If the publication
contains no dialog state information, the Appearance Agent MUST contains no dialog state information, the Appearance Agent MUST
reserve the appearance number for the UA but can not assign the reserve the appearance number for the UA but can not assign the
appearance to any particular dialog of the UA. When the publication appearance to any particular dialog of the UA. When the publication
state is updated with any dialog information, the appearance number state is updated with any dialog information, the appearance number
can then be assigned to the particular dialog. A UA which has been can then be assigned to the particular dialog. A UA which has been
allocated an appearance number using a PUBLISH MAY free up the allocated an appearance number using a PUBLISH MAY 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].
If an INVITE is sent by a member of the group to the shared AOR (i.e.
they call their own AOR), the Appearance Agent MUST assign two
appearance numbers. The first appearance number will be the one
selected or assigned to the outgoing INVITE. The second appearance
number will be another one assigned by the Appearance Agent for the
INVITE as it is forked back to the members of the group.
The is to preserve a common behavior in legacy systems.
If an INVITE is sent by a member of the group using the shared AOR or If an INVITE is sent by a member of the group using the shared AOR or
sent to the shared AOR and no appearance number is available, the sent to the shared AOR and no appearance number is available, the
proxy MAY reject the INVITE with a 403 Forbidden response code. proxy MAY reject the INVITE with a 403 Forbidden response code.
Appearance numbers are only used for dialogs in which one UA Appearance numbers are only used for dialogs in which one or more UAs
associated with the group AOR is a participant. If an incoming associated with the group AOR is a participant. If an incoming
INVITE to the group AOR is forwarded to another AOR, the appearance INVITE to the group AOR is forwarded to another AOR, the appearance
number is immediately freed up and can be assigned to another dialog. number is immediately freed up and can be assigned to another dialog.
6. XML Schema Definition 6. XML Schema Definition
The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive'
elements are defined within a new XML namespace URI. This namespace elements are defined within a new XML namespace URI. This namespace
is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these
elements is: elements is:
skipping to change at page 23, line 18 skipping to change at page 23, line 18
parameter to the Alert-Info header field, and to also allow proxies parameter to the Alert-Info header field, and to also allow proxies
to modify or delete the Alert-Info header field. to modify or delete the Alert-Info header field.
The changes to RFC 3261 ABNF are: The changes to RFC 3261 ABNF are:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI alert-param = LAQUOT absoluteURI RAQUOT *( SEMI
(generic-param / appearance-param) ) (generic-param / appearance-param) )
appearance-param = "appearance" EQUAL 1*DIGIT appearance-param = "appearance" EQUAL 1*DIGIT
A proxy inserting an 'appearance' Alert-Info parameter follows normal A proxy inserting an 'appearance' Alert-Info parameter follows normal
policies Alert-Info policies. If an Alert-Info is already present, Alert-Info policies. To indicate the appearance number for this
the proxy either removes the Alert-Info if it is not trusted, or adds dialog, the proxy adds the Alert-Info header field with the
the 'appearance' parameter to the Alert-Info header field. If an 'appearance' parameter to the INVITE. If an Alert-Info is already
appearance number parameter is already present (associated with present, the proxy adds the 'appearance' parameter to the Alert-Info
another AOR or by mistake), the value is rewritten adding the new header field. If an appearance number parameter is already present
appearance number. There MUST NOT be more than one appearance (associated with another AOR or by mistake), the value is rewritten
parameter in an Alert-Info header field. adding the new appearance number. There MUST NOT be more than one
appearance parameter in an Alert-Info header field.
If no special ringtone is desired, a normal ringtone should be If no special ringtone is desired, a normal ringtone should be
indicated using the urn:alert:service:normal in the Alert-Info, as indicated using the urn:alert:service:normal in the Alert-Info, as
per [I-D.ietf-salud-alert-info-urns]. The appearance number present per [I-D.ietf-salud-alert-info-urns]. The appearance number present
in an Alert-Info header field SHOULD be rendered by the UA to the in an Alert-Info header field SHOULD be rendered by the UA to the
user, following the guidelines in Section 5.3. If the INVITE is user, following the guidelines in Section 5.3. If the INVITE is
forwarded to another AOR, the appearance parameter in the Alert-Info forwarded to another AOR, the appearance parameter in the Alert-Info
SHOULD be removed before forwarding outside the group. SHOULD be removed before forwarding outside the group.
The determination as to what value to use in the appearance parameter The determination as to what value to use in the appearance parameter
skipping to change at page 28, line 41 skipping to change at page 28, line 41
Bob and Alice are in an appearance group identified by the shared Bob and Alice are in an appearance group identified by the shared
appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact
sip:bob@ua2.example.com. Alice REGISTERs with contact sip:bob@ua2.example.com. Alice REGISTERs with contact
sip:alice@ua1.example.com. sip:alice@ua1.example.com.
User Agents for Alice and Bob subscribe to the dialog package for the User Agents for Alice and Bob subscribe to the dialog package for the
appearance AOR and publish dialog state to the Appearance Agent. appearance AOR and publish dialog state to the Appearance Agent.
Message exchanges between the Registrar, Appearance Agent, Alice, and Message exchanges between the Registrar, Appearance Agent, Alice, and
Bob are shown below. The call flow examples below do not show the Bob are shown below. The call flow examples below do not show the
authentication of subscriptions, publications, and notifications. It authentication of subscriptions, publications, and notifications. It
should be noted that for security purposes, all subscriptions must be should be noted that for security purposes, all publications and
authorized before the SUBSCRIBE is accepted. subscriptions must be authorized before the SUBSCRIBE is accepted.
Also note that registrations and subscriptions must all be refreshed Also note that registrations and subscriptions must all be refreshed
by Alice at intervals determined by the expiration intervals returned by Alice at intervals determined by the expiration intervals returned
by the Registrar or Appearance Agent. by the Registrar or Appearance Agent.
Registrar Appearance Agent Alice Bob Registrar Appearance Agent Alice Bob
| | | | | | | |
| | | | | | | |
|<--------------------------- REGISTER F1<| | |<--------------------------- REGISTER F1<| |
| | | | | | | |
skipping to change at page 39, line 4 skipping to change at page 39, line 4
</dialog> </dialog>
</dialog-info> </dialog-info>
11.4. Outgoing Call with Appearance Seizure 11.4. Outgoing Call with Appearance Seizure
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) selecting/seizing an appearance number before sending state (trying) selecting/seizing an appearance number before sending
the INVITE. After receiving the 200 OK from the Appearance Agent the INVITE. After receiving the 200 OK from the Appearance Agent
confirming the appearance number, Bob's UA sends the INVITE to Carol confirming the appearance number, Bob's UA sends the INVITE to Carol
and establishes a session. For brevity, details of some of the and establishes a session. For brevity, details of some of the
messages are not included in the message flows. messages are not included in the message flows. Bob's UA puts as
much of the dialog information from F7 as can be determined in
advance. In this case, the minimum of the Contact URI is included
which allows the Appearance Agent to correlate the INVITE with the
PUBLISH.
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 24 skipping to change at page 52, line 30
<target uri="sip:bob@ua2.example.com" /> <target uri="sip:bob@ua2.example.com" />
</remote> </remote>
</dialog> </dialog>
</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 chooses not to have an appearance number for the call to Alice. Bob's UA chooses not to have an appearance number for the
Alice since he is treating it as part of the call to Carol. He call to Alice since it is treating it as part of the call to Carol.
indicates this in his PUBLISH F32 which contains the 'shared' Event He indicates this in the PUBLISH F32 which contains the 'shared'
parameter but no <appearance> element. The PUBLISH is sent before Event parameter but no <appearance> element. The PUBLISH is sent
the INVITE to Alice to ensure no appearance number is assigned by the before the INVITE to Alice to ensure no appearance number is assigned
Appearance Agent. Finally, Bob hangs up with Alice and resumes the by the Appearance Agent. Finally, Bob hangs up with Alice and
call with Carol. Dialog notifications of the consultation call are resumes the call with Carol. Dialog notifications of the
not shown, as they are not used. 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 66, line 7 skipping to change at page 66, line 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 NOTIFY or PUBLISH message bodies that provide the dialog state
information and the dialog identifiers MAY be encrypted end-to-end information and the dialog identifiers MAY be encrypted end-to-end
using the standard mechanisms. All SUBSCRIBES between the UA's and using the standard mechanisms. All SUBSCRIBES and PUBLISHES between
the Appearance Agent MUST be authenticated. the UAs and the Appearance Agent MUST be authenticated.
All INVITEs with Replaces or Join header fields MUST only be accepted
if the peer requesting dialog replacement or joining has been
properly authenticated using a standard SIP mechanism (such as Digest
or S/MIME), and authorized to request a replacement.
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 package parameter 'shared', the
SIP Alert-Info header field parameter "appearance" and the XML SIP Alert-Info header field parameter "appearance" and the XML
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-04 (work in progress), draft-ietf-sipcore-rfc3265bis-09 (work in progress),
October 2011. April 2012.
[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 30 skipping to change at page 69, line 30
[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., Jesske, R., Johnston, A., Worley, D., and P. Liess, L., Jesske, R., Johnston, A., Worley, D., and P.
Kyzivat, "Alert-Info URNs for the Session Initiation Kyzivat, "Alert-Info URNs for the Session Initiation
Protocol (SIP)", draft-ietf-salud-alert-info-urns-04 (work Protocol (SIP)", draft-ietf-salud-alert-info-urns-06 (work
in progress), December 2011. in progress), April 2012.
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-08 (work -- Music on Hold", draft-worley-service-example-09 (work
in progress), August 2011. in progress), February 2012.
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. 24 change blocks. 
47 lines changed or deleted 72 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/