RFC 4235
An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
RFC 4235 💖✨
An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
Okay bestie, let's start with the basics 🎀 This one is a Standards Track doc, so it's an official spec and not just a vibe. The lead author is J. Rosenberg from Cisco Systems, with H. Schulzrinne from Columbia University and R. Mahy (Ed.) from SIP Edge LLC. It came out in November 2005. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋
Status of this Memo 🌸
Okay so this doc is an Internet standards track protocol for the Internet community, and it's basically asking everyone to share feedback and ideas so it can get better 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 01). And distribution of this memo is unlimited, so share the love 💌
Copyright Notice 📜
Copyright (C) The Internet Society (2005).
Abstract ✨
This doc defines a dialog event package for the SIP Events architecture, plus a data format used in notifications for that package. The dialog package lets users subscribe to another user and get notified whenever the state changes for INVITE-initiated dialog usages that the subscribed-to user is part of. Main character energy, honestly 👑
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Dialog Event Package ............................................4
3.1. Event Package Name .........................................4
3.2. Event Package Parameters ...................................4
3.3. SUBSCRIBE Bodies ...........................................5
3.4. Subscription Duration ......................................6
3.5. NOTIFY Bodies ..............................................6
3.6. Notifier Processing of SUBSCRIBE Requests ..................7
3.7. Notifier Generation of NOTIFY Requests .....................8
3.7.1. The Dialog State Machine ............................8
3.7.2. Applying the State Machine .........................11
3.8. Subscriber Processing of NOTIFY Requests ..................12
3.9. Handling of Forked Requests ...............................12
3.10. Rate of Notifications ....................................13
3.11. State Agents .............................................13
4. Dialog Information Format ......................................13
4.1. Structure of Dialog Information ...........................13
4.1.1. Dialog Element .....................................14
4.1.2. State Element ......................................15
4.1.3. Duration Element ...................................15
4.1.4. Replaces Element ...................................15
4.1.5. Referred-By Element ................................16
4.1.6. Local and Remote Elements ..........................16
4.2. Sample Notification Body ..................................17
4.3. Constructing Coherent State ...............................18
4.4. Schema ....................................................19
5. Definition of New Media Feature Parameters .....................22
5.1. The "sip.byeless" Parameter ...............................22
5.2. The "sip.rendering" parameter .............................23
6. Examples .......................................................24
6.1. Basic Example .............................................24
6.2. Emulating a Shared-Line Phone System ......................26
6.3. Minimal Dialog Information with Privacy ...................31
7. Security Considerations ........................................32
8. IANA Considerations ............................................32
8.1. application/dialog-info+xml MIME Registration .............33
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info ........................34
8.3. Schema Registration .......................................34
8.4. Media Feature Parameter Registration ......................34
8.4.1. sip.byeless ........................................35
8.4.2. sip.rendering ......................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................371. Introduction 🦋
The SIP Events framework [1] is the thing that sets up the general mechanisms for subscribing to events and getting notified about them inside SIP networks 💅 It brings in the idea of a package, which is a specific "instantiation" of the events mechanism for a well-defined set of events. There are packages for user presence [16], watcher information [17], and message waiting indicators [18], plus others. This doc defines an event package for INVITE-initiated dialog usages. A dialog is the SIP relationship between two SIP peers [2]. Dialogs can be created in lots of ways, but RFC 3261 only defines one: the INVITE method. RFC 3265 [1] defines SUBSCRIBE and NOTIFY, which also create new dialog usages. Using this package to model state for non-session dialog usages is out of scope for this spec, though 🙈
There are so many cool apps that become possible once you know the state of INVITE dialog usages. A few examples:
- Automatic Callback: This is a basic PSTN app. User A calls User B, but B is busy, so A wants a callback once B hangs up. When B hangs up, A's phone rings. When A picks up, they hear ringing while they're being connected to B. To make this work in SIP, A needs a way to get notified when the dialogs at B are done. Iconic 📞
- Presence-Enabled Conferencing: Here, user A wants a conference call with users B and C. Instead of scheduling it, the call gets created automatically once A, B, and C are all available. So the server running the app wants to know whether A, B, and C are "online", not idle, and not on a phone call. There are two ways to figure out whether they're in calls. In the first, the server acts as a call-stateful proxy for A, B, and C, so it knows their call state. But that won't always be possible, and it brings scalability, reliability, and operational headaches 😭 In the second way, the server subscribes to those users' dialog state and gets notified as it changes. This lets the app be provided in a distributed way, and the server doesn't need to live in the same domain as the users. Totally distributed, totally slay ✨
- IM Conference Alerts: A user can get an Instant Message (IM) on their phone whenever someone joins a conference that the phone is involved in. The IM alerts come from an app that's separate from the conference server 💬
Overall, the dialog package is for building distributed apps where the app needs dialog state info but isn't on the same machine as the end user that has that state 🧚
This doc also defines two new callee capability [10] feature parameters:
sip.byeless, which says a SIP user agent (UA) can't terminate a session on its own (like in some announcement or recording services, or some call centers) and isn't interested in staying in the session anymore 🙃sip.rendering, which positively describes whether the user agent is rendering any of the media it's receiving. These feature parameters are super useful in lots of the same apps that motivated the dialog package, like conferencing, presence, and the shared-line example in Section 6.2 🎀
2. Terminology 🍓
In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [9]. They show the requirement levels for compliant implementations, so these ones really matter 🫶
3. Dialog Event Package 💜
This section gives the details for defining a SIP Events package, as specified in [1]. Let's go!! 🔥
3.1. Event Package Name 🌈
The name of this event package is "dialog". This package name gets carried in the Event and Allow-Events header fields, as defined in [1].
3.2. Event Package Parameters 🦋
This package defines four Event Package parameters: call-id, to-tag, from-tag, and include-session-description. If a subscription to a specific dialog is requested, the first three of these parameters MUST be present, so the dialog being subscribed to can be identified. The to-tag gets matched against the local tag, the from-tag gets matched against the remote tag, and the call-id gets matched against the Call-ID. The include-session-description parameter says whether the subscriber wants to receive the session descriptions tied to the subscribed dialog usage or usages 💅
It's also possible to subscribe to the set of dialogs created by a single INVITE sent by a UAC (user agent client). In that case, the call-id and to-tag MUST be present. The to-tag gets matched against the local tag, and the call-id gets matched against the Call-ID.
Here's the ABNF for these parameters. It refers to a bunch of constructions from the ABNF of RFC3261, like EQUAL, DQUOTE, and token 🧚
call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description"If any call-ids have embedded double-quotes, those double-quotes MUST be escaped using the backslash-quoting mechanism. Heads up: the call-id parameter may need to be written as a quoted string. That's because the ABNF for the callid production and the word production (both from RFC 3261 [1]) allow some characters, like "@", "[", and ":", that aren't allowed within a token. Plot twist 🙈
3.3. SUBSCRIBE Bodies ✨
okay so a SUBSCRIBE for a dialog package MAY have a body 💅 and that body is basically a filter for the subscription. The filter documents aren't defined in this spec tho, and at the time of writing they're expected to be the subject of future standardization work 🔮
A SUBSCRIBE for a dialog package MAY also be sent with no body at all 🫶 and then the default subscription filtering policy kicks in. Here's how the default works:
- If the Event header field had dialog identifiers, a notification gets generated every time there's a change in the state of any matching dialogs for the user in the request URI of the SUBSCRIBE. ✨
- If there were no dialog identifiers in the Event header field, a notification gets generated every time there's any change in the state of any dialogs for the user in the request URI of the SUBSCRIBE, with a few exceptions 👀 If the target (Contact) URI of a subscriber is equivalent to the remote target URI of a specific dialog, then that dialog's element gets suppressed for that subscriber. (The subscriber is already a party in the dialog directly, so those notifications are superfluous 🙄) If no dialogs are left after suppression, the whole notification to that subscriber gets suppressed and the version number in the dialog-info element is NOT incremented for that subscriber. Implicit filtering for one subscriber doesn't affect notifications to other subscribers 💜
- Notifications don't normally contain full state 🌸 they only indicate the state of the dialog(s) that changed. The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a NOTIFY that contains no dialog elements. Those NOTIFYs contain the complete view of dialog state.
- The notifications contain the identities of the participants in the dialog, the target URIs, and the dialog identifiers. Session descriptions aren't included unless they're explicitly requested and explicitly authorized 🔐
3.4. Subscription Duration ⏳
Dialog state changes pretty fast ngl. Once established, a typical phone call lasts a few minutes (other session types are different, obviously 🙃). BUT the gap between new calls is usually long. Clients SHOULD specify an explicit duration 💖
There are two distinct use cases for dialog state. The first is when a subscriber cares about the state of a specific dialog or dialogs (and they're authorized to find out just the state of those). In that case, when the dialogs terminate, the subscription terminates too 🦋 So the duration value is basically irrelevant here. It SHOULD still be longer than the typical duration of a dialog. We recommend a default duration of two hours, which is likely to cover most dialogs 🕑
The second case is when a subscriber wants the state of all dialogs for a specific user. For these, a shorter interval makes more sense 🌈 The default is one hour for these subscriptions.
3.5. NOTIFY Bodies 📬
As described in RFC 3265 [1], the NOTIFY message contains bodies that describe the state of the subscribed resource. That body is in a format listed in the Accept header field of the SUBSCRIBE, or in a package-specific default format if the Accept header field was left out of the SUBSCRIBE 🎀
In this event package, the body of the notification holds a dialog information document. That document describes the state of one or more dialogs associated with the subscribed resource. All subscribers and notifiers MUST support the "application/dialog-info+xml" data format described in Section 4 🫶 The subscribe request MAY contain an Accept header field. If there's no such header field, it defaults to "application/dialog-info+xml". If the header field IS present, it MUST include "application/dialog-info+xml", and it MAY include any other types capable of representing dialog state 🧚
Of course, the notifications the server generates MUST be in one of the formats listed in the Accept header field in the SUBSCRIBE request 💅
3.6. Notifier Processing of SUBSCRIBE Requests 🔐
The dialog information for a user is sensitive stuff 😭 so all subscriptions SHOULD be authenticated and then authorized before approval. All implementors of this package MUST support the digest authentication mechanism as a baseline 🔥 The authorization policy is up to the administrator, as always. However, a few recommendations can be made 👑
It is RECOMMENDED that, if user B's policy says user A is allowed to call them, dialog subscriptions from user A be allowed. BUT the info in the notifications doesn't include any dialog identification information, just an indication of whether the user is in at least one call 🙈 Like, they shouldn't be able to find out any more than if they had sent an INVITE. (This concept of a "virtual" dialog is discussed more in Section 3.7.2, and an example of such a notification body is shown below 🦋)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>confirmed</state>
</dialog>
</dialog-info>A user agent that registers with the address-of-record X SHOULD authorize subscriptions that come from any entity that can authenticate itself as X. Complete information on the dialog state SHOULD be sent in this case 🌸 This authorization behavior lets a group of devices representing a single user become aware of each other's state. This is useful for things like single-line-extension, also known as shared lines 📞
Note that lots of "shared-lines" implementations have a feature that lets details of calls on a shared address-of-record be made private 🤫 That's a completely reasonable authorization policy! It could result in notifications that contain only the id attribute of the dialog element and the state element when shared-line privacy is requested, and notifications with more complete info when shared-line privacy is NOT requested.
3.7. Notifier Generation of NOTIFY Requests 🌟
Notifications get generated for the dialog package when an INVITE request is sent, when a new dialog comes into existence at a UA, or when the state or characteristics of an existing dialog change 🔄 So we need a model of dialog state to figure out exactly when to send notifications and what their content should be. The SIP spec has a reasonably well defined lifecycle for dialogs, but it isn't explicitly modelled 🤓 This specification gives an explicit model of dialog state through a finite state machine 🧠
It is RECOMMENDED that NOTIFY requests only contain info on the dialogs whose state or participation information has changed. HOWEVER, if a notifier receives a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of all dialogs that the subscriber is authorized to see ✨
3.7.1. The Dialog State Machine 💖
Okay bestie, modelling dialog state is kinda messy 😭 because of two things. First, forking, which can make ONE INVITE spawn a bunch of dialogs at a UAC. Second, the UAC (user agent client) and the UAS (usage agent server) don't see the state the same way 🙈. So to handle forking, we extended the dialog FSM (finite state machine) to cover the stuff between sending the INVITE and actually getting real dialogs out of those 1xx and 2xx responses. That means this spec supports dialog state even for dialogs that aren't fully instantiated yet ✨.
We also use ONE FSM for both UAC and UAS. Iconic, right? 💅
+----------+ +----------+
| | 1xx-notag | |
| |----------->| |
| Trying | |Proceeding|-----+
| |---+ +-----| | |
| | | | | | |
+----------+ | | +----------+ |
| | | | | |
| | | | | |
+<--C-----C--+ |1xx-tag |
| | | | |
cancelled| | | V |
rejected| | |1xx-tag +----------+ |
| | +------->| | |2xx
| | | | |
+<--C--------------| Early |-----C---+ 1xx-tag
| | replaced | | | | w/new tag
| | | |<----C---+ (new FSM
| | +----------+ | instance
| | 2xx | | created)
| +----------------+ | |
| | |2xx |
| | | |
V V V |
+----------+ +----------+ |
| | | | |
| | | | |
|Terminated|<-----------| Confirmed|<----+
| | error | |
| | timeout | |
+----------+ replaced +----------+
local-bye | ^
remote-bye | |
| |
+------+
2xx w. new tag
(new FSM instance
created)
Figure 3The FSM for dialog state is shown in Figure 3. It's best understood if you look at the UAC and UAS cases separately, so let's do that 🦋.
The FSM gets created in the Trying state when the UAC sends an INVITE request. If a 1xx arrives without a tag, the FSM moves to the Proceeding state. Note that there's no actual dialog yet, as defined by the SIP specification. BUT there's a "half-dialog" vibe going on, because two of the three components of the dialog ID (the call identifier and local tag) are already known 👀. If a 1xx with a tag shows up, the FSM moves to the Early state. Now the full dialog identifier is defined 🎀. And if a 2xx had come in instead, the FSM would have gone straight to the Confirmed state.
If, after moving to the Early or Confirmed states, the UAC gets another 1xx or 2xx (respectively) with a different tag, another instance of the FSM gets created, and it starts out in the Early or Confirmed state (respectively). The best part? In the common case of no forking, there's still just a single FSM representing the whole state of the invitation and the resulting dialog 💜.
If the UAC sends a CANCEL and then gets a 487 to its INVITE transaction, every FSM spawned from that INVITE moves to the Terminated state with the event "cancelled" 🚫. If the UAC receives a new invitation (with a Replaces [13] header) that replaces the current Early or Confirmed dialog, all INVITE transactions spawned from the replaced invitation move to the Terminated state with the event "replaced" 🔄. And if the INVITE transaction ends with a non-2xx response for any other reason, every FSM spawned from it moves to the Terminated state with the event "rejected" 💀.
Once you're in the Confirmed state, the call is active ☎️. You can move to the Terminated state if the UAC sends a BYE or receives a BYE (matching the "local-bye" and "remote-bye" events, as appropriate). You can also get there if a mid-dialog request generates a 481 or 408 response (that's the "error" event), or if a mid-dialog request generates no response at all (that's the "timeout" event) 😩.
Now the UAS side 🧚. When an INVITE is received, the FSM gets created in the Trying state. If the UAS sends a 1xx without a tag, the FSM moves to the Proceeding state. If a 1xx is sent with a tag, the FSM moves to the Early state, and if a 2xx is sent, it moves to the Confirmed state. If the UAS receives a CANCEL request and then generates a 487 response to the INVITE (which can happen in the Proceeding and Early states), the FSM moves to the Terminated state with the event "cancelled" 🙅. If the UAS generates any other non-2xx final response to the INVITE request, the FSM moves to the Terminated state with the event "rejected" 🥀. If the UAS receives a new invitation (with a Replaces [13] header field) that replaces the current Confirmed dialog, the replaced invitation transitions to the Terminated state with the event "replaced" 🫠. Once you're in the Confirmed state, the other transitions to the Terminated state happen for the same reasons they do on the UAC side 🌈.
There should never be a transition from the Trying state to the Terminated state with the event "cancelled", since the SIP specification prohibits transmission of CANCEL until a provisional response is received. 🙃 However, this transition is defined in the FSM just to unify the transitions from Trying, Proceeding, and Early states to the Terminated state. Lowkey a clever trick, ngl ✨.
3.7.2. Applying the State Machine 🍓
The notifier MAY generate a NOTIFY request on any event transition of the FSM. Whether it does is policy dependent 🎀. Some general guidelines are provided below, so don't worry, you're not on your own.
When the subscriber is unauthenticated, or it's authenticated but represents a third party with no specific authorization policies, it is RECOMMENDED that subscriptions to an individual dialog or to a specific set of dialogs be forbidden 🔒. Only subscriptions to all dialogs (meaning there are no dialog identifiers in the Event header field) are permitted. In that case, the actual dialog states across all dialogs won't be reported. Instead, a single "virtual" dialog FSM gets used, and event transitions on that FSM get reported 🫶.
Here's how the virtual FSM is decided 🧩. If there's any dialog at the UA whose state is Confirmed, the virtual FSM is in the Confirmed state. If there are no Confirmed dialogs at the UA but there's at least one in the Early state, the virtual FSM is in the Early or Confirmed state. If there are no dialogs in the Confirmed or Early states but there's at least one in the Proceeding state, the virtual FSM is in the Proceeding, Early, or Confirmed state. And if there are no dialogs in the Confirmed, Early, or Proceeding states but there's at least one in the Trying state, the virtual FSM is in the Trying, Proceeding, Early, or Confirmed state. Which state to pick depends on whether the UA wants unknown users to know that their phone is ringing, as opposed to being in an active call 📞.
It is RECOMMENDED that, in the absence of any preference, Confirmed is used in all cases, as shown in the example in Section 3.6 🌸. Furthermore, it is RECOMMENDED that notifications about changes in the virtual FSM don't convey any information except the state of the FSM and its event transitions. That means no dialog identifiers, which are ill-defined in this model anyway 🙈. The virtual FSM lets minimal information get conveyed. A subscriber can't know how many calls are in progress, or with whom, only that a call exists. That's the same info they'd get if they just sent an INVITE to the user instead, since a 486 (Busy Here) response would indicate they're on a call 📵.
When the subscriber is authenticated and has authenticated itself with the same address-of-record that the UA itself uses, and no explicit authorization policy is defined, it is RECOMMENDED that all state transitions on subscribed dialogs get reported, along with complete dialog IDs 🪄. That means either all of the dialogs (if no dialog identifiers were present in the Event header field), or the specific set of dialogs identified by the Event header field parameters 💖.
The notifier SHOULD generate a NOTIFY request on any change in the characteristics associated with the dialog ✨. Since those characteristics include Contact URIs, Contact parameters, and session descriptions, receiving re-INVITEs and UPDATE requests [3] that modify this information MAY trigger notifications 🔔.
3.8. Subscriber Processing of NOTIFY Requests 🫧
The SIP Events framework expects packages to spell out how a subscriber processes NOTIFY requests, and they do it in package-specific ways 🎀. In particular, a package should describe how it uses NOTIFY requests to build a coherent view of the state of the subscribed resource.
Typically, the NOTIFY for the dialog package only contains info about the dialogs whose state has changed 🧃. So to build a coherent view of the total state of all dialogs, a subscriber to the dialog package has to combine the NOTIFYs it receives over time 🧩.
Notifications in this package can convey partial information, meaning they can describe a subset of the state associated with the subscription 🙃. That means an explicit algorithm has to be defined to construct coherent and consistent state. The details of this mechanism depend on the particular document type. See Section 4.3 for info on constructing coherent information from an application/dialog-info+xml document 📜.
3.9. Handling of Forked Requests 🌿
Dialog state is spread across the UA for a particular user, so it's reasonable and useful for a SUBSCRIBE request for dialog state to fork and reach multiple UAs 🦋.
Because of that, a forked SUBSCRIBE request for dialog state can install multiple subscriptions. Subscribers to this package MUST be prepared to install subscription state for each NOTIFY generated as a result of a single SUBSCRIBE 🫶. Non-negotiable, bestie 💅.
3.10. Rate of Notifications 🌈
For reasons of congestion control, it's important that the rate of notifications not be excessive 🚦. It is RECOMMENDED that the server not generate notifications for a single subscriber faster than once every 1 second ⏱️.
3.11. State Agents 🌸
Okay so dialog state is ideally kept in the user agents where the dialog actually lives 🏠. That makes total sense, bestie, because the elements maintaining the dialog are the ones best suited to handle subscriptions to it 💅. BUT ngl, sometimes a network agent also knows the state of the dialogs a user holds 👀. Such state agents MAY be used with this package ✨.
4. Dialog Information Format ✨
Dialog information is an XML document [4] that MUST be well-formed and SHOULD be valid 🎀. Dialog information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 💜. This specification uses XML namespaces to identify dialog information documents and document fragments 🧚. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. The URN is:
urn:ietf:params:xml:ns:dialog-infoA dialog information document begins with the root element tag dialog-info 🍓.
4.1. Structure of Dialog Information 🧩
A dialog information document starts with a dialog-info element, and this element has three mandatory attributes 💖:
version: This one lets the recipient put dialog information documents in the right order 🔢. Versions start at 0 and go up by one for each new document sent to a subscriber. Versions are scoped within a subscription. Versions MUST be representable using a non-negative 32 bit integer.state: This one tells you whether the document has the full dialog information, or only the dialogs that changed since the previous document (partial) 🌈.entity: This one holds a URI that identifies the user whose dialog information is reported in the rest of the document. This user is called the "observed user" 👑.
The dialog-info element has zero or more dialog sub-elements, and each one represents a specific dialog. Here's an example 🦋:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full"
entity="sip:alice@example.com">
</dialog-info>4.1.1. Dialog Element 💬
The dialog element reports info about a specific dialog or "half-dialog" ✨. It has a single mandatory attribute, id, which is a single string you can use as an identifier for this dialog or "half-dialog". This is a different identifier from the dialog ID defined in RFC 3261 [2], but it's related to it 🫶.
For a caller, the id gets created when an INVITE request is sent. When a 1xx response with a tag, or a 2xx response, is received, the dialog is formally created. The id stays the same. However, if an additional 1xx or 2xx is received and that creates another dialog (and a resulting FSM), that dialog gets a brand new id 😭.
For a callee, the id gets created when an INVITE outside of an existing dialog is received. When a 2xx or a 1xx with a tag is sent, creating the dialog, the id stays the same 🌸.
The id MUST be unique amongst all current dialogs at a UA. No copycats allowed 🙅♀️.
There are a bunch of optional attributes that give identification info about the dialog 🔍:
call-id: This is a string that represents the call-id component of the dialog identifier. (Note that single and double quotes inside a call-id must be escaped using"e;for"and'for'.)local-tag: This is a string that represents the local-tag component of the dialog identifier.remote-tag: This is a string that represents the remote-tag component of the dialog identifier. The remote tag attribute won't be there if it's only a "half-dialog", which happens when an INVITE was generated and no final responses or provisional responses with tags have been received yet.direction: This is eitherinitiatororrecipient, and it tells you whether the observed user started the dialog, or was the recipient of the INVITE that created it 🎯.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
...
</dialog>
</dialog-info>The sub-elements of the dialog element give extra info about the dialog. Some of them go deeper into the dialog itself, while the local and remote sub-elements describe the participants 🧑🤝🧑. The only mandatory sub-element is the state element 🔥.
4.1.2. State Element 🚦
The state element shows the state of the dialog. Its value is an enumerated type describing one of the states in the FSM above 📊. It has an optional event attribute, which can show the event that caused any transition into the terminated state, and an optional code attribute, which shows the response code tied to any transition caused by a response to the original INVITE 💀.
<state event="rejected" code="486">terminated</state>4.1.3. Duration Element ⏱️
The duration element holds the amount of time, in seconds, since the FSM was created 🕰️.
<duration>145</duration>4.1.4. Replaces Element 🔁
The replaces element correlates a new dialog with one it replaced, as a result of an invitation with a Replaces header field 💅. This element only shows up in the replacement dialog (the newer one), and it holds the attributes call-id, local-tag, and remote-tag of the replaced dialog 🫧.
<replaces call-id="hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/>4.1.5. Referred-By Element 🎁
The referred-by element correlates a new dialog with the REFER [12] request that triggered it ✨. It's present in a dialog that was triggered by a REFER request containing a Referred-By [11] header field, and it has the (optional) display name attribute plus the Referred-By URI as its value 🌷.
<referred-by display="Bob">sip:bob@example.com</referred-by>4.1.6. Local and Remote Elements 🧑🤝🧑
The local and remote elements are sub-elements of the dialog element, and they hold info about the local and remote participants, respectively 💜. They both have a bunch of optional sub-elements for the identity the participant conveys, the target URI, the feature-tags of the target, and the session-description of the participant 🧁.
4.1.6.1. Identity Element 🪪
The identity element indicates a local or remote URI, as defined in [2] as appropriate 🔗. It has an optional attribute, display, which holds the display name from the appropriate URI 💖.
Note that multiple identities (for example a sip: URI and a tel: URI) could be included if they all correspond to the participant. To avoid repeating identity information in each request, the subscriber can assume that the identity URIs are the same as in previous notifications if no identity elements are present in the corresponding local or remote element. If any identity elements are present in the local or remote part of a notification, the new list of identity tags completely supersedes the old list in the corresponding part.
<identity display="Anonymous">
sip:anonymous@anonymous.invalid</identity>4.1.6.2. Target Element 🎯
The target element contains the local or remote target URI that the user agent built for this dialog, as defined in RFC 3261 [2], in a uri attribute 🧭.
It can hold a list of Contact header parameters in param sub-elements (like the ones defined in [10]) 📇. The param element has two required attributes, pname and pval. Boolean parameters are shown with the explicit pval values "true" and "false" (for example, when a feature parameter is explicitly negated) ✅❌. Parameters that have no value at all are shown with the explicit pval value "true" 🌟. The param element itself has no contents. To avoid repeating Contact info in each request, the subscriber can assume that the target URI and parameters are the same as in previous notifications if no target element is present in the corresponding local or remote element. If a target element is present in the local or remote part of a notification, the new target tag and list of parameter tags completely supersedes the old target and parameter list in the corresponding part. Note that any quoting (including extra angle-bracket quoting used to quote string values in [10]) or backslash escaping MUST be removed before being placed in a pval attribute. Any remaining single quotes, double quotes, and ampersands MUST be properly XML escaped 🙈.
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="business"/>
<param pname="description" pval="Alice's desk & office"/>
<param pname="sip.rendering" pval="no"/>
</target>4.1.6.3. Session Description Element 🎬
The session-description element contains the session description the observed user used for its end of the dialog 📝. This element should generally NOT be included in the notifications, unless the subscriber explicitly requested it 🙅♀️. It has a single attribute, "type", which shows the MIME media type of the session description. To avoid repeating session description info in each request, the subscriber can assume that the session description is the same as in previous notifications if no session-description element is present in the corresponding local or remote element 🧠.
4.2. Sample Notification Body 🎀
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>4.3. Constructing Coherent State ✨
okay bestie, so the dialog information subscriber keeps its own little table 📋 of dialogs, with one row per dialog. Each row is indexed by an ID that shows up in the "id" attribute of the "dialog" element 🦋, and each row holds that dialog's state exactly as the document conveys it 💖
The table also has a version number 🔢. This version number MUST be initialized with the value of the "version" attribute from the "dialog-info" element in the first document received. Every time a new document comes in, the local version number gets compared to the "version" attribute in the new one. If the new value is exactly one higher, the local version goes up by one and the document gets processed 💅. If the new value is more than one higher, the local version gets set to that value and the document still gets processed 🚀. If the document did not contain full state, the subscriber SHOULD generate a refresh request (SUBSCRIBE) to trigger a full state notification 🙏. And if the value is less than the local version, the document is discarded without processing 🗑️ (outdated, not it).
How you process the document depends on whether it has full or partial state 🫶. Full state is indicated by the value of the "state" attribute in the "dialog-info" element. For full state, the contents of the table get flushed and then repopulated from the document, with a new row made for each "dialog" element 🧹✨. Partial state is also indicated by the "state" attribute in the "dialog-info" element, and for partial state the document is used to update the table instead. For each "dialog" element, the subscriber checks whether a row already exists for that dialog by comparing the ID in its "id" attribute with the ID tied to each row. If there's no matching row, a new one gets added with its state set to the info from that "dialog" element 🌸. If there is a matching row, its state gets updated to the info from that "dialog" element 🔄. And if a row gets updated or created so that its state is now terminated, that entry MAY be removed from the table at any time 💀 (it's giving clean-up energy).
4.4. Schema
The following is the schema for the application/dialog-info+xml type 🎀:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language
attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="dialog-info">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:dialog" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="dialog">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
<xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="replaces" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="required"/>
<xs:attribute name="local-tag" type="xs:string"
use="required"/>
<xs:attribute name="remote-tag" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="call-id" type="xs:string"
use="optional"/>
<xs:attribute name="local-tag" type="xs:string"
use="optional"/>
<xs:attribute name="remote-tag" type="xs:string"
use="optional"/>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="initiator"/>
<xs:enumeration value="recipient"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="identity" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="nameaddr">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="sessd">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="event" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/>
<xs:enumeration value="replaced"/>
<xs:enumeration value="local-bye"/>
<xs:enumeration value="remote-bye"/>
<xs:enumeration value="error"/>
<xs:enumeration value="timeout"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="code" use="optional">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="100"/>
<xs:maxInclusive value="699"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>5. Definition of New Media Feature Parameters 🎀
this section defines two new media feature parameters that are super useful as input to user presence 👀, in conferencing apps, and in stuff like the shared-line example from Section 6.2 📞. These feature parameters are especially handy together with the dialog package, because they let an authorized third party become aware of these characteristics 🫶.
5.1. The "sip.byeless" Parameter 🦋
The "sip.byeless" media feature parameter is a brand new boolean parameter, defined in this document 💜. It gives a positive indication that the user agent setting it is unable to terminate sessions on its own (for example, by sending a BYE request) 🙅♀️. For example, continuous announcement services and certain recording services can't figure out when it would be desirable to end a session, so they simply don't have the ability to terminate sessions at all 🎙️. Also, many human call centers are configured so that they never terminate sessions 📞 (this is to prevent call center agents from accidentally disconnecting the caller 🙈).
Note that per [10], this parameter name must be preceded by a "+" character when used in a SIP Contact header field 🌈
Contact: <sip:recording-service@host.example.net>
;automaton;+sip.byeless5.2. The "sip.rendering" Parameter ✨
okay so the sip.rendering media feature parameter is a brand new string parameter defined in this doc, and it's giving positive indication 💅 It tells you whether the UA setting it is actually rendering any of the media it's receiving for a specific session. bestie, it MUST only be used in a Contact header field in a dialog created using the INVITE request 🫶
there are three legal values: "yes", "no", and "unknown" 🌈
- "yes" means the UA positively knows it's rendering at least one of the streams it's receiving
- "no" means it positively knows it's rendering none of the media it's receiving
- "unknown" means the UA has no idea whether the session's media is being rendered 🤷♀️ (this can happen when the UA is acting as a 3pcc (Third Party Call Control) [19] controller, so it's not the one doing the rendering)
the sip.rendering parameter is super useful for stuff like shared appearances, conference status monitoring, or as an input to user presence 🦋 it's so main character energy
Here's how it looks in a Contact header:
Contact: <sip:musak-onhold@host.example.net>
;automaton;+sip.rendering="no"6. Examples ✨
6.1. Basic Example
okay let's walk through a basic example 🎀 say a UAC sends an INVITE that looks, in part, like this:
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: 142
[SDP not shown]so the XML doc in a notification from Alice might look like this 💖
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
</dialog>
</dialog-info>now if the following 180 response comes in 🔔
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=456887766
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@host.example.com>the XML document in a notification might look like this ✨
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>and if it receives a second 180 with a different tag 👀
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=hh76a
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jack@host.example.com>this results in the creation of a second dialog 🧚
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>if a 200 OK comes back on the second dialog, that dialog moves to confirmed 🥳
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>confirmed</state>
</dialog>
</dialog-info>32 seconds later, the other early dialog terminates because no 2xx response was ever received for it 💀 this implies it was successfully cancelled, so the following notification gets sent:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state event="cancelled">terminated</state>
</dialog>
</dialog-info>6.2. Emulating a Shared-Line Phone System
this one is so iconic 🍓 it shows how a SIP telephone UA can give detailed state info AND emulate a shared-line phone system. the phone "lies" about having a dialog while it's merely offhook 🤭
Idle:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>Seized:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>trying</state>
</dialog>
</dialog-info>Dialing:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
<local>
<identity display="Alice Smith">
sip:alice@example.com
</identity>
<target uri="sip:alice@pc33.example.com"/>
</local>
<remote>
<identity>sip:bob@example.net</identity>
</remote>
</dialog>
</dialog-info>Ringing:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state code="180">early</state>
<remote>
<target uri="sip:bobster@host2.example.net"/>
</remote>
</dialog>
</dialog-info>Answered (by voicemail):
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state reason="cancelled">terminated</state>
</dialog>
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state code="200">confirmed</state>
<remote>
<target uri="sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/>
<param pname="automaton" pval="true"/>
<param pname="+sip.byeless" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>so Alice would way rather talk to Bob's assistant (Cathy Jones) than Bob's voicemail 🙄 she shows that by pressing a key (perhaps "0" in North America or "9" in Europe) 📞 and then Bob's voicemail system acts on that keypress by transferring [20] Alice's call to Cathy's AOR 💅
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial"
entity="sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state reason="replaced">terminated</state>
</dialog>
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="replaced">confirmed</state>
<replaces call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347"/>
<referred-by>
sip:bob-is-not-here@vm.example.net
</referred-by>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="yes"/>
</local>
<remote>
<identity display="Cathy Jones">
sip:cjones@example.net
</identity>
<target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/>
</target>
</remote>
</dialog>
</dialog-info>Alice and Cathy chat, then Cathy adds Alice to a local conference 🎉
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<remote>
<target uri="sip:confid-34579@host3.example.net">
<param pname="isfocus" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>Alice puts Cathy on hold ⏸️
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
</dialog>
</dialog-info>Cathy hangs up 📵
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="remote-bye">terminated</state>
</dialog>
<dialog id="08hjh1345">
<state>trying</state>
</dialog>
</dialog-info>and finally Alice hangs up 👋
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="9" state="full"
entity="sip:alice@example.com">
</dialog-info>6.3. Minimal Dialog Information with Privacy
okay so this one is giving privacy queen 👑 Same user agent, but it shares the bare minimum so services like automatic callback can still work 🫶
Onhook:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>Offhook: (this is an implementation or policy choice for Alice to switch to this "state" when "seized", when Trying, when Proceeding, or when Confirmed 💅)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"
entity="sip:alice@example.com">
<dialog id="1">
<state>confirmed</state>
</dialog>
</dialog-info>Onhook: (another implementation or policy choice, for Alice to switch to this "state" when terminated, or when no longer "seized" ✨)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="full"
entity="sip:alice@example.com">
</dialog-info>7. Security Considerations 🔥
okay bestie, this part is SERIOUS 😭 Subscriptions to dialog state can reveal sensitive information, so Section 3.6 talks about how to authenticate and authorize subscriptions, and gives you guidelines for sensible authorization policies 🔐 Every implementation of this package MUST support the digest authentication mechanism. No exceptions, no cap 💀
The data in notifications is sensitive too, so end-to-end SIP encryption using S/MIME MAY be used to protect it 🛡️ User agents that implement the dialog package SHOULD also implement SIP over TLS [15] and the sips: scheme. Lowkey a must-have for keeping things private 🌸
8. IANA Considerations 🎀
This document registers a new MIME type, application/dialog-info+xml, a new XML namespace, and two new media feature parameters in the SIP tree. So much registering, I'm obsessed 🧚
8.1. MIME Registration for application/dialog-info+xml Type
- MIME media type name:
application - MIME subtype name:
dialog-info+xml - Mandatory parameters: none
- Optional parameters: Same as the charset parameter for
application/xmlas specified in RFC 3023 [8]. - Encoding considerations: Same as the encoding considerations of
application/xmlas specified in RFC 3023 [8]. - Security considerations: See Section 10 of RFC 3023 [8] and Section 7 of this specification.
- Interoperability considerations: none.
- Published specification: This document.
- Applications that use this media type: This document type has been used to support SIP applications such as call return and auto-conference 📞
- Additional Information:
- Magic Number: None
- File Extension:
.xml - Macintosh file type code: "TEXT"
- Personal and email address for further information: Jonathan Rosenberg,
<jdrosen@jdrosen.net> - Intended usage: COMMON
- Author/Change controller: The IETF.
8.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:dialog-info
this section registers a new XML namespace, following the guidelines in [7] ✨
- URI: The URI for this namespace is
urn:ietf:params:xml:ns:dialog-info. - Registrant Contact: The IESG,
<iesg@ietf.org> - 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>Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4235.txt">
RFC4235</a>.</p>
</body>
</html>
END8.3. Schema Registration
this spec registers a schema, following the guidelines in [7] 🌈
- URI:
urn:ietf:params:xml:schema:dialog-info - Registrant Contact: The IESG,
<iesg@ietf.org> - XML: The XML can be found as the sole content of Section 4.4.
8.4. Media Feature Parameter Registration
this section registers two new media feature tags, using the procedures defined in RFC 2506 [14]. The tags go into the sip tree, which is defined in [10] 🦋
8.4.1. Media Feature Tag sip.byeless
- Media feature tag name:
sip.byeless - ASN.1 Identifier: 19
- Summary of the media feature indicated by this tag: This feature tag is a boolean flag. When set, it means the device is incapable of ending a session on its own 🙅♀️
- Values appropriate for use with this feature tag: Boolean.
- The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing what an application can do, like an announcement service, recording service, conference, or call center 📣
- Examples of typical use: Call centers and media services.
- Related standards or documents: RFC 4235
- Security Considerations: This media feature tag can be used in ways that affect application behaviors or may reveal private information. For example, a conferencing or other application may decide to terminate a call prematurely if this media feature tag is set. Therefore, if an attacker can modify the values of this tag, they may be able to affect the behavior of applications. As a result of this, applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, this feature tag should only be trusted as valid when it comes from the user or user agent described by the tag. As a result, protocols for conveying this feature tag SHOULD provide a mechanism for guaranteeing authenticity 🔒
8.4.2. Media Feature Tag sip.rendering
- Media feature tag name:
sip.rendering - ASN.1 Identifier: 20
- Summary of the media feature indicated by this tag: This feature tag holds one of three string values: "yes" means the device is rendering some media from the current session, "no" means it isn't rendering any of the media from the current session, and "unknown" means the device doesn't know this status 🤷♀️
- Values appropriate for use with this feature tag: String.
- The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the state of a device, like a phone or PDA, during a multimedia session 📱
- Examples of typical use: Conferencing, telephone shared-line emulation, and presence applications.
- Related standards or documents: RFC 4235
- Security Considerations: This media feature tag can be used in ways that affect application behaviors or may reveal private information. For example, a conferencing or other application may decide to terminate a call prematurely if this media feature tag is set to "no". Therefore, if an attacker can modify the values of this tag, they may be able to affect the behavior of applications. As a result of this, applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, this feature tag should only be trusted as valid when it comes from the user or user agent described by the tag. As a result, protocols for conveying this feature tag SHOULD provide a mechanism for guaranteeing authenticity 🔐
9. Acknowledgements 🫶
The authors would like to thank Sean Olson for his comments. Thank you, Sean 💜
10. References
10.1. Normative References
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] 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.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[4] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[13] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[14] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
10.2. Informative References
[16] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[17] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[18] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[20] Sparks, R., "Session Initiation Protocol Call Control - Transfer", Work in Progress, July 2005.
Authors' Addresses 🌸
Jonathan Rosenberg, Cisco Systems, 600 Lanidex Plaza, Parsippany, NJ 07054, US. Phone: +1 973 952-5000. EMail: jdrosen@cisco.com. URI: http://www.jdrosen.net
Henning Schulzrinne, Columbia University, M/S 0401, 1214 Amsterdam Ave., New York, NY 10027, US. EMail: schulzrinne@cs.columbia.edu. URI: http://www.cs.columbia.edu/~hgs
Rohan Mahy (editor), SIP Edge LLC. EMail: rohan@ekabal.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Okay so, the IETF is NOT picking sides here 🙅♀️. They don't take a position on whether any Intellectual Property Rights (the legal stuff like patents and copyrights) are valid, how far they reach, or whether you can get a license for them. They also haven't done their own hunt for any such rights 🕵️♀️. If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79 📚.
Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any licensing assurances, or the results of anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️✨.
The IETF also really wants to hear from anyone who spots a copyright, patent, patent application, or other proprietary right that might cover technology needed to implement this standard 🫶. Just send the info to ietf-ipr@ietf.org 💌. Bestie, speak up early, it's giving good citizenship 🌈.
Acknowledgement
Last but not least, the RFC Editor function is currently funded by the Internet Society 💜. Shoutout to them for keeping the lights on for all these documents 🌸👑.
📦 where this page comes from
- ietf: rfc4235 2005-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms