diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7463.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7463.txt')
| -rw-r--r-- | doc/rfc/rfc7463.txt | 4034 |
1 files changed, 4034 insertions, 0 deletions
diff --git a/doc/rfc/rfc7463.txt b/doc/rfc/rfc7463.txt new file mode 100644 index 0000000..36c27cc --- /dev/null +++ b/doc/rfc/rfc7463.txt @@ -0,0 +1,4034 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Johnston, Ed. +Request for Comments: 7463 Avaya +Updates: 3261, 4235 M. Soroushnejad, Ed. +Category: Standards Track V. Venkataramanan +ISSN: 2070-1721 Sylantro Systems Corp. + March 2015 + + + Shared Appearances of a Session Initiation Protocol (SIP) + Address of Record (AOR) + +Abstract + + This document describes the requirements and implementation of a + group telephony feature commonly known as Bridged Line Appearance + (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line + Appearance (SCA). When implemented using the Session Initiation + Protocol (SIP), it is referred to as shared appearances of an Address + of Record (AOR) since SIP does not have the concept of lines. This + feature is commonly offered in IP Centrex services and IP Private + Branch Exchange (IPBX) offerings and is likely to be implemented on + SIP IP telephones and SIP feature servers used in a business + environment. This feature allows several user agents (UAs) to share + a common AOR, learn about calls placed and received by other UAs in + the group, and pick up or join calls within the group. This document + discusses use cases, lists requirements, and defines extensions to + implement this feature. This specification updates RFCs 3261 and + 4235. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7463. + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + + + +Johnston, et al. Standards Track [Page 1] + +RFC 7463 SIP Shared Appearances March 2015 + + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 + 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5 + 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6 + 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Requirements and Implementation . . . . . . . . . . . . . . . 6 + 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8 + 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11 + 5.2.1. The <appearance> Element . . . . . . . . . . . . . . 11 + 5.2.2. The <exclusive> Element . . . . . . . . . . . . . . . 12 + 5.2.3. The <joined-dialog> Element . . . . . . . . . . . . . 12 + 5.2.4. The <replaced-dialog> Element . . . . . . . . . . . . 13 + 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13 + 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16 + 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17 + 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18 + 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 18 + 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21 + 7. Alert-Info Appearance Parameter Definition . . . . . . . . . 23 + + + +Johnston, et al. Standards Track [Page 2] + +RFC 7463 SIP Shared Appearances March 2015 + + + 8. User Interface Considerations . . . . . . . . . . . . . . . . 24 + 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24 + 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24 + 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24 + 8.1.3. Shared Appearance UAs with Fixed Appearance Number . 25 + 8.1.4. Shared Appearance UAs with Variable Appearance + Numbers . . . . . . . . . . . . . . . . . . . . . . . 25 + 8.1.5. Example User Interface Issues . . . . . . . . . . . . 25 + 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26 + 9. Interoperability with Non-shared Appearance UAs . . . . . . . 26 + 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26 + 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27 + 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27 + 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27 + 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28 + 11.1. Registration and Subscription . . . . . . . . . . . . . 28 + 11.2. Appearance Selection for Incoming Call . . . . . . . . . 32 + 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35 + 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . 38 + 11.5. Outgoing Call without Using an Appearance Number . . . . 42 + 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44 + 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . 45 + 11.8. Call between UAs within the Group . . . . . . . . . . . 50 + 11.9. Consultation Hold with Appearances . . . . . . . . . . . 52 + 11.10. Joining or Bridging an Appearance . . . . . . . . . . . 55 + 11.11. Loss of Appearance during Allocation . . . . . . . . . . 58 + 11.12. Appearance Seizure Contention Race Condition . . . . . . 59 + 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 + 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62 + 11.15. Appearance Seizure Incoming/Outgoing Contention Race + Condition . . . . . . . . . . . . . . . . . . . . . . . 65 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 + 13.1. SIP Event Header Field Parameter: shared . . . . . . . . 67 + 13.2. SIP Alert-Info Header Field Parameter: appearance . . . 68 + 13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68 + 13.4. XML Schema Registration . . . . . . . . . . . . . . . . 68 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 69 + 14.2. Informative References . . . . . . . . . . . . . . . . . 70 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 + +1. Introduction + + The feature and functionality requirements for SIP user agents (UAs) + supporting business telephony applications differ greatly from basic + SIP UAs, both in terms of services and end-user experience. In + + + +Johnston, et al. Standards Track [Page 3] + +RFC 7463 SIP Shared Appearances March 2015 + + + addition to basic SIP support [RFC3261], many of the services in a + business environment require the support for SIP extensions such as + REFER [RFC3515], SUBSCRIBE/NOTIFY [RFC6665], PUBLISH [RFC3903], the + SIP Replaces [RFC3891], and Join [RFC3911] header fields, etc. Many + of the popular business services have been documented in the SIP + Service Examples [RFC5359]. + + This specification details a method for implementing a group + telephony feature known variously in telephony as Bridged Line + Appearance (BLA) or Multiple Line Appearances (MLA), one of the more + popular advanced features expected of SIP IP telephony devices in a + business environment. Other names for this feature include Shared + Call/Line Appearance (SCA), Shared Call Status and Multiple Call + Appearance (MCA). A variant of this feature is known as Single Line + Extension. + + This document looks at how this feature can be implemented using + standard SIP [RFC3261] in conjunction with SIP events [RFC6665] and + publication [RFC3903] (carrying the SIP dialog state event package + [RFC4235]) for exchanging status among UAs. + + In traditional telephony, the line is physical. A common scenario in + telephony is for a number of business telephones to share a single or + a small number of lines. The sharing or appearance of these lines + between a number of phones is what gives this feature its name. A + common scenario in SIP is for a number of business telephones to + share a single or a small number of Address of Record (AOR) URIs. + + In addition, an AOR can have multiple appearances on a single UA in + terms of the user interface. The appearance number relates to the + user interface for the telephone; typically, each appearance of an + AOR has a visual display (lamp that can change color or blink or a + screen icon) and a button (used to select the appearance) where each + appearance number is associated with a different dialog to/from the + AOR. The telephony concept of line appearance is still relevant to + SIP due to the user interface considerations. It is important to + keep the appearance number construct because: + + 1. Human users are used to the concept and will expect it in + replacement systems (e.g., an overhead page announcement says + "Joe pickup line 3"). + + 2. It is a useful structure for user interface representation. + + The purpose of the appearance number is to identify active calls to + facilitate sharing between users (e.g., passing a call from one user + to another). If a telephone has enough buttons/lamps, the appearance + number could be the positional sequence number of the button. If + + + +Johnston, et al. Standards Track [Page 4] + +RFC 7463 SIP Shared Appearances March 2015 + + + not, it may still be desirable to present the call state, but the + appearance number should be displayed so that users know which call, + for example, is on hold on which key. + + In this document, except for the usage scenarios in the next section, + we will use the term "appearance" rather than "line appearance" since + SIP does not have the concept of lines. Note that this does not mean + that a conventional telephony user interface (lamps and buttons) must + be used: implementations may use another metaphor as long as the + appearance number is readily apparent to the user. Each AOR has a + separate appearance numbering space. As a result, a given UA user + interface may have multiple occurrences of the same appearance + number, but they will be for different AORs. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119] + and indicate requirement levels for compliant mechanisms. + +3. Usage Scenarios + + The following examples are common applications of the shared + appearances feature and are mentioned here as informative use cases. + All these example usages can be supported by the shared appearances + feature described in this document. The main differences relate to + the user interface considerations of the device. + +3.1. Executive/Assistant Arrangement + + The appearances on the executive's UA also appear on the assistant's + UA. The assistant may answer incoming calls to the executive and + then place the call on hold for the executive to pick up. The + assistant can always see the state of all calls on the executive's + UA. + +3.2. Call Group + + Users with similar business needs or tasks can be assigned to + specific groups and share an AOR. For example, an IT department + staff of five might answer a help line that has three appearances on + each phone in the IT work area. A call answered on one phone can be + put on hold and picked up on another phone. A shout or an IM to + another staff member can result in them taking over a call on a + particular appearance. Another phone can request to be added/joined/ + bridged to an existing appearance resulting in a conference call. + + + + +Johnston, et al. Standards Track [Page 5] + +RFC 7463 SIP Shared Appearances March 2015 + + +3.3. Single Line Extension + + In this scenario, incoming calls are offered to a group of UAs. When + one answers, the other UAs are informed. If another UA in the group + seizes the line (i.e., goes off-hook), it is immediately bridged or + joined in with the call. This mimics the way residential telephone + extensions usually operate. + +3.4. Changing UAs + + A user is on a call on one UA and wishes to change devices and + continue the call on another UA. They place the call on hold, note + the appearance number of the call, then walk to another UA. They are + able to identify the same appearance number on the other UA, pick up + the call, and continue the conversation. + +4. Requirements and Implementation + + The next section details the requirements and discusses the + implementation of the shared appearances feature. + +4.1. Requirements + + The basic requirements of the shared appearances feature can be + summarized as follows: + + REQ-1: Incoming calls to the AOR must be offered to a group of UAs + and can be answered by any of them. + + REQ-2: Each UA in the group must be able to learn the call status + of the others in the group for the purpose of rendering this + information to the user. + + REQ-3: A UA must be able to join (also called bridge or conference + together) or pick up (take) an active call of another UA in + the group in a secure way. + + REQ-4: The mechanism should require the minimal amount of + configuration. UAs registering against the group AOR should + be able to participate in the shared appearance group + without manual configuration of group members. + + REQ-5: The mechanism must scale for large numbers of appearances + and large numbers of UAs without introducing excessive + messaging traffic. + + REQ-6: Each call or session (incoming or outgoing) should be + assigned a common "appearance" number from a managed pool + + + +Johnston, et al. Standards Track [Page 6] + +RFC 7463 SIP Shared Appearances March 2015 + + + administered for the AOR group. Once the session has + terminated, the appearance number is released back into the + pool and can be reused by another incoming or outgoing + session. + + REQ-7: Each UA in the group must be able to learn the status of all + appearances of the group. + + REQ-8: There must be mechanisms to resolve appearance contention + among the UAs in the group. Contention in this context + means an appearance number being associated with multiple + dialogs that are not mixed or otherwise associated. + + REQ-9: The mechanism must allow all UAs receiving an incoming + session request to utilize the same appearance number at the + time of alerting. + + REQ-10: The mechanism must have a way of reconstructing appearance + state after an outage that does not result in excessive + traffic and processing. + + REQ-11: The mechanism must have backwards compatibility such that a + UA that is unaware of the feature can still register against + the group AOR and make and receive calls. + + REQ-12: The mechanism must not allow UAs outside the group to + select, seize, or manipulate appearance numbers. + + REQ-13: For privacy reasons, there must be a mechanism so that + appearance information is not leaked outside the group of + UAs (e.g., "So who do you have on line 1?"). + + REQ-14: The mechanism must support a way for UAs to request + exclusivity on a line appearance. Exclusivity means that + the UA requesting it desires a private conversation with the + external party and other UAs must not be allowed to join or + take the call. Exclusivity may be requested at the start of + an incoming or outgoing session or during the session. An + exclusivity request may be accepted or rejected by the + entity providing the shared appearance service. Therefore, + the mechanism must provide a way of communicating the result + back to the requester UA. + + REQ-15: The mechanism should support a way for a UA to seize a + particular appearance number for outgoing requests prior to + sending the actual request. This is often called seizure. + + + + + +Johnston, et al. Standards Track [Page 7] + +RFC 7463 SIP Shared Appearances March 2015 + + + 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 time. This is needed when an automatic ringdown + feature (a telephone configured to immediately dial a phone + number when it goes off-hook) is combined with shared + appearances. In this case, seizing the line is integrated + with dialing. + +4.2. Implementation + + This section non-normatively discusses the implementation of the + shared appearances feature. The normative description is in + Section 5. Many of the requirements for this service can be met + using standard SIP mechanisms such as: + + o A SIP Forking Proxy and Registrar/Location Service meets REQ-1. + + o The SIP Dialog Package meets REQ-2. + + o The combination of the SIP Replaces and Join header fields meets + REQ-3. + + o The use of a State Agent for the Dialog Package meets REQ-4 and + REQ-5. + + REQ-6 suggests the need for an entity that manages the appearance + resource. Just as conferencing systems commonly have a single point + of control, known as a focus, a shared appearance group has a single + point of control of the appearance shared resource. This is defined + as an Appearance Agent for a group. While an Appearance Agent can be + part of a centralized server, it could also be co-resident in a + member UA that has taken on this functionality for a group. The + Appearance Agent knows or is able to determine the dialog state of + all members of the group. + + While the appearance resource could be managed cooperatively by a + group of UAs without any central control, this is outside the scope + of this document. It is also possible that the Appearance Agent + logic could be distributed in all UAs in the group. For example, + rules that govern assigning appearance numbers for incoming requests + (e.g., lowest available appearance number) and rules for contention + handling (e.g., when two UAs request the use of the same appearance + number, hash dialog identifiers and compare with the lowest hash + winning) would need to be defined and implemented. + + To best meet REQ-9, the appearance number for an incoming INVITE + needs to be contained in the INVITE, in addition to being delivered + in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or + + + +Johnston, et al. Standards Track [Page 8] + +RFC 7463 SIP Shared Appearances March 2015 + + + lost, a UA in the group might receive an incoming INVITE but might + not know which appearance number to render during alerting. + + This specification defines an extension parameter, which is + normatively defined in Section 7, for the Alert-Info header field in + RFC 3261 to carry the appearance number: + + Alert-Info: <urn:alert:service:normal>;appearance=1 + + The following list describes the operation of the shared appearances + feature. + + 1. A UA is configured with the AOR of a shared appearance group. It + registers against the AOR, then attempts a dialog state + subscription to the AOR. If the subscription fails, loops back + to itself, or returns an error, it knows there is no State Agent + and, hence, no Appearance Agent and this feature is not + implemented. + + 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 + follows the steps in this list. + + 3. Information learned about the dialog state of other UAs in the + group is rendered to the user. + + 4. Incoming calls are forked to all UAs in the group, and any may + answer. UAs receive the appearance number to use in rendering + the incoming call in a NOTIFY from the Appearance Agent and in + the INVITE itself. The UA will also receive a notification if + the call is answered by another UA in the group so this + information can be rendered to the user. + + 5. For outgoing calls, the operation depends on the implementation. + If the user seizes a particular appearance number for the call, + the UA publishes the trying state dialog information with the + desired appearance number and waits for a 2xx response before + sending the INVITE. + + 6. For outgoing calls, if the user does not seize a particular + appearance or does not care, the INVITE can be sent immediately, + and the appearance number learned as the call progresses from a + notification from the Appearance Agent. + + 7. For outgoing calls, if the user does not want an appearance + number assigned (such as during a consultation call or if a UA is + fetching 'service media' such as music on hold [RFC7088]), the UA + + + + +Johnston, et al. Standards Track [Page 9] + +RFC 7463 SIP Shared Appearances March 2015 + + + also publishes prior to sending the INVITE but does not include + an appearance number in the publication. + + 8. Established calls within the group may be joined (bridged) or + taken (picked) by another UA. Information in the dialog package + notifications can be used to construct Join or Replaces header + fields. Since the same appearance number is used for these types + of operations, this information is published prior to sending the + INVITE Join or INVITE Replaces. + + 9. The Appearance Agent may not have direct access to the complete + dialog state of some or all of the UAs in the group. If this is + the case, the Appearance Agent will subscribe to the dialog state + of individual UAs in the group to obtain this information. In + any case, the Appearance Agent will send normal notifications + (via the subscriptions established by the UAs in step 1) every + time the aggregate dialog state of the AOR changes, including + when calls are placed, answered, placed on and off hold, and hung + up. + +5. Normative Description + + This section normatively describes the shared appearances feature + extensions. The following definitions are used throughout this + document: + + Appearance number: An appearance number is a positive integer + associated with one or more dialogs of an AOR. Appearance numbers + are managed by an Appearance Agent and displayed and rendered to + the user by UAs that support this specification. When an + appearance number is assigned or requested, generally the assigned + number is the smallest positive integer that is not currently + assigned as an appearance number to a dialog for this AOR. This + specification does not define an upper limit on appearance + numbers; however, using appearance numbers that are not easily + represented using common integer representations is likely to + cause failures. + + Seizing: An appearance can be reserved prior to a call being placed + by seizing the appearance. An appearance can be seized by + communicating an artificial state of "trying" prior to actually + initiating a dialog (i.e., sending the INVITE), in order to appear + as if it were already initiating a dialog. + + Selecting (or Not-Seizing): An appearance is merely selected (i.e., + not seized) if there is no such communication of artificial state + of "trying" prior to initiating a dialog: i.e., the state is + + + + +Johnston, et al. Standards Track [Page 10] + +RFC 7463 SIP Shared Appearances March 2015 + + + communicated when the dialog is actually initiated. The + appearance number is learned after the INVITE is sent. + +5.1. Elements + + A complete system to implement this feature consists of: + + 1. UAs that support publications, subscriptions, and notifications + for the SIP dialog event package and the shared appearance dialog + package extensions and behavior. + + 2. An Appearance Agent consisting of a State Agent for the dialog + event package that implements an Event State Compositor (ESC) and + the shared appearance dialog package extensions and behavior. + The Appearance Agent also has logic for assigning and releasing + appearance numbers and resolving appearance number contention. + + 3. A forking proxy server that can communicate with the State Agent. + + 4. A registrar that supports the registration event package. + + The behavior of these elements is described normatively in the + following sections after the definitions of the dialog package + extensions. + +5.2. Shared Appearance Dialog Package Extensions + + This specification defines four new elements as extensions to the SIP + Dialog Event package [RFC4235]. The schema is defined in Section 6. + The elements are <appearance>, <exclusive>, <joined-dialog>, and + <replaced-dialog>, which are sub-elements of the <dialog> element. + +5.2.1. The <appearance> Element + + The <appearance> element, a child of the <dialog> element, is used to + convey the appearance number of the dialog described by the parent + <dialog> element. When sent by a UA in a PUBLISH with parent + <dialog> with state attribute "trying" to the Appearance Agent, the + UA is requesting assignment of the given appearance number to the + current or future dialog with the given dialog identifiers. When an + <appearance> element is sent by the Appearance Agent in a NOTIFY, it + indicates that the appearance number has been assigned to the + specified dialog. + + Note that a <dialog-info> element describes the contained dialogs + from the point of view of the UA (named by the "entity" attribute), + regardless of whether the containing request is sent by the UA or the + Appearance Agent. In particular, if the UA sent a request within the + + + +Johnston, et al. Standards Track [Page 11] + +RFC 7463 SIP Shared Appearances March 2015 + + + described dialog, the To header field URI would match the <remote> + <identity> value and the to-tag parameter would match the remote-tag + attribute. Similarly, the From header field URI would match the + <local> <identity> value and the from-tag parameter would match the + local-tag attribute. + +5.2.2. The <exclusive> Element + + The <exclusive> element, a child of the <dialog> element, is a + boolean, which, when true, indicates that the UA is not willing to + accept an INVITE with a Join or Replaces header field targeted to the + dialog described by the <dialog> element that is the parent of the + <exclusive> element. For example, some shared appearance systems + only allow call pickup when the call is on hold. In this case, the + <exclusive> element should be set to "false" when the call is held + and "true" when the call is not held, rather than having the + "exclusive" value implied by the hold state. + + 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 + addition to setting the <exclusive> tag, not report full dialog + information to the Appearance Agent. Not having the full dialog + information (Call-ID, remote-tag, and local-tag) prevents another UA + 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 Join relating to this dialog. If these dialog identifiers + have already been shared with the Appearance Agent, the UA could send + an INVITE Replaces to change them and then not report the new ones to + the Appearance Agent. + + If the proxy knows which dialogs are marked exclusive, the proxy MAY + enforce this exclusivity by rejecting INVITE Join and INVITE Replaces + requests containing those dialog identifiers with a 403 (Forbidden) + response. + + Note that exclusivity has nothing to do with appearance number + selection or seizing -- instead, it is about call control + operations that can be performed on a dialog. + + If the <exclusive> element is not present, it is assumed to be false. + +5.2.3. The <joined-dialog> Element + + The <joined-dialog> element, a child of the <dialog> element, is used + to convey dialog identifiers of any other dialogs that are joined + (mixed or bridged) with the dialog. Only the UA that is the common + endpoint of the mixed dialogs (and thus controlling the mixing + operation) should include this element in publications to the + + + +Johnston, et al. Standards Track [Page 12] + +RFC 7463 SIP Shared Appearances March 2015 + + + Appearance Agent. Note that this element should still be used even + when the Join header field was not used to join the dialogs. For + example, two separate dialogs on a UA could be joined without any SIP + call control operations. Joined dialogs will share the same + appearance number. + + If the <joined-dialog> element is not present, it is assumed that the + dialog is not joined or to be joined to any other dialog. + +5.2.4. The <replaced-dialog> Element + + The <replaced-dialog> element, a child of the <dialog> element, is + used to convey dialog identifiers of any other dialogs that will be + 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 + Replaces would include this element for the replacing dialog. + Replaced dialogs will share the same appearance number. + + 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. + +5.3. Shared Appearance User Agents + + UAs that support the shared appearances feature use the dialog state + package [RFC4235] with the shared appearance extensions and the + 'shared' Event header field parameter defined in Section 13. + + UAs use the dialog package extensions in Section 5.2 along with + SUBSCRIBE [RFC6665], NOTIFY [RFC6665], and PUBLISH [RFC3903]. + SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package + include the 'shared' Event header field parameter as required by this + specification. + + The presence of the 'shared' Event header field parameter tells + the Appearance Agent that the UA supports this specification. + + Upon initialization, the UA MUST subscribe to the dialog event + package of the AOR and refresh the subscription per the SIP Events + Framework [RFC6665]. If the SUBSCRIBE request fails, then no + Appearance Agent may be present and this feature is not active for + this AOR. The UA MAY periodically retry the subscription to see if + conditions have changed at intervals no shorter than four hours. + + Four hours was chosen to limit the subscription test to six per + day per UA. Increasing this interval would reduce this failure + traffic but take longer for a newly activated Appearance Agent to + be discovered. + + + + +Johnston, et al. Standards Track [Page 13] + +RFC 7463 SIP Shared Appearances March 2015 + + + UAs can also use the presence of the 'shared' Event header field + parameter in NOTIFYs to discover the presence of an Appearance Agent + for the AOR. + + UAs that implement the shared appearances feature, call pickup, + joining, and bridging MUST support sending an INVITE with Replaces + [RFC3891] or Join [RFC3911]. The User Agent Client (UAC) needs to + include the to-tag and from-tag information in the Replaces or Join + header so that the correct dialog will be matched by the User Agent + Server (UAS) per the rules in RFCs 3891 and 3911. + + All UAs that implement the shared appearances feature and support + INVITE MUST support receiving an INVITE with a Replaces [RFC3891] or + a Join [RFC3911] header field. + + When publishing or notifying dialog package information, a UA + includes the largest set of dialog identification available at the + time of publication, with the exception that a UA may omit + information if it wishes to prevent other UAs from joining or picking + up a call. Dialog identification includes local and remote target + URIs, call-id, to-tag, and from-tag. While this dialog + identification information is optional in [RFC4235], it is essential + in the shared appearances feature, allowing call control operations. + When placing calls on hold, use the "+sip.rendering=no" feature tag + 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 + other UAs in the group is an important part of the shared + appearances 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 + confirmed seizure before sending an INVITE. Instead, the emergency + call MUST proceed without waiting for the PUBLISH transaction. + + If a UA requires a particular appearance number, the a UA MUST send a + dialog package PUBLISH request and wait for a 2xx response before + sending the INVITE. This is required in the following situations: + + 1. When the user seizes a particular appearance number for an + outgoing call (e.g., seizing the appearance and going "off-hook", + if the UA's user interface uses this metaphor). + + + + +Johnston, et al. Standards Track [Page 14] + +RFC 7463 SIP Shared Appearances March 2015 + + + 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 media' call such as for music on hold [RFC7088], or for + a call not considered part of the shared appearance group). + + 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. + + Note that when a UA seizes an appearance prior to establishment of a + dialog (numbers 1 and 2 in the above list), not all dialog + information will be available. In particular, when a UA publishes an + attempt to seize an appearance prior to knowing the destination URI, + minimal or no dialog information may be available. For example, in + some cases, only the local target URI for the call will be known: not + any dialog information. If the From tag and Call-ID were not present + in the initial PUBLISH, a new PUBLISH MUST be sent as soon as this + information is available. + + The first publication will cause the Appearance Agent to reserve + the appearance number for this UA. If the publication does not + have any dialog identifiers (e.g., Call-ID or local-tag), the + Appearance Agent cannot assign the appearance number to a + particular dialog of the UA until the second publication, which + will contain some dialog identifiers. + + This publication state is refreshed as described in [RFC3903] during + the early dialog state or the Appearance Agent may reassign the + appearance number. Once the dialog has transitioned to the confirmed + state, no publication refreshes are necessary. + + This specification assumes that the Appearance Agent has other + means besides UA publication to learn about the state of UA + dialogs. In this specification, PUBLISH is used to indicate + desired and intended appearance number operations. Once a dialog + transitions from early to confirmed, this role is over; hence, no + publication refreshes are needed. + + Appearance numbers are a shorthand label for active and pending + dialogs related to an AOR. Many of the features and services built + using this extension rely on the correct rendering of this + information to the human user. In addition, the group nature of the + feature means that the rendering must be similar between different + vendors and different models. Failure to do so will greatly reduce + the value and usefulness of these protocol extensions. In a + correctly designed user interface for this feature, the appearances + number for each active and pending dialog is explicitly (i.e., by + appearance number) or implicitly (using a user interface metaphor + + + +Johnston, et al. Standards Track [Page 15] + +RFC 7463 SIP Shared Appearances March 2015 + + + that makes the numbering and ordering clear to the user) rendered to + the user. The far-end identity of each dialog (e.g., the remote + party identity) is not a useful replacement for the appearance + number. The state of each appearance is also to be rendered (idle, + active, busy, joined, etc.). UAs can tell that a set of dialogs are + joined (bridged or mixed) together by the presence of one or more + <joined-dialog> elements containing other SIP dialog identifiers. + Appearance numbers of dialogs can be learned by dialog package + notifications containing the <appearance> element from the Appearance + Agent or from the 'appearance' Alert-Info parameter in an incoming + INVITE. Should they conflict, the dialog package notification takes + precedence. + + 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 + number by removing the event state with a PUBLISH as described in + [RFC3903]. A failure to do this will require unnecessary operations + by the Appearance Agent and tie up appearance numbers that could + otherwise be used by other UAs in the shared appearance group. + + 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 + monitoring the status of the shared appearance group calls and + picking or joining calls, the UA SHOULD only subscribe to the AOR and + not register against the AOR. If a monitoring UA registers rather + than just subscribing, it generates large amounts of unnecessary + network traffic. + + All subscribed UAs will receive dialog package NOTIFYs of trying + 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 + + 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 + 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 + puts an existing dialog on hold, then calls another user, before + switching back to the original dialog. Another case, described + below, occurs during transfer operations, where for a transient + period, a UA is involved in dialogs with two other UAs, but the + dialogs are related, and should not be treated as independent + dialogs. These cases are best handled by not assigning an appearance + + + +Johnston, et al. Standards Track [Page 16] + +RFC 7463 SIP Shared Appearances March 2015 + + + number to a newly created dialog when it shares a context with an + existing dialog. But if the preexisting dialog is terminated, its + appearance number should be reassigned to the newly created dialog. + + A UA that wants to place a call but does not have an appearance + number assigned sends a PUBLISH before sending the INVITE. The + PUBLISH does not have an 'appearance' element present, but it does + have the 'shared' Event header field parameter present. If the + Appearance Agent policy does not allow calls without an assigned + appearance number, a 400 (Bad Request) response is sent by the + Appearance Agent and the UA will republish either selecting/seizing + an appearance number or send the INVITE without publishing, in which + case the Appearance Agent will assign one. + + Note that if an Appearance Agent rejects calls without an + appearance number, certain operations such as consultation calls, + transfer, and music on hold may be negatively impacted. + +5.3.2. Appearance Numbers and Call Control + + 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 in the shared appearance group), the UA MUST first send a + PUBLISH to the Appearance Agent. This PUBLISH will contain: + + 1. The appearance number of the joined or replaced call in the + <appearance> element + + 2. The dialog information from the Join header field in the <joined- + dialog> element, if the dialog is being joined + + 3. The dialog information from the Replaces header field in the + <replaced-dialog> element, if the dialog is being replaced + + Note that this information is provided to the Appearance Agent so + that it can provide proper appearance assignment behavior. If the + INVITE Join or Replaces was sent without publishing first, the + Appearance Agent might assign a new appearance number to this + INVITE, which would be a mistake. With Join, the publication has + the <joined-dialog> element to prevent the Appearance Agent from + generating a 400 (Bad Request) response due to the reuse of an + appearance number. For Replaces, the purpose of the <replaced- + dialog> is to prevent a race condition where the BYE could cause + the appearance number to be released when it should stay with the + replacing dialog. + + + + + + +Johnston, et al. Standards Track [Page 17] + +RFC 7463 SIP Shared Appearances March 2015 + + +5.3.3. Appearance Numbers and Transfer + + During a transfer operation, it is important that the appearance + number not change during the operation. Consider the example of + Alice, a member of a shared appearance group, who is talking to + Carol, who is outside the shared appearance group. Carol transfers + Alice to David, who is also outside the shared appearance group. For + example, if Alice is using appearance 3 for the session with Carol, + the resulting session with David should also use appearance number 3. + Otherwise, an appearance number change can cause a "jump" on the UI + and confusion to the user. There are two possible scenarios using + the terminology of RFC 5589: Alice is the transferee in any type of + transfer (receives the REFER) or the transfer target in an attended + transfer (receives the INVITE with Replaces). + + If Alice is the transferee, the triggered INVITE from the REFER is + treated as a consultation call. Alice SHOULD publish requesting that + the Appearance Agent not assign an appearance number for this INVITE. + When the transfer completes, Alice SHOULD publish again to move the + appearance number from the dialog with Carol to the dialog with + David. If a PUBLISH is sent to move the appearance number, the + publication MUST be sent prior to sending the BYE to Carol to avoid a + race condition where the Appearance Agent reassigns the appearance + number after seeing the BYE. + + If Alice is the target, the incoming INVITE will contain a Replaces + header field. As a result, the Appearance Agent will have reused the + appearance number of the dialog with Carol, and this appearance + number will continue to be used after the dialog with Carol has been + terminated. + +5.4. Appearance Agent + + An Appearance Agent defined in this specification MUST implement a + dialog package state agent for the UAs registered against the AOR. + The Appearance Agent MUST support the appearance dialog package + extensions defined in Section 5.2 and use the 'shared' Event header + field parameter. The Appearance Agent MUST support publications and + subscriptions for this event package. + + The Appearance Agent MUST have a way of discovering the state of all + dialogs associated with the AOR. If this information is not + available from a call stateful proxy or Back-to-Back User Agent + (B2BUA), the Appearance Agent can use the registration event package + [RFC3680] to learn of UAs associated with the AOR and subscribe to + their dialog event state. An Appearance Agent can also subscribe to + a UA's dialog event state in order to reconstruct state. As a + result, the registrar MUST support the registration event package. + + + +Johnston, et al. Standards Track [Page 18] + +RFC 7463 SIP Shared Appearances March 2015 + + + Dialog package notifications are recommended by RFC 4235 to "only + contain information on the dialogs whose state or participation + information has changed." This specification extends RFC 4235 as + follows. The Appearance Agent SHOULD send dialog event state + notifications whenever the following events happen to UAs in the AOR + group: + + 1. A call is received, placed, answered, or terminated. + + 2. A call is placed on or off hold. + + 3. A call is joined or replaced. + + 4. An appearance number is reserved or released. + + The Appearance Agent MUST allocate an appearance number for all + incoming calls and send immediate notifications to the UAs subscribed + to the shared group AOR. A new appearance number is allocated except + for an incoming INVITE with a Join or Replaces header field. For + this case, the appearance number should match the appearance number + of the dialog being joined or replaced. If the INVITE Replaces or + Join comes from outside the shared appearance group, the Appearance + Agent will include a <joined-dialog> or <replaced-dialog> element in + the NOTIFY containing the dialog information from the Replaces or + Joined header field. + + The Appearance Agent MUST be able to communicate with the forking + proxy to learn about incoming calls and also to pass the appearance + number to the proxy or ensure the Alert-Info header field is included + in the INVITE with the appropriate appearance number. + + Note that UAs need to be able to handle incoming INVITEs without + an appearance number assigned. This could be caused by a failure + of the Appearance Agent or other error condition. Although the + proper rendering of the INVITE may not be possible, this is better + than ignoring or failing the INVITE. + + An Appearance Agent SHOULD assign an appearance number to an outgoing + dialog if a PUBLISH has not been received selecting/seizing a + particular appearance number. + + Note that if the shared appearance group has appearance-unaware + UAs making calls, the Appearance Agent will still allocate + appearance numbers for INVITEs sent by those UAs. + + An Appearance Agent receiving a PUBLISH with 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> + + + +Johnston, et al. Standards Track [Page 19] + +RFC 7463 SIP Shared Appearances March 2015 + + + or <replaced-dialog> element indicating that the dialog will be/has + been replaced or joined. A 400 (Bad Request) response is returned if + the chosen appearance number is invalid, and an immediate NOTIFY + SHOULD be sent to the UA containing full dialog event state. + + An Appearance Agent receiving a PUBLISH without an appearance number + but with the 'shared' Event header field parameter present interprets + this as a request by the UA to not assign an appearance number. If + the Appearance Agent policy does not allow this, a 400 (Bad Request) + response is returned. If policy does allow this, a 200 (OK) response + is returned and no appearance number is allocated. An Appearance + Agent does not have to share this dialog information (i.e., send a + NOTIFY) with other UAs in the group as the information will not be + rendered by the other UAs. + + The Appearance Agent allocates an appearance number to a dialog from + the time the appearance is requested via a PUBLISH or from the + receipt of an INVITE to the time when the last dialog associated with + the appearance is terminated, including all dialogs that are joined + or replaced. During the early dialog state, the Appearance Agent + controls the rate of dialog state publication using the Expires + header field in 200 (OK) responses to PUBLISH requests. An interval + of 3 minutes is RECOMMENDED. After the dialog associated with the + publication has been confirmed, the expiration of the publication + state has no effect on the appearance allocation. If the publication + contains no dialog state information, the Appearance Agent MUST + reserve the appearance number for the UA but cannot assign the + appearance to any particular dialog of the UA. When the publication + state is updated with any dialog information, the appearance number + can then be assigned to the particular dialog. A UA that has been + allocated an appearance number using a PUBLISH MAY free up the + appearance number by removing the event state with a PUBLISH as + 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 + sent to the shared AOR and no appearance number is available, the + proxy MAY reject the INVITE with a 403 (Forbidden) response code. + + + + + +Johnston, et al. Standards Track [Page 20] + +RFC 7463 SIP Shared Appearances March 2015 + + + Appearance numbers are only used for dialogs in which one or more UAs + associated with the group AOR are participants. If an incoming + INVITE to the group AOR is forwarded to another AOR, the appearance + number is immediately freed up and can be assigned to another dialog. + +6. XML Schema Definition + + The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' + elements are defined within a new XML namespace URI. This namespace + is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these + elements is: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johnston, et al. Standards Track [Page 21] + +RFC 7463 SIP Shared Appearances March 2015 + + + <?xml version="1.0" encoding="UTF-8"?> + <xs:schema + targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info" + xmlns="urn:ietf:params:xml:ns:sa-dialog-info" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified"> + + + <xs:element name="joined-dialog" minOccurs="0" + maxOccurs="unbounded"> + <xs:complexType> + <xs:attribute name="call-id" type="xs:string" + use="mandatory"/> + <xs:attribute name="local-tag" type="xs:string" + use="mandatory"/> + <xs:attribute name="remote-tag" type="xs:string" + use="mandatory"/> + </xs:complexType> + </xs:element> + + <xs:element name="replaced-dialog" minOccurs="0" + maxOccurs="unbounded"> + <xs:complexType> + <xs:attribute name="call-id" type="xs:string" + use="mandatory"/> + <xs:attribute name="local-tag" type="xs:string" + use="mandatory"/> + <xs:attribute name="remote-tag" type="xs:string" + use="mandatory"/> + </xs:complexType> + </xs:element> + + <xs:element name="appearance" minOccurs="0" maxOccurs="1"> + <xs:simpleType type="xs:integer"> + </xs:simpleType> + </xs:element> + + <xs:element name="exclusive" minOccurs="0" maxOccurs="1"> + <xs:simpleType type="xs:boolean"> + </xs:simpleType> + </xs:element> + </xs:schema> + + + + + + + + + +Johnston, et al. Standards Track [Page 22] + +RFC 7463 SIP Shared Appearances March 2015 + + +7. Alert-Info Appearance Parameter Definition + + This specification extends [RFC3261] to add an 'appearance' parameter + to the Alert-Info header field and also to allow proxies to modify or + delete the Alert-Info header field. + + The changes to the ABNF [RFC5234] in RFC 3261 are: + + alert-param = LAQUOT absoluteURI RAQUOT *( SEMI + (generic-param / appearance-param) ) + appearance-param = "appearance" EQUAL 1*DIGIT + + A proxy inserting an 'appearance' Alert-Info parameter follows normal + Alert-Info policies. To indicate the appearance number for this + dialog, the proxy adds the Alert-Info header field with the + 'appearance' parameter to the INVITE. If an Alert-Info is already + present, the proxy adds the 'appearance' parameter to the Alert-Info + header field. If an appearance number parameter is already present + (associated with another AOR or by mistake), the value is rewritten + 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 + indicated using the urn:alert:service:normal in the Alert-Info, as + per [RFC7462]. The appearance number present 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 forwarded to another + AOR, the appearance parameter in the Alert-Info SHOULD be removed + before forwarding outside the group. + + The determination as to what value to use in the appearance parameter + can be done at the proxy that forks the incoming request to all the + registered UAs. + + There is a variety of ways the proxy can determine what value it + should use to populate this parameter. For example, the proxy + could fetch this information by initiating a SUBSCRIBE request + with Expires: 0 to the Appearance Agent for the AOR to fetch the + list of lines that are in use. Alternatively, it could act like a + UA that is a part of the shared appearance group and SUBSCRIBE to + the State-Agent like any other UA. This would ensure that the + active dialog information is available without having to poll on a + need basis. It could keep track of the list of active calls for + the appearance AOR based on how many unique INVITE requests it has + forked to or received from the appearance AOR. Another approach + would be for the Proxy to first send the incoming INVITE to the + Appearance Agent, which would redirect to the shared appearance + + + + +Johnston, et al. Standards Track [Page 23] + +RFC 7463 SIP Shared Appearances March 2015 + + + group URI and escape the proper Alert-Info header field for the + Proxy to recurse and distribute to the other UAs in the group. + + The Appearance Agent needs to know about all incoming requests to + the AOR in order to seize the appearance number. One way in which + this could be done is for the Appearance Agent to register against + the AOR with a higher q value. This will result in the INVITE + being sent to the Appearance Agent first, then being offered to + the UAs in the group. + +8. User Interface Considerations + + The appearance number allocated to a call is an important concept + that enables calls to be handled by multiple devices with + heterogeneous user interfaces in a manner that still allows users to + see a consistent model. Careful treatment of the appearance number + is essential to meet the expectations of the users. Also, rendering + the correct call/appearance state to users is also important. + +8.1. Appearance Number Rendering + + Since different UAs have different user interface capabilities, it is + usual to find that some UAs have restrictions that others do not. + Perfect interoperability across all UAs is clearly not possible, but + by careful design, interoperability up to the limits of each UA can + be achieved. + + The following guidelines suggest how the appearance number should be + handled in three typical user interface implementations. + +8.1.1. Single Appearance UAs + + These devices are constrained by only having the capability of + displaying status indications for a single appearance. The UA SHOULD + still send messages annotated with appearance number "1". Any call + indications for appearances other than for number "1" SHOULD be + rejected with a 480 (Temporarily Unavailable) or 486 (Busy Here) + 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 + + These devices are essentially single appearance phones that implement + call waiting. They have a very simple user interface that allows + them to switch between two appearances (toggle or flash hook) and + perhaps audible tones to indicate the status of the other appearance. + Only appearance numbers "1" and "2" will be used by these UAs. + + + +Johnston, et al. Standards Track [Page 24] + +RFC 7463 SIP Shared Appearances March 2015 + + +8.1.3. Shared Appearance UAs with Fixed Appearance Number + + This UA is the typical 'business-class' hard-phone. A number of + appearances are typically configured statically and labeled on + buttons, and calls may be managed using these configured appearances. + Any calls outside this range should be rejected, and not mapped to a + free button. Users of these devices often seize specific appearance + numbers for outgoing calls, and the UA will need to seize the + appearance number and wait for confirmation from the Appearance Agent + before proceeding with calls. + +8.1.4. Shared Appearance UAs with Variable Appearance Numbers + + This UA is typically a soft-phone or graphically rich user interface + hard-phone. In these cases, even the idea of an appearance index may + seem unnecessary. However, for these phones to be able to interwork + successfully with other phone types, it is important that they still + use the appearance index to govern the order of appearance of calls + in progress. No specific guidance on presentation is given except + that the order should be consistent. These devices can typically + make calls without waiting for confirmation from the Appearance Agent + on the appearance number. + +8.1.5. Example User Interface Issues + + The problems faced by each style of user interface are readily seen + in this example: + + 1. A call arrives at the shared appearance group and is assigned an + appearance number of "1". All UAs should be able to render to + the user the arrival of this call. + + 2. Another call arrives at the shared appearance group and is + assigned an appearance number of "2". The single appearance UA + should not present this call to the user. Other UAs should have + no problems presenting this call distinctly from the first call. + + 3. The first call clears, releasing appearance number "1". The + single appearance UA should now be indicating no calls since it + is unable to manage calls other than on the first appearance. + Both shared appearance UAs should clearly show that appearance + number "1" is now free, but that there is still a call on + appearance number "2". + + 4. A third call arrives and is assigned the appearance number of + "1". All UAs should be able to render the arrival of this new + call to the user. Multiple appearance UAs should continue to + indicate the presence of the second call, and they should also + + + +Johnston, et al. Standards Track [Page 25] + +RFC 7463 SIP Shared Appearances March 2015 + + + ensure that the presentation order is related to the appearance + number and not the order of call arrival. + +8.2. Call State Rendering + + UAs that implement the shared appearances feature typically have a + user interface that provides the state of other appearances in the + group. As dialog state NOTIFYs from the Appearance Agent are + processed, this information can be rendered. Even the simplest user + interface typically has three states: idle, active, and hold. The + idle state, usually indicated by lamp off, is indicated for an + appearance when the appearance number is not associated with any + dialogs, as reported by the Appearance Agent. The active state, + usually indicated by a lamp on, means that an appearance number is + associated with at least one dialog, as reported by the Appearance + Agent. The hold state, often indicated by a blinking lamp, means the + call state from the perspective of the UA in the shared appearance + group is hold. This can be determined by the presence of the + "+sip.rendering=no" feature tag [RFC3840] with the local target URI. + Note that the hold state of the remote target URI is not relevant to + this display. For joined dialogs, the state is rendered as hold only + if all local target URIs are indicated with the "+sip.rendering=no" + feature tag. + +9. Interoperability with Non-shared Appearance UAs + + It is desirable to allow a basic UA that does not directly support + shared appearance to be part of a shared appearance group. To + support this, the Proxy must collaborate with the Appearance Agent. + This is not required in the basic shared appearance architecture; + consequently, shared appearance interoperability with non-shared + appearance UAs will not be available in all shared appearance + deployments. + + First, a UA that does not support dialog events or the shared + appearances feature will be discussed. Then, a UA that does support + dialog events but not the shared appearances feature will be + discussed. + +9.1. Appearance Assignment + + A UA that has no knowledge of appearances will only have appearance + numbers for outgoing calls if assigned by the Appearance Agent. If + the non-shared appearance UA does not support Join or Replaces, all + dialogs SHOULD be marked "exclusive" to indicate that these options + are not available. Marking these dialogs "exclusive" provides a + better user experience and avoids extra SIP messaging failures. + + + + +Johnston, et al. Standards Track [Page 26] + +RFC 7463 SIP Shared Appearances March 2015 + + +9.2. Appearance Release + + In all cases, the Appearance Agent must be aware of the dialog + lifetime to release appearances back into the group. + + 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 + Event Package. If the Appearance Agent includes a proxy that Record- + Routes for dialogs from the non-shared-appearance-aware UA, the + Appearance Agent will know about the state of dialogs including hold, + etc. This information could be determined from inspection of non- + end-to-end-encrypted INVITE and re-INVITE messages and added to the + dialog information conveyed to other UAs. + +9.3. UAs Supporting Dialog Events but Not Shared Appearance + + Interoperability with UAs that support dialog events but not the + shared appearances feature is more straightforward. As before, all + appearance number assignments must be done by the Appearance Agent. + The Appearance Agent SHOULD still include appearance information in + NOTIFYs -- this UA will simply ignore this extra information. This + type of UA will also ignore appearance number limitations and may + attempt to join or replace dialogs marked exclusive. As a result, + the Proxy or UAs need to reject such requests or the dialogs will be + joined or taken. + +10. Provisioning Considerations + + UAs can automatically discover if this feature is active for an AOR + by looking for the 'shared' Event header field parameter in a + response to a dialog package SUBSCRIBE to the AOR, so no provisioning + for this is needed. + + The registrar will need to be provisioned to accept either first or + third party registrations for the shared AOR. First party + 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 + 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 + user MUST be accepted by the registrar and the Appearance Agent, + depending on the authorization policy in place for the domain. + + If the Appearance Agent needs to subscribe to the dialog state of the + UAs, then the Appearance Agent and the UAs need to be provisioned + with credentials so the UAs can authenticate the Appearance Agent. + + In some cases, UAs in the shared appearance group might have a UI + limitation on the number of appearances that can be rendered. + + + +Johnston, et al. Standards Track [Page 27] + +RFC 7463 SIP Shared Appearances March 2015 + + + Typically, this will be hard-phones with buttons/lamps instead of + more flexible UIs. In this case, it can be useful for the Appearance + Agent to know this maximum number. This can allow the Appearance + Agent to apply policy when this limit is reached, e.g., deny a call. + However, this mechanism does not provide any way to discover this by + protocol means. + +11. Example Message Flows + + The next section shows call flow and message examples. The flows and + descriptions are non-normative. Note that, in these examples, all + INVITEs sent by a UA in the group will be From the shared AOR + (sip:HelpDesk@example.com in this case), and all INVITES sent to the + group will have a Request-URI of the shared AOR. Any other requests + would not apply to this feature and would be handled using normal SIP + mechanisms. + + Note that the first 12 examples assume the Appearance Agent is aware + of dialog state events. The example in Section 11.13 shows the case + where this is not the case, and, as a result, the Appearance Agent + initiates a subscription to users of the shared AOR. Any of the + other call flow examples could have shown this mode of operation as + it is equally valid. + +11.1. Registration and Subscription + + Bob and Alice are in a shared appearance group identified by the + shared appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using + contact sip:bob@ua2.example.com. Alice REGISTERs with contact + sip:alice@ua1.example.com. + + UAs for Alice and Bob subscribe to the dialog package for the + appearance AOR and publish dialog state to the Appearance Agent. + Message exchanges between the Registrar, Appearance Agent, Alice, and + Bob are shown below. The call flow examples below do not show the + authentication of subscriptions, publications, and notifications. It + should be noted that for security purposes, all publications and + subscriptions must be authorized before they are accepted. + + Also note that registrations and subscriptions must all be refreshed + by Alice at intervals determined by the expiration intervals returned + by the Registrar or Appearance Agent. + + Registrar Appearance Agent Alice Bob + | | | | + | | | | + |<--------------------------- REGISTER F1<| | + | | | | + + + +Johnston, et al. Standards Track [Page 28] + +RFC 7463 SIP Shared Appearances March 2015 + + + |>F2 200 OK ----------------------------->| | + | | | | + | |<----- SUBSCRIBE F3<| | + | | | | + | |>F4 200 OK -------->| | + | | | | + | |>F5 NOTIFY -------->| | + | | | | + | |<-------- 200 OK F6<| | + | | | | + |<-------------------------------------------- REGISTER F7<| + | | | | + |>F8 200 OK ---------------------------------------------->| + | | | | + | |<---------------------- SUBSCRIBE F9<| + | | | | + | |>F10 200 OK ------------------------>| + | | | | + | |>F11 NOTIFY ------------------------>| + | | | | + | |<------------------------ 200 OK F12<| + | | | | + + Figure 1. Registration and Subscription Example + + F1-F2: Alice registers AOR with + contact: <sip:alice@ua1.example.com> + + F1 Alice ----> Registrar + + REGISTER sip:registrar.example.com SIP/2.0 + Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 + From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD + To: <sip:HelpDesk@example.com> + CSeq: 2 REGISTER + Call-ID: d3281184-518783de-cc23d6bb + Contact: <sip:alice@ua1.example.com> + Max-Forwards: 70 + Expires: 3600 + Content-Length: 0 + + + F2 Registrar ----> Alice + + SIP/2.0 200 OK + Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 + CSeq: 2 REGISTER + Call-ID: d3281184-518783de-cc23d6bb + + + +Johnston, et al. Standards Track [Page 29] + +RFC 7463 SIP Shared Appearances March 2015 + + + From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD + To: <sip:HelpDesk@example.com>;tag=1664573879820199 + Contact: <sip:alice@ua1.example.com>;expires=3600 + Content-Length: 0 + + + F3 to F6: Alice also subscribes to the events associated with the + Appearance AOR. Appearance Agent notifies Alice of the status. + + F3 Alice ----> Appearance Agent + + SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 + Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A + From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E + To: <sip:HelpDesk@example.com> + CSeq: 91 SUBSCRIBE + Call-ID: ef4704d9-bb68aa0b-474c9d94 + Contact: <sip:alice@ua1.example.com> + Event: dialog;shared + Accept: application/dialog-info+xml + Max-Forwards: 70 + Expires: 3700 + Content-Length: 0 + + + F4 Appearance Agent ----> Alice + + SIP/2.0 200 OK + Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A + CSeq: 91 SUBSCRIBE + Call-ID: ef4704d9-bb68aa0b-474c9d94 + From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E + To: <sip:HelpDesk@example.com>;tag=1636248422222257 + Allow-Events: dialog + Expires: 3700 + Contact: <sip:appearanceagent.example.com> + Content-Length: 0 + + + F5 Appearance Agent ----> Alice + + NOTIFY sip:alice@ua1.example.com SIP/2.0 + From: <sip:HelpDesk@example.com>;tag=1636248422222257 + To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E + Call-ID: ef4704d9-bb68aa0b-474c9d94 + CSeq: 232 NOTIFY + Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 + Max-Forwards: 70 + + + +Johnston, et al. Standards Track [Page 30] + +RFC 7463 SIP Shared Appearances March 2015 + + + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=3000 + Contact: <sip:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + version="40" + state="full" + entity="sip:HelpDesk@example.com"> + </dialog-info> + + + F6 Alice ----> Appearance Agent + + SIP/2.0 200 OK + Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846 + From: <sip:HelpDesk@example.com>;tag=1636248422222257 + To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E + CSeq: 232 NOTIFY + Call-ID: ef4704d9-bb68aa0b-474c9d94 + Contact: <sip:alice@ua1.example.com> + Content-Length: 0 + + + F7 Bob ----> Registrar + + REGISTER sip:registrar.example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B + From: <sip:bob@example.com>;tag=34831131 + To: <sip:HelpDesk@example.com> + CSeq: 72 REGISTER + Call-ID: 139490230230249348 + Contact: <sip:bob@ua2.example.com> + Max-Forwards: 70 + Expires: 3600 + Content-Length: 0 + + + F8 Registrar ----> Bob + + SIP/2.0 200 OK + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B + From: <sip:bob@example.com>;tag=34831131 + To: <sip:HelpDesk@example.com>;tag=fkwlwqi1 + CSeq: 72 REGISTER + Call-ID: 139490230230249348 + + + +Johnston, et al. Standards Track [Page 31] + +RFC 7463 SIP Shared Appearances March 2015 + + + Contact: <sip:alice@ua1.example.com>;expires=3200 + Contact: <sip:bob@ua2.example.com>;expires=3600 + Content-Length: 0 + + + + +11.2. Appearance Selection for Incoming Call + + In the call flow below, Bob and Alice are in a shared appearance + group. Carol places a call to the shared appearance group AOR. The + Appearance Agent sends NOTIFYs to Alice and Bob telling them what + appearance the call is using. Both Alice and Bob's devices are + alerted of the incoming call. Bob answers the call. + + Note that it is possible that both Alice and Bob answer the call and + send 200 (OK) responses to Carol. It is up to Carol to resolve this + situation. Typically, Carol will send ACKs to both 200 OKs but send + a BYE to terminate one of the dialogs. As a result, either Alice or + Bob will receive the BYE and publish that their dialog is over. + However, if Carol answers both Alice and Bob and keeps both dialogs + active, then the Appearance Agent will need to resolve the situation + by moving either Alice or Bob's dialog to a different appearance. + + All NOTIFY messages in the call flow below carry dialog events and + only dialog states are mentioned for simplicity. For brevity, the + details of some messages are not shown below. Note that the order of + F2 - F5 and F7 - F8 could be reversed. + + Forking Appearance + Carol Proxy Agent Alice Bob + | | | | | + |>F1 INVITE >| | | | + | |< - - - - - >| | | + | | |>F2 NOTIFY ----------->| + | | | | | + | | |<F3 200 OK -----------<| + | | | | | + | | |>F4 NOTIFY ->| | + | | | | | + | | |<-200 OK F5-<| | + |<- 100 F6 -<| | | | + | |>F7 INVITE (appearance=1) ---------->| + | | | | | + | |>F8 INVITE (appearance=1) >| | + | | | | | + | |<-------------------- Ringing 180 F9<| + |< 180 F10 -<| | | | + + + +Johnston, et al. Standards Track [Page 32] + +RFC 7463 SIP Shared Appearances March 2015 + + + | |<--------- 180 Ringing F11<| | + |< 180 F12 -<| | | | + | | | | | + | |<------------------------ 200 OK F13<| + |< 200 F14 -<| | | | + | | | | | + | |>F15 CANCEL -------------->| | + | | | | | + | |<-------------- 200 OK F16<| | + | | | | | + | |<Request Cancelled 487 F17<| | + | | | | | + | |>F18 ACK ----------------->| | + |>F19 ACK -->| | | | + | |>F20 ACK --------------------------->| + | | | | | + |<=============Both way RTP established===========>| + | | | | | + | |< - - - - - >| | | + | | | | | + | | |>F21 NOTIFY >| | + | | | | | + | | |<- 200 F22 -<| | + | | | | | + | | |>F23 NOTIFY ---------->| + | | | | | + | | |<F24 200 OK ----------<| + | | | | + + Figure 2. Appearance Selection for Incoming Call Example + + + F4 Appearance Agent ----> Alice + + NOTIFY sip:alice@ua1.example.com SIP/2.0 + From: <sip:HelpDesk@example.com>;tag=151702541050937 + To: <sip:alice@example.com>;tag=18433323-C3D237CE + Call-ID: 1e361d2f-a9f51109-bafe31d4 + CSeq: 12 NOTIFY + Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=2800 + Contact: <sip:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + + + +Johnston, et al. Standards Track [Page 33] + +RFC 7463 SIP Shared Appearances March 2015 + + + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="13" + state="partial" + entity="sip:HelpDesk@example.com"> + <dialog id="2a7294823093f5274e3fd2ec54a2d76c" + call-id="14-1541707345" + remote-tag="44BAD75D-E3128D42" + direction="recipient"> + <sa:appearance>1</sa:appearance> + <state>trying</state> + <remote> + <identity>sip:carol@ua.example.com</identity> + </remote> + </dialog> + </dialog-info> + + + F7 Proxy ----> Bob + + INVITE sip:bob@ua2.example.com SIP/2.0 + Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea + Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji + From: <sip:carol@example.com>;tag=44BAD75D-E3128D42 + To: <sip:HelpDesk@example.com> + CSeq: 106 INVITE + Call-ID: 14-1541707345 + Contact: <sip:carol@ua3.example.com> + Max-Forwards: 69 + Alert-Info: <urn:alert:service:normal>;appearance=1 + Content-Type: application/sdp + Content-Length: ... + + v=0 + o=- 1102980499 1102980499 IN IP4 ua3.example.com + s= + c=IN IP4 ua3.example.com + t=0 0 + m=audio 2238 RTP/AVP 0 8 101 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:101 telephone-event/8000 + + + F21 Appearance Agent ----> Alice + + NOTIFY sip:alice@ua1.example.com SIP/2.0 + From: <sip:HelpDesk@example.com>;tag=151702541050937 + + + +Johnston, et al. Standards Track [Page 34] + +RFC 7463 SIP Shared Appearances March 2015 + + + To: <sip:alice@example.com>;tag=18433323-C3D237CE + Call-ID: 1e361d2f-a9f51109-bafe31d4 + CSeq: 13 NOTIFY + Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=2500 + Contact: <sip:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="17" + state="partial" + entity="sip:HelpDesk@example.com"> + <dialog id="2a7294823093f5274e3fd2ec54a2d76c" + call-id="14-1541707345" + remote-tag="44BAD75D-E3128D42" + local-tag="7349dsfjkFD03s" + direction="recipient"> + <sa:appearance>1</sa:appearance> + <state>confirmed</state> + <local> + <target>sip:bob@ua2.example.com</target> + </local> + <remote> + <identity>sip:carol@ua.example.com</identity> + </remote> + </dialog> + </dialog-info> + + +11.3. Outgoing Call without Appearance Seizure + + In this scenario, Bob's UA places a call without first selecting/ + seizing an appearance number. After Bob sends the INVITE, the + appearance assigns an appearance number for it and notifies both + Alice and Bob. + + + Carol Proxy Alice Appearance Agent Bob + | | | | | + | | | | | + | |<------------------------------------- INVITE F1<| + | | | | | + | |>F2 100 Trying --------------------------------->| + + + +Johnston, et al. Standards Track [Page 35] + +RFC 7463 SIP Shared Appearances March 2015 + + + |<-- INVITE F3<| | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<-- NOTIFY F4<| | + | | | | | + | | |>F5 200 OK -->| | + | | | |------- NOTIFY F6>| + | | | | | + | | | |<F7 200 OK ------<| + |>F8 180 ---->| | | | + | |>F9 180 Ringing -------------------------------->| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F10<| | + | | | | | + | | |>F11 200 OK ->| | + | | | |------ NOTIFY F12>| + | | | | | + | | | |<F13 200 OK -----<| + |>F14 200 OK ->| | | | + | |>F15 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F16<| + |<---- ACK F17<| | | | + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F18<| | + | | | | | + | | |>F19 200 OK ->| | + | | | |------ NOTIFY F20>| + | | | | | + | | | |<F21 200 OK -----<| + | | | | | + + Figure 3. Outgoing Call without Appearance Seizure Example + + + F1 Bob ----> Proxy + + INVITE sip:carol@example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF + From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B + To: <sip:carol@example.com> + CSeq: 1 INVITE + + + +Johnston, et al. Standards Track [Page 36] + +RFC 7463 SIP Shared Appearances March 2015 + + + Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 + Contact: <sip:bob@ua2.example.com> + Max-Forwards: 70 + Content-Type: application/sdp + Content-Length: 223 + + v=0 + o=- 1102980499 1102980499 IN IP4 ua2.example.com + s=IP SIP UA + c=IN IP4 ua2.example.com + t=0 0 + a=sendrecv + m=audio 2236 RTP/AVP 0 8 101 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:101 telephone-event/8000 + + + F4 Appearance Agent ----> Alice + + NOTIFY sip:alice@ua1.example.com SIP/2.0 + Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 + From: <sip:HelpDesk@example.com>;tag=1636248422222257 + To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E + Call-ID: ef4704d9-bb68aa0b-474c9d94 + CSeq: 233 NOTIFY + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=2200 + Contact: <sip:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="27" + state="partial" + entity="sip:HelpDesk@example.com"> + <dialog id="fa02538339df3ce597f9e3e3699e28fc" + call-id="f3b3cbd0-a2c5775e-5df9f8d5" + local-tag="15A3DE7C-9283203B" direction="initiator"> + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <state>trying</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + + + +Johnston, et al. Standards Track [Page 37] + +RFC 7463 SIP Shared Appearances March 2015 + + + </local> + </dialog> + </dialog-info> + + + F6 Appearance Agent ----> Bob + + NOTIFY sip:bob@ua1.example.com SIP/2.0 + From: <sip:HelpDesk@example.com>;tag=497585728578386 + To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 + Call-ID: a7d559db-d6d7dcad-311c9e3a + CSeq: 7 NOTIFY + Via: SIP/2.0/UDP appearanceagent.example.com + ;branch=z9hG4bK1711759878512309 + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=2000 + Contact: <sip:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="78" + state="partial" + entity="sip:HelpDesk@example.com"> + <dialog id="02538339hfgdf3ce597f9e3egkl3699e28fc" + call-id="f3b3cbd0-a2c5775e-5df9f8d5" + local-tag="15A3DE7C-9283203B" direction="initiator"> + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <state>trying</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + </local> + </dialog> + </dialog-info> + +11.4. Outgoing Call with Appearance Seizure + + In this scenario, Bob's UA sends out a dialog event PUBLISH with + state (trying) selecting/seizing an appearance number before sending + the INVITE. After receiving the 200 (OK) from the Appearance Agent + confirming the appearance number, Bob's UA sends the INVITE to Carol + and establishes a session. For brevity, details of some of the + messages are not included in the message flows. Bob's UA puts as + + + +Johnston, et al. Standards Track [Page 38] + +RFC 7463 SIP Shared Appearances March 2015 + + + 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 + | | | | | + | | | |<----- PUBLISH F1<| + | | | | | + | | | |>F2 200 OK ------>| + | | | | | + | | |<-- NOTIFY F3<| | + | | | | | + | | |>F4 200 OK -->| | + | | | |------- NOTIFY F5>| + | | | | | + | | | |<F6 200 OK ------<| + | | | | | + | |<------------------------------------- INVITE F7<| + | | | | | + | |>F8 100 Trying --------------------------------->| + |<-- INVITE F9<| | | | + | | | |<---- PUBLISH F10<| + | | | | | + | | | |>F11 200 OK ----->| + | | | | | + |>F12 180 --->| | | | + | |>F13 180 Ringing ------------------------------->| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F14<| | + | | | | | + | | |>F15 200 OK ->| | + | | | |------ NOTIFY F16>| + | | | | | + | | | |<F17 200 OK -----<| + |>F18 200 OK ->| | | | + | |>F19 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F20<| + |<---- ACK F21<| | | | + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F22<| | + + + +Johnston, et al. Standards Track [Page 39] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | | | | + | | |>F23 200 OK ->| | + | | | |------ NOTIFY F24>| + | | | | | + | | | |<F25 200 OK -----<| + | | | | | + + Figure 4. Outgoing Call with Appearance Seizure Example + + F1 to F4: Bob uses the shared appearance of the Help Desk on his UA + to place an outgoing call (e.g., he goes off-hook). Before sending + the outgoing INVITE request, Bob publishes to the Appearance Agent + reserving appearance number 1. The Appearance Agent notifies Alice + (and all other UAs, including Bob) of the event by sending NOTIFYs. + + + F1 Bob ----> Appearance Agent + + PUBLISH sip:HelpDesk@example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 + From: <sip:bob@example.com>;tag=44150CC6-A7B7919D + To: <sip:HelpDesk@example.com> + CSeq: 7 PUBLISH + Call-ID: 44fwF144-F12893K38424 + Contact: <sip:bob@ua2.example.com> + Event: dialog;shared + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="6" + state="full" + entity="sip:HelpDesk@example.com"> + <dialog id="id3d4f9c83" direction="initiator"> + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <state>trying</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + </local> + </dialog> + </dialog-info> + + + + + +Johnston, et al. Standards Track [Page 40] + +RFC 7463 SIP Shared Appearances March 2015 + + + F2 Appearance Agent ----> Bob + + SIP/2.0 200 OK + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 + From: <sip:bob@example.com>;tag=44150CC6-A7B7919D + To: <sip:HelpDesk@example.com> + CSeq: 7 PUBLISH + Call-ID: 44fwF144-F12893K38424 + Contact: <sip:bob@ua2.example.com> + Event: dialog;shared + SIP-Etag: 482943245 + Allow-Events: dialog + Expires: 60 + Content-Length: 0 + + + F7 Bob ---> Proxy + + INVITE sip:carol@example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122 + Max-Forwards: 70 + From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B + To: <sip:carol@example.com> + Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 + CSeq: 31 INVITE + Contact: <sip:bob@ua2.example.com> + Content-Type: application/sdp + Content-Length: ... + + (SDP Not Shown) + + + F10 Bob ----> Appearance Agent + + PUBLISH sip:HelpDesk@example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 + From: <sip:bob@example.com>;tag=0CCf6-A7FdsB79D + To: <sip:HelpDesk@example.com> + CSeq: 437 PUBLISH + Call-ID: fwF14d4-F1FFF2F2893K38424 + Contact: <sip:bob@ua2.example.com> + Event: dialog;shared + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + + + +Johnston, et al. Standards Track [Page 41] + +RFC 7463 SIP Shared Appearances March 2015 + + + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="6" + state="full" + entity="sip:HelpDesk@example.com"> + <dialog id="id3d4f9c83" + call-id="f3b3cbd0-a2c5775e-5df9f8d5" + local-tag="15A3DE7C-9283203B" + direction="initiator"> + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <state>trying</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + </local> + <remote> + <identity uri="sip:carol@example.com"> + </identity> + </remote> + </dialog> + </dialog-info> + +11.5. Outgoing Call without Using an Appearance Number + + In this scenario, Bob's UA sends out a dialog event PUBLISH with + state (trying) indicating that he does not want to utilize an + appearance number for this dialog. The PUBLISH does not have an + appearance element but does have the 'shared' Event header field + parameter. As a result, the Appearance Agent knows the UA does not + wish to use an appearance number for this call. If the Appearance + Agent does not wish to allow this, it would reject the PUBLISH with a + 400 (Bad Request) response and the UA would know to re-PUBLISH + selecting/seizing an appearance number. + + Carol Proxy Alice Appearance Agent Bob + | | | | | + | | | |<----- PUBLISH F1<| + | | | | | + | | | |>F2 200 OK ------>| + | | | | | + | | |<-- NOTIFY F3<| | + | | | | | + | | |>F4 200 OK -->| | + | | | |------- NOTIFY F5>| + | | | | | + | | | |<F6 200 OK ------<| + | | | | | + | |<------------------------------------- INVITE F7<| + + + +Johnston, et al. Standards Track [Page 42] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | | | | + | |>F8 100 Trying --------------------------------->| + |<-- INVITE F9<| | | | + | | | |<---- PUBLISH F10<| + | | | | | + | | | |>F11 200 OK ----->| + | | | | | + |>F12 180 --->| | | | + | |>F13 180 Ringing ------------------------------->| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F14<| | + | | | | | + | | |>F15 200 OK ->| | + | | | |------ NOTIFY F16>| + | | | | | + | | | |<F17 200 OK -----<| + |>F18 200 OK ->| | | | + | |>F19 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F20<| + |<---- ACK F21<| | | | + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F22<| | + | | | | | + | | |>F23 200 OK ->| | + | | | |------ NOTIFY F24>| + | | | | | + | | | |<F25 200 OK -----<| + | | | | | + + Figure 5. Outgoing Call without using an Appearance Number Example + + + F1 Bob ----> Appearance Agent + + PUBLISH sip:appearanceagent.example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 + From: <sip:bob@example.com>;tag=4415df82k39sf + To: <sip:HelpDesk@example.com> + CSeq: 7 PUBLISH + Call-ID: 44fwF144-F12893K38424 + Contact: <sip:bob@ua2.example.com> + + + +Johnston, et al. Standards Track [Page 43] + +RFC 7463 SIP Shared Appearances March 2015 + + + Event: dialog;shared + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="6" + state="full" + entity="sip:HelpDesk@example.com"> + <dialog id="id3d4f9c83" direction="initiator"> + <sa:exclusive>false</sa:exclusive> + <state>trying</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + </local> + </dialog> + </dialog-info> + + Note that F7 would be the same as the previous example. + +11.6. Appearance Release + + Bob and Carol are in a dialog, created, for example as in + Section 11.3. Carol sends a BYE to Bob to terminate the dialog and + the Appearance Agent de-allocates the appearance number used, sending + notifications out to the UAs in the shared group. + + Carol Proxy Alice Appearance Agent Bob + | | | | | + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + |>F22 BYE ---->| | | | + | |>F23 BYE --------------------------------------->| + | | | | | + | |<------------------------------------ 200 OK F24<| + |<--200 OK F25<| | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F26<| | + | | | | | + | | |>F27 200 OK ->| | + | | | |------ NOTIFY F28>| + | | | | | + | | | |<F29 200 OK -----<| + + + +Johnston, et al. Standards Track [Page 44] + +RFC 7463 SIP Shared Appearances March 2015 + + + Figure 6. Appearance Release Example + + F28 Appearance Agent ----> Bob + + NOTIFY sip:bob@ua1.example.com SIP/2.0 + From: <sip:HelpDesk@example.com>;tag=497585728578386 + To: <sip:bob@example.com> + Call-ID: a7d559db-d6d7dcad-311c9e3a + CSeq: 7 NOTIFY + Via: SIP/2.0/UDP appearanceagent.example.com + ;branch=z9hG4bK759878512309 + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=1800 + Contact: <sip:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="27" + state="partial" + entity="sip:HelpDesk@example.com"> + <dialog id="fa02538339df3ce597f9e3e3699e28fc" + call-id="f3b3cbd0-a2c5775e-5df9f8d5" + local-tag="15A3DE7C-9283203B" + remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c" + direction="initiator"> + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <state>terminated</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + </local> + </dialog> + </dialog-info> + + +11.7. Appearance Pickup + + In this scenario, Bob has an established dialog with Carol created + using the call flows of Figures 1 or 2. Bob then places Carol on + hold. Alice receives a notification of this and renders this on + Alice's UI. Alice subsequently picks up the held call and has a + established session with Carol. Finally, Carol hangs up. Alice must + PUBLISH F32 to indicate that the INVITE F38 will be an attempt to + + + +Johnston, et al. Standards Track [Page 45] + +RFC 7463 SIP Shared Appearances March 2015 + + + pickup the dialog between Carol and Bob and, hence, may use the same + appearance number. This example also shows Secure SIP (sips) being + used. + + Carol Proxy Alice Appearance Agent Bob + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + | |<------------------------------(hold) INVITE F22<| + |<- INVITE F23<| | | | + | | | | | + |>F24 200 OK ->| | | | + | |>F25 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F26<| + |<---- ACK F27<| | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F28<| | + | | | | | + | | |>F29 200 OK ->| | + | | | |>F30 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F31<| + | | | | | + | | Alice decides to pick up the call | + | | | | | + | | |>F32 PUBLISH->| | + | | | | | + | | |<- 200 OK F33<| | + | | | | | + | | |<- NOTIFY F34<| | + | | | | | + | | |>F35 200 OK ->| | + | | | |>F36 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F37<| + | |<-- INVITE F38<| | | + |<- INVITE F39<|(w/ Replaces) | | | + |( w/ Replaces)| | | | + |>F40 200 OK ->| | | | + | |>F41 200 OK -->| | | + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | | |>F42 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F43<| + + + +Johnston, et al. Standards Track [Page 46] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | |<- NOTIFY F44<| | + | | | | | + | | |>F45 200 OK ->| | + | | | | | + | |<----- ACK F46<| | | + |<---- ACK F47<| | | | + | | | | | + |<= Both way RTP established =>| | | + | | | | | + |>F48 BYE ---->| | | | + | |>F49 BYE --------------------------------------->| + | | | | | + | |<------------------------------------ OK 200 F50<| + |<- 200 OK F51<| | | | + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F52<| | + | | | | | + | | |>F53 200 OK ->| | + | | | | | + | | | |>F54 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F55<| + + Figure 7. Appearance Pickup Example + + + F28 Appearance ----> Alice + + NOTIFY sips:alice@ua1.example.com SIP/2.0 + From: <sips:HelpDesk@example.com>;tag=151702541050937 + To: <sips:alice@example.com>;tag=18433323-C3D237CE + Call-ID: 1e361d2f-a9f51109-bafe31d4 + CSeq: 12 NOTIFY + Via: SIP/2.0/TLS appearanceagent.example.com + ;branch=z9hG4bK1403 + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=1800 + Contact: <sips:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="10" + + + +Johnston, et al. Standards Track [Page 47] + +RFC 7463 SIP Shared Appearances March 2015 + + + state="partial" + entity="sips:HelpDesk@example.com"> + <dialog id="id3d4f9c83" + call-id="f3b3cbd0-a2c5775e-5df9f8d5" + local-tag="15A3DE7C-9283203B" + remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c" + direction="initiator"> + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <state>active</state> + <local> + <target uri="sips:bob@ua2.example.com"> + <param pname="+sip.rendering" pval="no"/> + </target> + </local> + <remote> + <identity>sips:carol@example.com</identity> + <target uri="sips:carol@ua3.example.com" /> + </remote> + </dialog> + </dialog-info> + + + F32 Alice ----> Appearance Agent + + PUBLISH sips:HelpDesk@example.com SIP/2.0 + Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A + From: <sips:HelpDesk@example.com>;tag=44150CC6-A7B7919D + To: <sips:alice@example.com>;tag=428765950880801 + CSeq: 11 PUBLISH + Call-ID: 87837Fkw87asfds + Contact: <sips:alice@ua2.example.com> + Event: dialog;shared + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="10" + state="full" + entity="sips:HelpDesk@example.com"> + <dialog id="id3d4f9c83" + call-id="3d57cd17-47deb849-dca8b6c6" + local-tag="8C4183CB-BCEAB710" > + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + + + +Johnston, et al. Standards Track [Page 48] + +RFC 7463 SIP Shared Appearances March 2015 + + + <sa:replaced-dialog + call-id="f3b3cbd0-a2c5775e-5df9f8d5" + from-tag="15A3DE7C-9283203B" + to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" /> + <state>trying</state> + <local> + <target uri="sips:alice@ua1.example.com"> + <param pname="+sip.rendering" pval="yes"/> + </target> + </local> + <remote> + <target uri="sips:carol@ua3.example.com" /> + </remote> + </dialog> + </dialog-info> + + + F38 Alice ----> Proxy + + INVITE sips:carol@example.com SIP/2.0 + Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK4ea695b5B376A60C + From: <sips:HelpDesk@example.com>;tag=8C4183CB-BCEAB710 + To: <sips:carol@example.com:5075> + CSeq: 1 INVITE + Call-ID: 3d57cd17-47deb849-dca8b6c6 + Contact: <sips:alice@ua1.example.com> + <all-one-line> + Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c + -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B + </all-one-line> + Max-Forwards: 70 + Content-Type: application/sdp + Content-Length: 223 + + v=0 + o=- 1102980497 1102980497 IN IP4 ua1.example.com + s=IP SIP UA + c=IN IP4 ua1.example.com + t=0 0 + a=sendrecv + m=audio 2238 RTP/AVP 0 8 101 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:101 telephone-event/8000 + + + + + + + +Johnston, et al. Standards Track [Page 49] + +RFC 7463 SIP Shared Appearances March 2015 + + +11.8. Call between UAs within the Group + + In this scenario, Bob calls Alice who is also in the shared + appearance group. Only one appearance number is used for this + dialog. This example also shows the use of the 'exclusive' tag to + indicate that other UAs in the group can not join or take this + dialog. + + Carol Proxy Alice Appearance Agent Bob + | | | | | + | |<-------------------- INVITE (to Alice's UA) F1<| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | | | | + | | |<-- NOTIFY F2<| | + | | | | | + | | |>F3 200 OK -->| | + | | | |>F4 NOTIFY ------>| + | | | | | + | | | |<------ 200 OK F5<| + | |>F6 INVITE --->| | | + | | (appearance=1)| | | + | | | | | + | |<------ 180 F7<| | | + | | | | | + | |>F8 180 --------------------------------------->| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<-- NOTIFY F9<| | + | | | | | + | | |>F10 200 OK ->| | + | | | |>F11 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F12<| + | |<-- 200 OK F13<| | | + | | | | | + | |>F14 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F15<| + | | | | | + | |>F16 ACK ----->| | | + | | | | | + | | |<======= RTP established =======>| + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + + + +Johnston, et al. Standards Track [Page 50] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | |<- NOTIFY F17<| | + | | | | | + | | |>F18 200 OK ->| | + | | | |>F19 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F24<| + | | | | | + + Figure 8. Call between UAs within the Group Example + + + F19 Appearance Agent ----> Bob + + NOTIFY sip:bob@ua1.example.com SIP/2.0 + From: <sip:HelpDesk@example.com>;tag=497585728578386 + To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 + Call-ID: a7d559db-d6d7dcad-311c9e3a + CSeq: 7 NOTIFY + Via: SIP/2.0/UDP appearanceagent.example.com + ;branch=z9hG4bK1711759878512309 + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Event: dialog;shared + Subscription-State: active;expires=1500 + Contact: <sip:appearanceagent.example.com> + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="10" + state="partial" + entity="sip:HelpDesk@example.com"> + <dialog id="3xdsd4f9c83" + call-id="b3cbd0-ad2c5775e-5df9f8d5" + local-tag="34322kdfr234f" + remote-tag="3153DE7C-928203B" + direction="initiator"> + <sa:exclusive>true</sa:exclusive> + <sa:appearance>1</sa:appearance> + <state>confirmed</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + </local> + <remote> + <identity>sip:HelpDesk@example.com</identity> + <target uri="sip:alice@ua1.example.com" /> + + + +Johnston, et al. Standards Track [Page 51] + +RFC 7463 SIP Shared Appearances March 2015 + + + </remote> + </dialog> + + <dialog id="4839589" + call-id="b3cbd0-ad2c5775e-5df9f8d5" + local-tag="3153DE7C-928203B" + remote-tag="34322kdfr234f" + direction="responder"> + <sa:exclusive>true</sa:exclusive> + <sa:appearance>1</sa:appearance> + <state>confirmed</state> + <local> + <target uri="sip:alice@ua1.example.com" /> + </local> + <remote> + <identity>sip:HelpDesk@example.com</identity> + <target uri="sip:bob@ua2.example.com" /> + </remote> + </dialog> + + </dialog-info> + +11.9. Consultation Hold with Appearances + + In this scenario, Bob has a call with Carol. Bob makes a + consultation call to Alice by putting Carol on hold and calling + 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. + He indicates this in the PUBLISH F32, which contains the 'shared' + Event header field parameter but no <appearance> element. The + PUBLISH is sent before the INVITE to Alice to ensure no appearance + number is assigned by the Appearance Agent. Finally, Bob hangs up + with Alice and resumes the call with Carol. Dialog notifications of + the consultation call are not shown, as they are not used. + + 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 + for the call with Alice. If not, Bob publishes the termination of + the dialog with Carol and the Appearance Agent will re-allocate the + appearance. If he wants to keep the appearance, Bob will publish the + termination of the dialog with Carol and also publish the appearance + with the dialog with Alice. This will result in Bob keeping the + appearance number until he reports the dialog with Alice terminated. + + Note that the call flow would be similar if Bob called a music on + hold server instead of Alice to implement a music on hold service as + described in [RFC7088]. + + + + +Johnston, et al. Standards Track [Page 52] + +RFC 7463 SIP Shared Appearances March 2015 + + + Carol Proxy Alice Appearance Agent Bob + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + | |<------------------------------(hold) INVITE F22<| + |<- INVITE F23<| | | | + | | | | | + |>F24 200 OK ->| | | | + | |>F25 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F26<| + |<---- ACK F27<| | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F28<| | + | | | | | + | | |>F29 200 OK ->| | + | | | |>F30 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F31<| + | | | | | + | | Bob makes a consultation call to Alice | + | | | | | + | | | |<---- PUBLISH F32<| + | | | | | + | | | |>F33 200 OK ----->| + | | | | | + | |<------------------------------------ INVITE F34<| + | | | | | + | |>F35 INVITE -->| | | + | | | | | + | |<-- 200 OK F36<| | | + | | | | | + | |>F37 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F38<| + | | | | | + | |>F39 ACK ----->| | | + | | | | | + | | |<======= RTP established =======>| + | | | | | + | | Bob hangs up with Alice | + | | | | | + | |<--------------------------------------- BYE F40<| + | | | | | + | |>F41 BYE ----->| | | + | | | | | + | |<-- 200 OK F42<| | | + + + +Johnston, et al. Standards Track [Page 53] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | | | | + | |>F43 200 OK ------------------------------------>| + | | | | | + | |<----------------------------(unhold) INVITE F44<| + |<- INVITE F45<| | | | + | | | | | + |>F46 200 OK ->| | | | + | |>F47 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F48<| + |<---- ACK F49<| | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F50<| | + | | | | | + | | |>F51 200 OK ->| | + | | | |>F52 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F53<| + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + + Figure 9. Consultation Hold with Appearances Example + + F32 Bob ----> Appearance Agent + + PUBLISH sip:HelpDesk@example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A + From: <sip:bob@example.com>;tag=44150CC6-A7B7919D + To: <sip:HelpDesk@example.com>;tag=428765950880801 + CSeq: 11 PUBLISH + Call-ID: 44fwF144-F12893K38424 + Contact: <sip:bob@ua2.example.com> + Event: dialog;shared + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="10" + state="full" + entity="sip:HelpDesk@example.com"> + <dialog id="id3d4f9c83" + call-id="b3cbd0-ad2c5775e-5df9f8d5" + local-tag="3153DE7C-928203B" + + + +Johnston, et al. Standards Track [Page 54] + +RFC 7463 SIP Shared Appearances March 2015 + + + direction="initiator"> + <sa:exclusive>true</sa:exclusive> + <state>trying</state> + <local> + <target uri="sip:bob@ua2.example.com"> + </target> + </local> + <remote> + <identity>sip:HelpDesk@example.com</identity> + <target uri="sip:alice@ua1.example.com" /> + </remote> + </dialog> + </dialog-info> + +11.10. Joining or Bridging an Appearance + + In this call flow, a call answered by Bob is joined by Alice or + "bridged". The Join header field is used by Alice to request this + bridging. If Bob did not support media mixing, Bob could obtain + conferencing resources as described in [RFC4579]. + + Carol Forking Proxy Appearance Agent Alice Bob + | | | | | + |<=============Both way RTP established===========>| + | | | | | + | | |< PUBLISH F22| | + | | | | | + | | |>F23 200 OK >| | + | | | | | + | |<---- INVITE (w/ Join) F24<| | + | | | | | + | |>F25 INVITE (w/Join)---------------->| + | | | | | + | |<---- OK 200 Contact:Bob;isfocus F26<| + | | | | | + | |< - - - - - >| | | + | | | | | + | | |>F27 NOTIFY >| | + | | | | | + | | |< 200 OK F28<| | + | | | | | + | | |>F29 NOTIFY ---------->| + | | | | | + | | |<F30 200 OK ----------<| + | | | | | + | |>F31 200 OK Contact:B----->| | + | | | | | + | |<----------------- ACK F32<| | + + + +Johnston, et al. Standards Track [Page 55] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | | | | + | |>ACK F33---------------------------->| + | | | | | + | |<-----INVITE Contact:Bob;isfocus F34<| + |<-INVITE F35| | | | + | | | | | + |>F26 200 -->| | | | + | |>F37 200 OK ------------------------>| + | | | | | + | |<--------------------------- ACK F38<| + |<--- ACK F39| | | | + | | | |<==RTP==>| + |<=============Both way RTP established===========>| + | | | | | + | |< - - - - - >| | | + | | | | | + | | |>F40 NOTIFY >| | + | | | | | + | | |< 200 OK F41<| | + | | | | | + | | |>F42 NOTIFY ---------->| + | | | | | + | | |<F43 200 OK ----------<| + | | | | | + + Figure 10. Joining or Bridging an Appearance Example + + F22 Alice ----> Appearance Agent + + PUBLISH sip:HelpDesk@example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A + From: <sip:alice@example.com>;tag=44150CC6-A7B7919D + To: <sip:HelpDesk@example.com>;tag=428765950880801 + CSeq: 11 PUBLISH + Call-ID: 87837Fkw87asfds + Contact: <sip:alice@ua2.example.com> + Event: dialog;shared + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="10" + state="full" + entity="sip:HelpDesk@example.com:5060"> + <dialog id="id3d4f9c83" + + + +Johnston, et al. Standards Track [Page 56] + +RFC 7463 SIP Shared Appearances March 2015 + + + call-id="dc95da63-60db1abd-d5a74b48" + local-tag="605AD957-1F6305C2" > + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <sa:joined-dialog + call-id="14-1541707345" + from-tag="44BAD75D-E3128D42" + to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> + <state>trying</state> + <local> + <target uri="sip:alice@ua1.example.com"> + </target> + </local> + <remote> + <target uri="sip:bob@example.com" /> + </remote> + </dialog> + </dialog-info> + + + F24 Alice ----> Proxy + + INVITE sip:bob@ua.example.com SIP/2.0 + Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 + From: <sip:HelpDesk@example.com>;tag=605AD957-1F6305C2 + To: <sip:bob@ua.example.com> + CSeq: 2 INVITE + Call-ID: dc95da63-60db1abd-d5a74b48 + Contact: <sip:alice@ua1.example.com> + <all-one-line> + Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 + -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 + </all-one-line> + Max-Forwards: 70 + Content-Type: application/sdp + Content-Length: 223 + + v=0 + o=- 1103061265 1103061265 IN IP4 ua1.example.com + s=IP SIP UA + c=IN IP4 ua1.example.com + t=0 0 + a=sendrecv + m=audio 2236 RTP/AVP 0 8 101 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:101 telephone-event/8000 + + + + +Johnston, et al. Standards Track [Page 57] + +RFC 7463 SIP Shared Appearances March 2015 + + +11.11. Loss of Appearance during Allocation + + Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, + then becomes unreachable. When he fails to refresh his publication + to the appearance agent, the Appearance Agent declares the dialog + terminated and frees up the appearance using NOTIFYs F14 and F16. + After retransmitting the NOTIFY to Bob (in not shown messages F17, + F18, etc.), the subscription is terminated. + + Carol Proxy Alice Appearance Agent Bob + | | | | | + | | | |<----- PUBLISH F1<| + | | | | | + | | | |>F2 200 OK ------>| + | | | | | + | | |<-- NOTIFY F3<| | + | | | | | + | | |>F4 200 OK -->| | + | | | |------- NOTIFY F5>| + | | | | | + | | | |<F6 200 OK ------<| + | | | | | + | |<------------------------------------- INVITE F7<| + | | | | | + | |>F8 100 Trying --------------------------------->| + |<-- INVITE F9<| | | | + | | | |<---- PUBLISH F10<| + | | | | | + | | | |>F11 200 OK ----->| + | | | | | + |>F12 180 --->| | | | + | |>F13 180 Ringing ------------------------------->| + | | | | | + | | | | Bob goes offline | + | | | | | + | | | Appearance selection times out | + | | | | | + | | |<- NOTIFY F14<| | + | | | | | + | | |>F15 200 OK ->| | + | | | |------ NOTIFY F16>| + | | | | | + | | | NOTIFY is retransmitted | + + Figure 11. Loss of Appearance during Allocation Example + + + + + + +Johnston, et al. Standards Track [Page 58] + +RFC 7463 SIP Shared Appearances March 2015 + + +11.12. Appearance Seizure Contention Race Condition + + Bob and Alice both try to reserve appearance 2 by publishing at the + same time. The Appearance Agent allocates the appearance to Bob by + sending a 200 OK and denies it to Alice by sending a 400 (Bad + Request) response. After the NOTIFY F5, Alice learns that Bob is + using appearance 2. Alice then attempts to reserve appearance 3 by + publishing, which is then accepted. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johnston, et al. Standards Track [Page 59] + +RFC 7463 SIP Shared Appearances March 2015 + + + Carol Proxy Alice Appearance Agent Bob + | | | | | + | | | |<----- PUBLISH F1<| + | | | | (appearance=2) + | | |>F2 PUBLISH ->| | + | | | (appearance=2) | + | | | | | + | | | |>F3 200 OK ------>| + | | |<---- F4 400 <| | + | | | | | + | | |<-- NOTIFY F5<| | + | | | | | + | | |>F6 200 OK -->| | + | | | |------- NOTIFY F7>| + | | | | | + | | | |<F8 200 OK ------<| + | | | | | + | |<------------------------------------- INVITE F9<| + | | | | | + | |>F10 100 Trying -------------------------------->| + |<- INVITE F11<| | | | + | | | |<---- PUBLISH F12<| + | | | | (appearance=2) + | | | |>F13 200 OK ----->| + | | |>F14 PUBLISH->| | + | | | (appearance=3) | + | | | | | + | | |<--- F15 200 <| | + | | | | | + | | |<- NOTIFY F16<| | + | | | | | + | | |>F17 200 OK ->| | + Dave | | |------ NOTIFY F18>| + | | | | | + | | | |<F19 200 OK -----<| + | |<-- INVITE F20<| | | + | | | | | + | |>F21 100 ----->| | | + |<- INVITE F22<| | | | + + Figure 12. Appearance Seizure Contention Race Condition Example + + +11.13. Appearance Agent Subscription to UAs + + In this scenario, the Appearance Agent does not have any way of + knowing Bob's dialog state information, except through Bob. This + could be because the Appearance Agent is not part of a B2BUA, or + + + +Johnston, et al. Standards Track [Page 60] + +RFC 7463 SIP Shared Appearances March 2015 + + + perhaps Bob is remotely registering. When Bob registers, the + Appearance Agent receives a registration event package notification + from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's + dialog event state using Event:dialog in the SUBSCRIBE. Whenever + Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance + Agent which then notifies the other UAs in the group. + + Carol Proxy Alice Appearance Agent Bob + | | | | | + | |<----------------------------------- REGISTER F1<| + | | | | | + | |>F2 200 OK ------------------------------------->| + | | | | | + | |>F3 NOTIFY ------------------>| | + | | | | | + | |<------------------ 200 OK F4<| | + | | | |---- SUBSCRIBE F5>| + | | | | | + | | | |<F6 200 OK ------<| + | | | | | + | | | |<------ NOTIFY F7<| + | | | | | + | | | |>F8 200 OK ------>| + | | | | | + | | | |<--- SUBSCRIBE F9<| + | | | | | + | | | |>F10 200 OK ----->| + | | | | | + | | | |------ NOTIFY F11>| + | | | | | + | | | |<F12 200 OK -----<| + | | | | | + | |<------------------------------------ INVITE F13<| + | | | | | + | |>F14 100 Trying -------------------------------->| + |<- INVITE F15<| | | | + | | | |<----- NOTIFY F16<| + | | | | | + | | | |>F17 200 OK ----->| + | | |<- NOTIFY F18<| | + | | | | | + | | |>F19 200 OK ->| | + | | | |------ NOTIFY F20>| + | | | | | + | | | |<F21 200 OK -----<| + |>F22 180 --->| | | | + | |>F23 180 Ringing ------------------------------->| + | | | | | + + + +Johnston, et al. Standards Track [Page 61] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | | |<----- NOTIFY F24<| + | | | | | + | | | |>F25 200 OK ----->| + | | |<- NOTIFY F26<| | + | | | | | + | | |>F27 200 OK ->| | + | | | |------ NOTIFY F28>| + | | | | | + | | | |<F29 200 OK -----<| + |>F30 200 OK ->| | | | + | |>F31 200 OK ------------------------------------>| + | | | | | + | | | |<----- NOTIFY F32<| + | | | | | + | | | |>F33 200 OK ----->| + | | | | | + | |<--------------------------------------- ACK F34<| + |<---- ACK F35<| | | | + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + | | |<- NOTIFY F36<| | + | | | | | + | | |>F37 200 OK ->| | + | | | |------ NOTIFY F38>| + | | | | | + | | | |<F39 200 OK -----<| + | | | | | + + Figure 13. Appearance Agent Subscription to UAs Example + + +11.14. Appearance Pickup Race Condition Failure + + In this scenario, Bob has an established dialog with Carol created + using the call flows of Figure 1 or Figure 2. Bob then places Carol + on hold. Alice receives a notification of this and renders this on + Alice's UI. Alice attempts to pick up the call but Carol hangs up + before the pickup can complete. Alice cancels the pickup attempt + with the PUBLISH F48. Note that the call flow for a failed Join + would be almost identical. + + Carol Proxy Alice Appearance Agent Bob + | | | | | + |<================= Both way RTP established ===================>| + | | | | | + | |<------------------------------(hold) INVITE F22<| + |<- INVITE F23<| | | | + + + +Johnston, et al. Standards Track [Page 62] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | | | | + |>F24 200 OK ->| | | | + | |>F25 200 OK ------------------------------------>| + | | | | | + | |<--------------------------------------- ACK F26<| + |<---- ACK F27<| | | | + | | | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |<- NOTIFY F28<| | + | | | | | + | | |>F29 200 OK ->| | + | | | |>F30 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F31<| + | | | | | + | | Alice decides to pick up the call | + | | | | | + | | |>F32 PUBLISH->| | + | | | | | + | | |<- 200 OK F33<| | + | | | | | + | | |<- NOTIFY F34<| | + | | | | | + | | |>F35 200 OK ->| | + | | | |>F36 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F37<| + |>F38 BYE ---->| | | | + | |>F39 BYE --------------------------------------->| + | | | | | + | |<------------------------------------ OK 200 F40<| + |<- 200 OK F41<| | | | + | |<-- INVITE F42<| | | + |<- INVITE F43<|(w/ Replaces) | | | + |( w/ Replaces)| | | | + | | | | | + |>F44 481 ---->| | | | + | |>F45 481 ----->| | | + |<---- ACK F46<| | | | + | |<----- ACK F47<| | | + | | |>F48 PUBLISH->| | + | | | | | + | | |<- 200 OK F49<| | + | | | | | + | | |<- NOTIFY F50<| | + | | | | | + | | |>F51 200 OK ->| | + + + +Johnston, et al. Standards Track [Page 63] + +RFC 7463 SIP Shared Appearances March 2015 + + + | | | |>F52 NOTIFY ----->| + | | | | | + | | | |<----- 200 OK F53<| + + Figure 14. Appearance Pickup Race Condition Failure Example + + F48 Alice ----> Appearance Agent + + PUBLISH sip:HelpDesk@example.com SIP/2.0 + Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A + From: <sip:alice@example.com>;tag=44150CC6-A7B7919D + To: <sip:HelpDesk@example.com>;tag=428765950880801 + CSeq: 11 PUBLISH + Call-ID: 87837Fkw87asfds + Contact: <sip:alice@ua2.example.com> + Event: dialog;shared + Max-Forwards: 70 + Content-Type: application/dialog-info+xml + Content-Length: ... + + <?xml version="1.0"?> + <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" + xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info" + version="10" + state="full" + entity="sip:HelpDesk@example.com"> + <dialog id="id3d4f9c83" + call-id="dc95da63-60db1abd-d5a74b48" + local-tag="605AD957-1F6305C2" > + <sa:appearance>1</sa:appearance> + <sa:exclusive>false</sa:exclusive> + <sa:replaced-dialog + call-id="14-1541707345" + from-tag="44BAD75D-E3128D42" + to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> + <state>terminated</state> + <local> + <target uri="sip:alice@ua1.example.com"> + </target> + </local> + <remote> + <target uri="sip:carol@ua3.example.com" /> + </remote> + </dialog> + </dialog-info> + + + + + + +Johnston, et al. Standards Track [Page 64] + +RFC 7463 SIP Shared Appearances March 2015 + + +11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition + + Alice tries to seize appearance 2 at the same time appearance 2 is + allocated to an incoming call. The Appearance Agent resolves the + conflict by sending a 400 (Bad Request) to Alice. After the NOTIFY + F6, Alice learns that the incoming call is using appearance 2. Alice + republishes for appearance 3, which is accepted. Note that this + example shows the INVITE being received before the NOTIFY from the + Appearance Agent. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johnston, et al. Standards Track [Page 65] + +RFC 7463 SIP Shared Appearances March 2015 + + + Carol Proxy Alice Appearance Agent Bob + | | | | | + |>-- INVITE F1>| | | | + | |< - - - - - - - - - - - - - ->| | + | | | | | + | | |>F2 PUBLISH ->| | + | | | (appearance=2) | + | | | | | + | |>F3 INVITE (appearance=2) ---------------------->| + | | | | | + | |>F4 INVITE | | | + | |(appearance=2)>| | | + | | |<---- F5 400 <| | + | | | | | + | | |<-- NOTIFY F6<| | + | | | | | + | | |>F7 200 OK -->| | + | | | |------- NOTIFY F8>| + | | | | | + | | | |<F9 200 OK ------<| + | | | | | + | | |>F10 PUBLISH->| | + | | | (appearance=3) | + | | | | | + | | |< F11 200 OK <| | + | | | | | + | | |<- NOTIFY F12<| | + | | | | | + | |>F13 200 OK ->| | + Dave | | |------ NOTIFY F14>| + | | | | | + | | | |<F15 200 OK -----<| + | |<-- INVITE F16<| | | + | | | | | + | |>F17 100 ----->| | | + |<- INVITE F18<| | | | + + Figure 15. Appearance Seizure Incoming/Outgoing Contention + Race Condition Example + + +12. Security Considerations + + Since multiple line appearance features are implemented using + semantics provided by SIP [RFC3261], the SIP Event Package for Dialog + State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903], + security considerations in these documents apply to this document as + well. + + + +Johnston, et al. Standards Track [Page 66] + +RFC 7463 SIP Shared Appearances March 2015 + + + To provide confidentiality, NOTIFY or PUBLISH message bodies that + provide the dialog state information and the dialog identifiers MAY + be encrypted end-to-end using the standard mechanisms such as S/MIME + described in [RFC3261]. Alternatively, sending the NOTIFY and + PUBLISH requests over TLS also provides confidentiality, although on + a hop-by-hop basis. All SUBSCRIBEs and PUBLISHes between the UAs and + the Appearance Agent MUST be authenticated. Without proper + authentication and confidentiality, 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. + + This feature relies on standard SIP call control primitives such as + Replaces and Join. Proper access controls on their use MUST be used + so that only members of the shared appearance group can use these + mechanisms. 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. + Otherwise, a third party could disrupt or hijack existing dialogs in + the shared appearance group. + + For an emergency call, a UA MUST NOT wait for a confirmed seizure of + an appearance before sending an INVITE. Waiting for confirmation + could inadvertently delay or block the emergency call, which by its + nature needs to be placed as expeditiously as possible. Instead, a + emergency call MUST proceed regardless of the status of the PUBLISH + transaction. + +13. IANA Considerations + + This section registers the SIP Event header field parameter 'shared', + the SIP Alert-Info header field parameter 'appearance', and the XML + namespace extensions to the SIP Dialog Package. + +13.1. SIP Event Header Field Parameter: shared + + This document defines the 'shared' header field parameter in the + Event header field in the "Header Field Parameters and Parameter + Values" registry defined by [RFC3968]. + + Predefined + Header Field Parameter Name Values Reference + ---------------------------- ------------------ ---------- --------- + Event shared No RFC 7463 + + + + + + +Johnston, et al. Standards Track [Page 67] + +RFC 7463 SIP Shared Appearances March 2015 + + +13.2. SIP Alert-Info Header Field Parameter: appearance + + This document defines the 'appearance' parameter in the Alert-Info + header in the "Header Field Parameters and Parameter Values" registry + defined by [RFC3968]. + + Predefined + Header Field Parameter Name Values Reference + ---------------------- --------------- --------- --------- + Alert-Info appearance No RFC 7463 + +13.3. URN Sub-Namespace Registration: sa-dialog-info + + This section registers a new XML namespace per the procedures in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:sa-dialog-info. + + Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, + Alan Johnston <alan.b.johnston@gmail.com> + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>Shared Appearance Dialog Information Namespace</title> + </head> + <body> + <h1>Namespace for Shared Appearance Dialog Information</h1> + <h2>urn:ietf:params:xml:ns:sa-dialog-info</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7463.txt"> + RFC 7463</a>.</p> + </body> + </html> + END + +13.4. XML Schema Registration + + This section registers an XML schema per the procedures in [RFC3688]. + + + + + + +Johnston, et al. Standards Track [Page 68] + +RFC 7463 SIP Shared Appearances March 2015 + + + URI: urn:ietf:params:xml:schesa:sa-dialog-info. + + Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, + Alan Johnston <alan.b.johnston@gmail.com> + + The XML for this schema can be found in Section 6. + + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002, <http://www.rfc-editor.org/info/rfc3261>. + + [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, April 2003, + <http://www.rfc-editor.org/info/rfc3515>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004, <http://www.rfc-editor.org/info/rfc3688>. + + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + Initiation Protocol (SIP)", RFC 3840, August 2004, + <http://www.rfc-editor.org/info/rfc3840>. + + [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation + Protocol (SIP) "Replaces" Header", RFC 3891, September + 2004, <http://www.rfc-editor.org/info/rfc3891>. + + [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension + for Event State Publication", RFC 3903, October 2004, + <http://www.rfc-editor.org/info/rfc3903>. + + [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol + (SIP) "Join" Header", RFC 3911, October 2004, + <http://www.rfc-editor.org/info/rfc3911>. + + + + + + + +Johnston, et al. Standards Track [Page 69] + +RFC 7463 SIP Shared Appearances March 2015 + + + [RFC3968] Camarillo, G., "The Internet Assigned Number Authority + (IANA) Header Field Parameter Registry for the Session + Initiation Protocol (SIP)", BCP 98, RFC 3968, December + 2004, <http://www.rfc-editor.org/info/rfc3968>. + + [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- + Initiated Dialog Event Package for the Session Initiation + Protocol (SIP)", RFC 4235, November 2005, + <http://www.rfc-editor.org/info/rfc4235>. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008, + <http://www.rfc-editor.org/info/rfc5234>. + + [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, + July 2012, <http://www.rfc-editor.org/info/rfc6665>. + + [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and + P. Kyzivat, "URNs for the Alert-Info Header Field of the + Session Initiation Protocol (SIP)", RFC 7462, March 2015, + <http://www.rfc-editor.org/info/rfc7462>. + +14.2. Informative References + + [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event + Package for Registrations", RFC 3680, March 2004, + <http://www.rfc-editor.org/info/rfc3680>. + + [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol + (SIP) Call Control - Conferencing for User Agents", BCP + 119, RFC 4579, August 2006, + <http://www.rfc-editor.org/info/rfc4579>. + + [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and + K. Summers, "Session Initiation Protocol Service + Examples", BCP 144, RFC 5359, October 2008, + <http://www.rfc-editor.org/info/rfc5359>. + + [RFC7088] Worley, D., "Session Initiation Protocol Service Example + -- Music on Hold", RFC 7088, February 2014, + <http://www.rfc-editor.org/info/rfc7088>. + + + + + + + + + + +Johnston, et al. Standards Track [Page 70] + +RFC 7463 SIP Shared Appearances March 2015 + + +Acknowledgements + + The following individuals were part of the shared appearance design + team and have provided input and text to the document (in + alphabetical order): + + Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek + MacDonald, Bill Mitchell, Michael Procter, and Theo Zourzouvillys. + + Thanks to Chris Boulton for helping with the XML schema. + + Much of the material has been drawn from previous work by Mohsen + Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, and Anil Kumar, + who in turn received assistance from: + + Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems; + Steve Towlson and Michael Procter of Citel Technologies; Rob + Harder and Hong Chen of Polycom, Inc.; John Elwell and JD Smith of + Siemens Communications; Dale R. Worley of Pingtel; and Graeme + Dollar of Yahoo, Inc. + + Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, + Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their + comments. + + Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji + Chinnappa, and Harsh Mendiratta for their detailed review of the + document. + +Authors' Addresses + + Alan Johnston (editor) + Avaya + St. Louis, MO + United States + + EMail: alan.b.johnston@gmail.com + + + Mohsen Soroushnejad (editor) + Sylantro Systems Corp. + + EMail: msoroush@gmail.com + + + + + + + + +Johnston, et al. Standards Track [Page 71] + +RFC 7463 SIP Shared Appearances March 2015 + + + Venkatesh Venkataramanan + Sylantro Systems Corp. + + EMail: vvenkatar@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johnston, et al. Standards Track [Page 72] |