RFC 7463
Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
Part 1 of 18 🧚✨
Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) 💖
Title block tea ☕
- RFC number: RFC 7463 🎀
- Category: Standards Track 👑
- Date: March 2015 📅
- Authors: A. Johnston (Ed.) from Avaya, M. Soroushnejad (Ed.), and V. Venkataramanan from Sylantro Systems Corp. 💅
- ISSN: 2070-1721 🦋
- Updates: RFC 3261 and RFC 4235 🔥
Okay so this one is an update to RFC 3261 and RFC 4235, not a replacement. Nothing is obsoleted here, so the older specs still exist, they just get some new details added. Bestie, that's the vibe 🫶
Abstract 🌸
Okay so this doc is about a group phone feature that goes by a few names: Bridged Line Appearance (BLA), Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA) 📞. When you build it with the Session Initiation Protocol (SIP), it gets called shared appearances of an Address of Record (AOR), because SIP doesn't actually have the concept of "lines" 🙈. You'll usually find this in IP Centrex services and IP Private Branch Exchange (IPBX) offerings, and it's likely to show up on SIP IP telephones and SIP feature servers used in business environments 💼.
The whole point is that several user agents (UAs) can share one common AOR. They can see calls placed and received by other UAs in the group, and they can pick up or join calls inside that group 🧚. The document covers use cases, lists requirements, and defines extensions to make it all work. Literally iconic 👑 This specification updates RFCs 3261 and 4235.
Status of This Memo 📝
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 💅. If you want more info on Internet Standards, check out Section 2 of RFC 5741 🦋.
For current status, errata, and how to send feedback, go to 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 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, also as described in the Simplified BSD License 🔥.
Heads up: this document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 ✨. Some of the people who own the copyright on that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🥺. Unless you get an adequate license from those copyright holders, 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. The one exceptions are formatting it for publication as an RFC or translating 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
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 . . . . . . . . . . . . . . . . . . . . . . . 71Part 1 wrap: the big stuff starts next with Section 1 (Introduction) 🦋 Stay tuned bestie 💜
1. Introduction ✨
okay so SIP user agents (UAs) for business telephony are a whole different vibe from basic SIP UAs, both in the services they offer and in the end-user experience 💅. On top of basic SIP support [RFC3261], a lot of business services need SIP extensions like REFER [RFC3515], SUBSCRIBE/NOTIFY [RFC6665], PUBLISH [RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911] header fields, etc. 🎀 Lots of the popular business services are documented in the SIP Service Examples [RFC5359].
This spec explains how to build a group telephony feature called Bridged Line Appearance (BLA) or Multiple Line Appearances (MLA) 🦋. It's one of the most popular advanced features people expect from SIP IP phones at work. Other names for it include Shared Call/Line Appearance (SCA), Shared Call Status and Multiple Call Appearance (MCA). A variant of it is called Single Line Extension.
This document looks at how to do this with standard SIP [RFC3261], plus SIP events [RFC6665] and publication [RFC3903] (carrying the SIP dialog state event package [RFC4235]) so UAs can trade status with each other 🧚.
In traditional telephony, the line is physical. A super common setup is a bunch of business phones sharing one line, or a small handful of lines 📞. That sharing, or "appearance," of lines across a bunch of phones is literally where the feature gets its name. In SIP, the equivalent is a bunch of business phones sharing a single Address of Record (AOR) URI, or a small number of them 💜.
An AOR can also have multiple appearances on one UA, at least from the user interface point of view. The appearance number is all about the phone's UI 🙈. Usually each appearance of an AOR has a visual display (a lamp that can change colour or blink, or a screen icon) and a button (used to select the appearance), and each appearance number is tied to a different dialog to or from the AOR. The line appearance idea still matters in SIP because of those UI considerations. Keeping the appearance number is important for two reasons:
- 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").
- It is a useful structure for user interface representation.
The whole point of the appearance number is to identify active calls so people can share them around (e.g., passing a call from one user to another) 🌸. If a phone has enough buttons or lamps, the appearance number could just be the button's positional sequence number. If not, it might still be desirable to show the call state, but the appearance number should be displayed so 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'll say "appearance" instead of "line appearance," since SIP doesn't have the concept of lines 🙌. That doesn't mean you have to use a conventional telephony UI (lamps and buttons). Implementations can use another metaphor as long as the appearance number is readily apparent to the user ✨. Each AOR gets its own appearance numbering space, so a given UA user interface can have multiple occurrences of the same appearance number, but they'll 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 uses of the shared appearances feature, mentioned here as informative use cases 💖. All of these can be supported by the shared appearances feature described in this document. The main differences are about the device's user interface.
3.1. Executive/Assistant Arrangement
The appearances on the executive's UA also show up on the assistant's UA 👑. The assistant can answer incoming calls to the executive and then put them on hold so the executive can pick them up. The assistant can always see the state of every call on the executive's UA 👀.
3.2. Call Group
People with similar business needs or tasks can be put into specific groups and share an AOR 🍓. For example, an IT department 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 ask to be added, joined, or bridged to an existing appearance, which ends up as a conference call 🎀.
3.3. Single Line Extension
Here, incoming calls get 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's immediately bridged or joined in with the call. This mimics the way residential telephone extensions usually work 🏠.
3.4. Changing UAs
A user is on a call on one UA and wants to switch devices and keep talking on another UA 🚶♀️. They put the call on hold, note the appearance number of the call, then walk over to another UA. They can identify the same appearance number on the other UA, pick up the call, and keep the conversation going 🌈.
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 summarised like this 📝:
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, so it can show that info 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, and it has to do so 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 take part in the shared appearance group without manual configuration of group members ✨.REQ-5:The mechanism must scale to large numbers of appearances and large numbers of UAs without causing excessive messaging traffic 📈.REQ-6:Each call or session (incoming or outgoing) should be assigned a common "appearance" number from a managed pool 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 aren't mixed or otherwise associated ⚔️.REQ-9:The mechanism must allow all UAs receiving an incoming session request to use the same appearance number at the time of alerting 🔔.REQ-10:The mechanism must have a way of rebuilding appearance state after an outage that doesn't result in excessive traffic and processing 🔄.REQ-11:The mechanism must have backwards compatibility, so a UA that's 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 isn't 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 the UA requesting it wants 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 before sending the actual request. This is often called seizure 🎯.REQ-16:The mechanism should support a way for a UA to seize a particular appearance number and 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 ✨
okay bestie, this section is non-normative 🫶, so it's ideas and suggestions, not rules. The real rules live in Section 5. Most of what this feature needs is already built from standard SIP stuff, and it's giving efficiency 💅:
- A SIP Forking Proxy and Registrar/Location Service handles REQ-1.
- The SIP Dialog Package handles REQ-2.
- The SIP Replaces and Join header fields, used together, handle REQ-3.
- A State Agent for the Dialog Package handles REQ-4 and REQ-5.
REQ-6 is where it gets interesting 👀. It suggests you need something that manages the appearance resource. Conferencing systems usually have a single point of control called a focus, and a shared appearance group works the same way: it has one point of control over the shared appearance resource. This is called an Appearance Agent for the group. An Appearance Agent can live on a centralized server, but it could also be built into a member UA that takes on that job for the group. Either way, the Appearance Agent knows, or can work out, the dialog state of every member of the group. main character energy 🎀
Could a group of UAs manage the appearance resource together with no central control at all? Maybe, but that's outside the scope of this document 🙈. It's also possible for the Appearance Agent logic to be spread across all the UAs in the group. In that case, you'd need to define and implement rules for things like assigning appearance numbers to incoming requests (e.g., lowest available appearance number) and for handling contention, like when two UAs request the same appearance number. For that one, you'd hash the dialog identifiers and compare them, with the lowest hash winning. Iconic problem-solving 😭
To best meet REQ-9, the appearance number for an incoming INVITE needs to be in the INVITE itself, not just in the dialog package NOTIFY. Why? If the NOTIFY gets delayed or lost, a UA in the group could receive an incoming INVITE and have no idea which appearance number to show during alerting. Not ideal, bestie 💀
This specification defines an extension parameter for the Alert-Info header field from RFC 3261 to carry the appearance number. It's normatively defined in Section 7. Here's what it looks like:
Alert-Info: <urn:alert:service:normal>;appearance=1Here's how the shared appearances feature actually works, step by step 🦋:
- A UA is configured with the AOR of a shared appearance group. It registers against the AOR, then tries a dialog state subscription to the AOR. If the subscription fails, loops back to itself, or returns an error, the UA knows there's no State Agent, and therefore no Appearance Agent, so this feature isn't implemented.
- If the subscription gets a 200 OK, the UA knows there's a State Agent and that the feature is implemented. The UA then follows the steps in this list. ✨
- Info about the dialog state of the other UAs in the group gets shown to the user.
- Incoming calls get forked to all UAs in the group, and any one of them can answer 📞. UAs get the appearance number to use when rendering the incoming call, both in a NOTIFY from the Appearance Agent and in the INVITE itself. A UA also gets a notification if another UA in the group answers the call, so that can be shown to the user too.
- For outgoing calls, it 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, then waits for a 2xx response before sending the INVITE. 🌸
- For outgoing calls, if the user doesn't seize a particular appearance or doesn't care, the INVITE can go out immediately. The appearance number gets learned as the call goes on, from a notification from the Appearance Agent.
- For outgoing calls, if the user doesn't want an appearance number assigned (like during a consultation call, or when a UA is fetching 'service media' such as music on hold [RFC7088]), the UA still publishes before sending the INVITE, but leaves the appearance number out of the publication.
- Established calls in the group can be joined (bridged) or taken (picked) by another UA 🔥. The info in the dialog package notifications can be used to build Join or Replaces header fields. Since the same appearance number gets used for both kinds of operation, this info gets published before the INVITE Join or INVITE Replaces is sent.
- The Appearance Agent might not have direct access to the full dialog state of some or all of the UAs in the group. If that's the case, it subscribes to the dialog state of each individual UA to get the info it needs. Either way, the Appearance Agent sends normal notifications (through the subscriptions the UAs set up in step 1) every time the aggregate dialog state of the AOR changes. That includes when calls are placed, answered, put on and taken off hold, and hung up. Literally always in the loop 👑
5. Normative Description ✨
This section is the normative part, so it's where the rules for the shared appearances feature extensions are written down 🎀. 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 Agents manage appearance numbers, and UAs that support this specification display and render them to the user. When an appearance number is assigned or requested, the assigned number is generally the smallest positive integer not currently assigned as an appearance number to a dialog for this AOR. This specification doesn't set an upper limit on appearance numbers. However, using appearance numbers that common integer representations can't easily handle is likely to cause failures 💀.
Seizing: An appearance can be reserved before a call is placed by seizing it. An appearance gets seized by communicating an artificial state of "trying" before the dialog is actually started (i.e., before the INVITE is sent), so it looks like the UA is already starting a dialog 💅.
Selecting (or Not-Seizing): An appearance is only selected (not seized) if there's no communication of that artificial "trying" state before the dialog starts. In other words, the state gets communicated when the dialog is actually started. The appearance number is learned after the INVITE is sent.
5.1. Elements
A complete system for this feature has four pieces:
- UAs that support publications, subscriptions, and notifications for the SIP dialog event package and the shared appearance dialog package extensions and behavior.
- An Appearance Agent, made up of a State Agent for the dialog event package that implements an Event State Compositor (ESC), plus the shared appearance dialog package extensions and behavior. The Appearance Agent also has the logic for assigning and releasing appearance numbers and for resolving appearance number contention. 🧚
- A forking proxy server that can talk to the State Agent.
- 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>, and they're all sub-elements of the <dialog> element 🌈.
5.2.1. The <appearance> Element
The <appearance> element is a child of the <dialog> element, and it's used to convey the appearance number of the dialog described by the parent <dialog> element. When a UA sends it in a PUBLISH to the Appearance Agent, with a parent <dialog> whose state attribute is "trying", the UA is asking for the given appearance number to be assigned to the current or future dialog with the given dialog identifiers. When the Appearance Agent sends an <appearance> element in a NOTIFY, it means 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), no matter whether the UA or the Appearance Agent is the one sending the request containing it. Specifically, if the UA sent a request within the described dialog, the To header field URI would match the <remote> <identity> value, and the to-tag parameter would match the remote-tag attribute. In the same way, 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 is a child of the <dialog> element, and it's a boolean. When it's true, it means the UA is not willing to accept an INVITE with a Join or Replaces header field targeting the dialog described by the parent <dialog> element. For example, some shared appearance systems only allow call pickup when the call is on hold. In that case, the <exclusive> element should be set to "false" when the call is held and "true" when it isn't, rather than having the "exclusive" value implied by the hold state 🙌.
Here's the important bit: this element is only a hint 🚨. To stop another UA from taking or joining a call, a UA can also avoid reporting full dialog information to the Appearance Agent. Without the full dialog information (Call-ID, remote-tag, and local-tag), another UA can't build a Join or Replaces header field. A UA can set <exclusive> to "true" and still must be ready to reject an INVITE Join for that dialog. If those dialog identifiers have already been shared with the Appearance Agent, the UA could send an INVITE Replaces to change them, then not report the new ones to the Appearance Agent.
If the proxy knows which dialogs are marked exclusive, the proxy MAY enforce that exclusivity by rejecting INVITE Join and INVITE Replaces requests that contain 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's assumed to be false. 🎀
5.2.3. The <joined-dialog> Element ✨
okay so the <joined-dialog> element is a child of the <dialog> element, and its whole job is to tell the Appearance Agent which other dialogs are joined (mixed or bridged) with this one 🎀. Only the UA that is the common endpoint of the mixed dialogs (aka the one controlling the mixing operation) should include this element in publications to the Appearance Agent 💅. And this element should still be used even when the Join header field was NOT used to join the dialogs 👀. Like, two separate dialogs on a UA could get joined with zero SIP call control operations and it still counts 🙈. 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 is also a child of the <dialog> element, and it carries the 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. 🕰️
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:
- 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). 📞
- 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). 🎶
- When the user has selected to join (or bridge) an existing call. 🤝
- 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 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 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 📞
Okay so when an INVITE gets generated to bridge or take a call (aka it has a Join or Replaces with a dialog identifier from another dialog in the shared appearance group 💅), the UA MUST first send a PUBLISH to the Appearance Agent. This PUBLISH is gonna contain:
- The appearance number of the joined or replaced call in the
<appearance>element - The dialog information from the Join header field in the
<joined-dialog>element, if the dialog is being joined - The dialog information from the Replaces header field in the
<replaced-dialog>element, if the dialog is being replaced
ngl this part is super important ✨ That info goes to the Appearance Agent so it can do proper appearance assignment. If the INVITE Join or Replaces got sent without publishing first, the Appearance Agent might hand this INVITE a brand new appearance number, and that would be a mistake 💀. With Join, the publication has the<joined-dialog>element so the Appearance Agent doesn't throw a 400 (Bad Request) just because an appearance number got reused 🙅♀️. For Replaces, the whole point of<replaced-dialog>is to stop a race condition where the BYE could cause the appearance number to get released when it should stay with the replacing dialog 🫶.
5.3.3. Appearance Numbers and Transfer 🦋
During a transfer, it is super important that the appearance number does not change. Picture Alice, a member of a shared appearance group, who is talking to Carol (who is outside the group). Carol transfers Alice to David (also outside the 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 total confusion for the user 😭. There are two possible scenarios using the terminology of RFC 5589: Alice is either the transferee in any type of transfer (she receives the REFER), or the transfer target in an attended transfer (she receives the INVITE with Replaces).
If Alice is the transferee, the triggered INVITE from the REFER gets 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 over 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. This avoids 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 keep being used even 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 💖.
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:
- A call is received, placed, answered, or terminated.
- A call is placed on or off hold.
- A call is joined or replaced.
- 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.
ngl 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 some other error condition. Even though the proper rendering of the INVITE may not be possible, it's still 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 or 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> or <replaced-dialog> element indicating that the dialog will be or 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 🚫.
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:
<?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>7. Alert-Info Appearance Parameter Definition ✨
okay so this spec extends [RFC3261] to add an appearance parameter to the Alert-Info header field 🎀 and also lets proxies modify or delete the Alert-Info header field. it's giving flexibility, bestie 💅
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*DIGITokay so a proxy that inserts an appearance Alert-Info parameter still follows its normal Alert-Info policies 📋. to show 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 there, the proxy adds the appearance parameter to that Alert-Info header field instead 🧚. if an appearance number parameter is already present (either tied to another AOR or by accident), the value gets rewritten with the new appearance number 🔄. there MUST NOT be more than one appearance parameter in an Alert-Info header field 🚫, periodt.
if no special ringtone is wanted, a normal ringtone SHOULD be indicated using urn:alert:service:normal in the Alert-Info, as per [RFC7462] 🔔. the appearance number 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 gets forwarded to another AOR, the appearance parameter in the Alert-Info SHOULD be removed before it goes 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 figure out what value it should use to fill in this parameter 🧠. for example, the proxy could fetch this information by sending a SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR, to get the list of lines that are in use 📞. or it could act like a UA that is part of the shared appearance group and SUBSCRIBE to the State-Agent like any other UA 👀. this makes sure the active dialog information is available without having to poll whenever it's needed 💖. it could also 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 is for the Proxy to first send the incoming INVITE to the Appearance Agent, which would redirect to the shared appearance group URI and escape the proper Alert-Info header field so the Proxy can recurse and distribute it 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 to do this is for the Appearance Agent to register against the AOR with a higher q value 🌟. this means the INVITE gets sent to the Appearance Agent first, then gets offered to the UAs in the group 🫶.
8. User Interface Considerations 🎀
okay so the appearance number allocated to a call is a super important concept 🌈. it lets calls get handled by multiple devices with totally different user interfaces, while users still see one consistent model. treating the appearance number carefully is essential to meet what users expect 💅. and rendering the correct call and appearance state to users matters just as much 👑.
8.1. Appearance Number Rendering
different UAs have different user interface capabilities, so it's super normal for some UAs to have restrictions that others don't 🙈. perfect interoperability across all UAs is clearly not possible, but with 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 can only display status indications for a single appearance 📱. the UA SHOULD still send messages annotated with appearance number "1" 🔢. any call indications for appearances other than number "1" SHOULD be rejected with a 480 (Temporarily Unavailable) or 486 (Busy Here) response 🙅♀️. note that this means a single appearance UA can't answer its own call to the shared AOR, since that call would use a second appearance number 💀.
8.1.2. Dual Appearance UAs
these devices are basically single appearance phones that implement call waiting 📞. they have a very simple user interface that lets them switch between two appearances (toggle or flash hook), and maybe audible tones to show the status of the other appearance 🎶. only appearance numbers "1" and "2" will be used by these UAs 🦋.
8.1.3. Shared Appearance UAs with Fixed Appearance Number
this is the typical 'business-class' hard-phone 💼. a number of appearances are usually 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 it proceeds with calls ⏳.
8.1.4. Shared Appearance UAs with Variable Appearance Numbers
this UA is typically a soft-phone or a graphically rich hard-phone 🌸. for these phones, even the idea of an appearance index might seem unnecessary 🤷♀️. but to interwork successfully with other phone types, it's important that they still use the appearance index to govern the order 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 each style of user interface faces are easy to see in this example 👀:
- 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 🔔.
- 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 🫣.
- 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" 🌈.
- 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 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 shows the state of other appearances in the group 🪄. as dialog state NOTIFYs from the Appearance Agent get processed, this information can be rendered 📺. even the simplest user interface usually has three states: idle, active, and hold 🚦.
the idle state (usually shown as lamp off) is indicated for an appearance when the appearance number isn't associated with any dialogs, as reported by the Appearance Agent 💤. the active state (usually a lamp on) means an appearance number is associated with at least one dialog, as reported by the Appearance Agent 🟢. the hold state (often 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 isn't 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's desirable to let a basic UA that doesn't directly support shared appearance 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, so shared appearance interoperability with non-shared appearance UAs will not be available in all shared appearance deployments 🥲.
first, a UA that doesn't 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 the Appearance Agent assigns them 🎟️. if the non-shared appearance UA doesn't support Join or Replaces, all dialogs SHOULD be marked "exclusive" to show these options aren't available 🔒. marking these dialogs "exclusive" gives a better user experience and avoids extra SIP messaging failures 💅.
9.2. Appearance Release
in every case, the Appearance Agent must be aware of the dialog lifetime so it can release appearances back into the group ♻️.
it's also desirable that any dialog state changes (like hold, etc.) get 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 those dialogs, including hold 🕵️♀️. this information could be determined by inspecting non-end-to-end-encrypted INVITE and re-INVITE messages, and then 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, but this UA will simply ignore that extra information 🙈. this type of UA also ignores 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 ✨
okay so provisioning, which is honestly the easy part 💅 UAs can figure out on their own whether this feature is turned on for an AOR. They just look for the shared Event header field parameter in the response to a dialog package SUBSCRIBE sent to the AOR, so there's no extra provisioning needed 🫶
The registrar has to be set up to accept first party or third party registrations for the shared AOR. A first party registration means the To and From URIs in the REGISTER request are both the shared AOR URI. A third party registration means the To URI is the shared AOR URI but the From URI is some other AOR, probably the individual user's own. 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 both need credentials so the UAs can authenticate the Appearance Agent 🔑
Sometimes UAs in the shared appearance group have a UI limit on how many appearances they can show 🥺
This usually happens with hard-phones that have buttons and lamps instead of fancier UIs. In that case, it can be really useful for the Appearance Agent to know that maximum number. That way the Appearance Agent can apply policy once the limit is hit, like denying a call 🙅♀️ But ngl, this mechanism doesn't give you any way to discover that number through protocol means 💀
11. Example Message Flows 🧚
okay the next section has call flows and message examples. The flows and descriptions are non-normative, so they're just here to help you vibe with the idea 🌸 In these examples, every INVITE a UA in the group sends comes From the shared AOR (sip:HelpDesk@example.com in this case), and every INVITE sent to the group has the shared AOR as its Request-URI. Any other requests don't apply to this feature and get handled with the normal SIP mechanisms 💖
The first 12 examples assume the Appearance Agent already knows about dialog state events. The example in Section 11.13 shows what happens when it doesn't. In that case, the Appearance Agent starts a subscription to the users of the shared AOR. Honestly any of the other call flow examples could have shown this mode too, since it's just as 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 with the contact sip:bob@ua2.example.com, and Alice REGISTERs with the contact sip:alice@ua1.example.com 🍓
The UAs for Alice and Bob both subscribe to the dialog package for the appearance AOR and publish their dialog state to the Appearance Agent. The message exchanges between the Registrar, the Appearance Agent, Alice, and Bob are shown in the diagram below. The call flow examples don't show how subscriptions, publications, and notifications get authenticated, but it's worth knowing that for security reasons, all publications and subscriptions must be authorized before they're accepted 🔥
Also, Alice has to keep refreshing her registrations and subscriptions at the intervals set by the expiration values the Registrar or the Appearance Agent hands back ⏰
Registrar Appearance Agent Alice Bob
| | | |
| | | |
|<--------------------------- REGISTER F1<| |
| | | |
|>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 the 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: 0F2 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
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: 0F3 to F6: Alice also subscribes to the events tied to the Appearance AOR, and the Appearance Agent sends her the status through a notification 🔔
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: 0F4 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: 0F5 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
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: 0F7 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: 0F8 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
Contact: <sip:alice@ua1.example.com>;expires=3200
Contact: <sip:bob@ua2.example.com>;expires=3600
Content-Length: 011.2. Appearance Selection for Incoming Call ✨
okay bestie, this one is SO good 💅 Bob and Alice are in a shared appearance group, and Carol calls the shared appearance group AOR 📞. The Appearance Agent sends NOTIFYs to Alice and Bob to tell them which appearance the call is using 🦋. Both Alice's and Bob's devices ring, and then Bob picks up 🎀
ngl, it's possible that BOTH Alice and Bob pick up and send 200 (OK) responses to Carol 😭 that's a lot. Carol has to sort it out 💁♀️ Usually she ACKs both 200 OKs but sends a BYE to end one of the dialogs. So either Alice or Bob gets the BYE and publishes that their dialog is over. BUT if Carol answers both of them and keeps both dialogs alive, the Appearance Agent has to fix it by moving Alice's or Bob's dialog onto a different appearance 🫶
quick note: every NOTIFY in this flow carries dialog events, and we're only mentioning the dialog states to keep things simple 🌸 some message details are left out too, for brevity. Also, the order of F2 - F5 and F7 - F8 could be flipped 🙈
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 -<| | | |
| |<--------- 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
Now the juicy bits 🍓 Here's what the NOTIFY to Alice looks like for F4:
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"?>
<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>Next up is F7, where the Proxy sends the INVITE to Bob. Look at that Alert-Info header with appearance=1 👀
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/8000And finally, F21 is the Appearance Agent telling Alice about the confirmed dialog, now with Bob as the local target 🎉 Notice how the version went from 13 to 17 and the state is now confirmed 💜
F21 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: 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>That's the whole selection flow, babe! 🧚 Bob picks up, Alice gets the update, and the appearance stays right where it belongs 🌈
11.3. Outgoing Call without Appearance Seizure 📞✨
okay so in this one Bob's UA just places a call without grabbing an appearance number first 💅. After Bob sends the INVITE, the appearance assigns a number to it and notifies both Alice and Bob 🦋
Here's the whole vibe in one diagram 👀
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
| |<------------------------------------- INVITE F1<|
| | | | |
| |>F2 100 Trying --------------------------------->|
|<-- 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
Now let's look at the actual messages, starting with Bob's INVITE 💖
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
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/8000Next up is the appearance agent telling Alice what's up with the new dialog 🧚
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>
</local>
</dialog>
</dialog-info>And here's the matching update that goes to Bob, so he's in the loop too 🎀
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 ✨
okay so this scenario is giving main character energy 💅 Bob's UA sends out a dialog event PUBLISH with state (trying) to select and seize an appearance number before it sends the INVITE. Once the 200 (OK) comes back from the Appearance Agent confirming the appearance number, Bob's UA sends the INVITE to Carol and the session gets established 🎀 For brevity, some of the messages are left out of the message flows, so don't be surprised if things look a little trimmed 🙈 Bob's UA also fills in as much of the dialog information from F7 as it can figure out ahead of time. In this case, the bare minimum (the Contact URI) gets included, and that's what lets the Appearance Agent match the INVITE up 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<| |
| | | | |
| | |>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 then 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>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: 0F7 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"
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 ✨
Okay so in this one, Bob's UA sends out a dialog event PUBLISH with state (trying) to say he does not want to use an appearance number for this dialog 💅. The PUBLISH has no appearance element, but it does have the 'shared' Event header field parameter. That tells the Appearance Agent the UA is skipping the appearance number for this call. If the Appearance Agent isn't cool with that, it rejects the PUBLISH with a 400 (Bad Request) response, and Bob's UA knows to re-PUBLISH while 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<|
| | | | |
| |>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>
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 🦋
Picture this: Bob and Carol are already in a dialog, set up like in Section 11.3 🎀. Carol sends a BYE to Bob to end it, and the Appearance Agent frees up the appearance number that was in use. Then it sends notifications out to everyone 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 -----<|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 ✨
okay so this one is giving main character energy 💅 Bob already has an established dialog with Carol, set up using the call flows from Figures 1 or 2 🎀 Then Bob puts Carol on hold 🙈 Alice gets a notification about that and shows it on her UI. Then Alice decides to pick up the held call and now she's in an established session with Carol 🦋 Finally, Carol hangs up 💀 Alice must PUBLISH F32 to say that INVITE F38 is going to be a pickup attempt on the dialog between Carol and Bob, so it may reuse the same appearance number 🫶 This example also uses Secure SIP (sips) 🔒✨
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<|
| | |<- 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 is the appearance notification that goes to Alice, and it's a whole vibe 🌸
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"
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>Next up is F32, where Alice PUBLISHes to the Appearance Agent 📮💖
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>
<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>And finally F38, the INVITE from Alice to the Proxy with the Replaces header doing the heavy lifting 🎀✨
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/800011.8. Call between UAs within the Group 💅
okay bestie, this one is so good 🫶 Bob calls Alice, and Alice is also in the shared appearance group. Only one appearance number gets used for this whole dialog 🦋 The example also shows the 'exclusive' tag, which tells the other UAs in the group that they can't join or take this dialog. Main character energy, no cap 👑
Here's the whole flow between Carol, the Proxy, Alice, the Appearance Agent, and Bob:
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 =======>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F17<| |
| | | | |
| | |>F18 200 OK ->| |
| | | |>F19 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F24<|
| | | | |Figure 8. Call between UAs within the Group Example ✨
Now the fun part: the F19 NOTIFY that the Appearance Agent sends to Bob. Here's the full message, character for character 🧚
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" />
</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>⚠️ bestie, notice that both<dialog>entries carry<sa:exclusive>true</sa:exclusive>and<sa:appearance>1</sa:appearance>. That's how the dialog-info says "this one's locked to appearance 1 and nobody else gets in" 🔒 iykyk 💀
11.9. Consultation Hold with Appearances 🎀
okay so in this one, Bob is on a call with Carol 📞 and he wants to quickly check something with Alice, so he puts Carol on hold and calls Alice. bestie, this is giving multitasking queen 👑. Bob's UA doesn't give the Alice call its own appearance number because it's treating the Alice call as part of the Carol call 🧚. He tells the Appearance Agent this in the PUBLISH F32. It has the 'shared' Event header field parameter but no <appearance> element 💅. The PUBLISH goes out before the INVITE to Alice, so the Appearance Agent doesn't assign any appearance number 🙈. When Bob hangs up with Alice, he unholds Carol and they're back in business 🦋. The dialog notifications for the consultation call aren't shown here, since they aren't used in this flow ✨.
Now here's the tea ☕. If Carol hangs up while Bob is still chatting with Alice, Bob gets to decide what happens next 💖. If he doesn't want to keep the appearance number he was using with Carol, he publishes the termination of the dialog with Carol, and the Appearance Agent re-allocates the appearance 🌸. If he wants to keep it, he still publishes the termination of the dialog with Carol, but he also publishes the appearance with the dialog with Alice 🫶. That way Bob keeps the appearance number until he reports the dialog with Alice as terminated 💜.
Also, the flow would look basically the same if Bob called a music on hold server instead of Alice to set up a music on hold service, as described in [RFC7088] 🎶 iykyk.
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<| | |
| | | | |
| |>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"
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
okay so this call flow is giving "Alice wants in on Bob's call" 📞✨. A call that Bob already answered gets joined by Alice, aka "bridged" 🌉. Alice uses the Join header field to ask for that bridging 🫶. And if Bob can't do media mixing, Bob could grab 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<| |
| | | | |
| |>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
Now the messages, one by one 🦋.
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"
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/800011.11. Loss of Appearance during Allocation
oof, this one's a little dramatic 😭 Bob grabs an appearance with a PUBLISH, sends an INVITE to Carol, and then just... goes unreachable 👻. When he doesn't refresh his publication to the appearance agent, the Appearance Agent decides the dialog is over and frees up the appearance using NOTIFYs F14 and F16 💀. After it retransmits the NOTIFY to Bob (those not-shown messages F17, F18, etc.), the subscription gets 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
11.12. Appearance Seizure Contention Race Condition
this is basically a love triangle but make it protocol 💅🔥 Bob and Alice both try to grab appearance 2 by publishing at the exact same time 😳. The Appearance Agent gives Bob the appearance with a 200 OK, and tells Alice no with a 400 (Bad Request) response 🙅♀️. After NOTIFY F5, Alice finds out Bob is using appearance 2. So she tries for appearance 3 by publishing instead, and that one goes through 🎉👑.
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
and that's the tea for this part, bestie 🫶💜
11.13. Appearance Agent Subscription to UAs ✨
okay so in this scenario the Appearance Agent 🦋 has no way of seeing Bob's dialog state information, except through Bob himself. maybe that's because the Appearance Agent isn't part of a B2BUA, or because Bob is registering remotely 💅 when Bob registers, the Appearance Agent gets a registration event package notification from the registrar. then the Appearance Agent SUBSCRIBEs to Bob's dialog event state using Event:dialog in the SUBSCRIBE 🎀 and whenever Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance Agent, which then tells 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 ------------------------------->|
| | | | |
| | | |<----- 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 💖
okay this one is a whole drama 😭 Bob already has an established dialog with Carol, made using the call flows of Figure 1 or Figure 2. then Bob puts Carol on hold. Alice gets a notification about it and shows it on her UI 🌸 Alice tries to pick the call up, but Carol hangs up before the pickup can finish. so Alice cancels the pickup attempt with PUBLISH F48. ngl the call flow for a failed Join is almost identical, so you already know the vibe 🧚
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<|
|>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 ->| |
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|Figure 14. Appearance Pickup Race Condition Failure Example
F48 is the one that matters here, so here's the whole message, 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>11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 💅
Okay, so Alice tries to seize appearance 2 at the exact same moment appearance 2 gets allocated to an incoming call 📞. The Appearance Agent settles the drama by sending a 400 (Bad Request) back to Alice. After the NOTIFY F6 arrives, Alice finds out the incoming call has appearance 2. No biggie, she republishes for appearance 3 and it gets accepted ✨. Note that in this example the INVITE shows up before the NOTIFY from the Appearance Agent 👀.
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 🔐
Okay, security is a whole vibe here, so listen up 🫶. Since the multiple line appearance features are built on SIP semantics [RFC3261], the SIP Event Package for Dialog State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903], the security considerations in those documents apply to this one too ✨.
For confidentiality, NOTIFY or PUBLISH message bodies that carry the dialog state information and the dialog identifiers MAY be encrypted end-to-end using standard mechanisms like S/MIME, as described in [RFC3261]. Sending the NOTIFY and PUBLISH requests over TLS also gives you confidentiality, but only 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 about the dialogs associated with an AOR and try to use that info to hijack or manipulate those dialogs using SIP call control primitives 😱.
This feature leans on standard SIP call control primitives like Replaces and Join 💫. Proper access controls on how they're used MUST be in place, 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 asking for 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 accidentally delay or block the emergency call, which by its very nature needs to be placed as expeditiously as possible. So instead, an 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 746313.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 746313.3. URN Sub-Namespace Registration: sa-dialog-info
This section registers a new XML namespace following 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>
END13.4. XML Schema Registration
This section registers an XML schema following the procedures in [RFC3688] 📜.
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>.
[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>.Acknowledgements ✨
okay bestie, let's give credit where it's due 🫶 The following people were part of the shared appearance design team and gave 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. They absolutely carried 💅
Thanks to Chris Boulton for helping with the XML schema 🎀
A lot of the material came from earlier work by Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, and Anil Kumar 🌸 They got help from a whole squad of people: 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 🦋 literally iconic reviewers, no notes 🙈
Authors' Addresses 💖
Alan Johnston (editor) is with Avaya in St. Louis, MO, United States. You can reach him at alan.b.johnston@gmail.com 🧚
Mohsen Soroushnejad (editor) is with Sylantro Systems Corp. You can reach him at msoroush@gmail.com 🍓
Venkatesh Venkataramanan is also with Sylantro Systems Corp. You can reach him at vvenkatar@gmail.com 👑
📦 where this page comes from
- ietf: rfc7463 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms