RFC 3959
The Early Session Disposition Type for the Session Initiation Protocol (SIP)
The Early Session Disposition Type for the Session Initiation Protocol (SIP) 🎀
Okay bestie, this is RFC 3959 💖 It's by G. Camarillo from Ericsson, it's on the Standards Track, and it's dated December 2004. The header doesn't list any RFCs it obsoletes or updates, so it's a standalone thing. It's from the Network Working Group 🧚
Status of This Memo 🍓
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Copyright Notice 🌈
Copyright (C) The Internet Society (2004).
Abstract 💜
So this doc adds a brand new disposition type called early-session for the Content-Disposition header field in SIP 💅 The way early-session bodies are treated is basically the same as how session bodies are treated. They both follow the offer/answer model. The only real difference is that session descriptions with the early-session disposition type are used to set up early media sessions inside early dialogs, instead of regular sessions inside regular dialogs. It's giving twins, but with a plot twist 🙈
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Issues Related to Early Media Session Establishment . . . . . 2
4. The Early Session Disposition Type . . . . . . . . . . . . . . 4
5. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Option tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informational References . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 111. Introduction ✨
Okay so, early media is media (think audio and video) that gets exchanged before the called user accepts a particular session 🦋 Inside a dialog, early media kicks off the moment the initial INVITE is sent and keeps going until the User Agent Server (UAS) generates a final response. It can be unidirectional or bidirectional, and the caller, the callee, or both can generate it. The usual callee-made examples are ringing tone and announcements (like queuing status). Caller-made early media is typically voice commands or dual tone multi-frequency (DTMF) tones, used to drive interactive voice response (IVR) systems 📞
The basic SIP spec (RFC 3261 [2]) only supports very simple early media mechanisms. Those simple mechanisms have a bunch of problems with forking and security, and they don't meet the requirements of most apps 😭 RFC 3960 [8] goes further than the mechanisms in RFC 3261 [2]. It describes two early media models using SIP: the gateway model and the application server model 🍓
Both early media models in RFC 3960 [8] are better than the one in RFC 3261 [2], but the gateway model still has issues. Specifically, the gateway model doesn't work well with forking. Even so, the gateway model is still needed, because some SIP entities (especially some gateways) can't implement the application server model 💅
The application server model fixes some of the gateway model's problems, and it's the one that uses the early-session disposition type defined in this document 🌸
2. Terminology 💅
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations 📖
3. Issues Related to Early Media Session Establishment 🦋
Traditionally, early media sessions get set up the same way regular sessions do 🫶 That means an offer/answer exchange where the disposition type of the session descriptions is session. Application servers do an offer/answer exchange with the User Agent Client (UAC) to swap early media exclusively, while UASs use that same offer/answer exchange twice: first to swap early media, and then, once the regular dialog is up, to swap regular media. This way of setting up early media is called the gateway model [8], and it has issues with forking and security. Those issues show up whether the model is used by an application server or by a UAS 🙈
Application servers might not be able to generate an answer for an offer received in the INVITE. The UAC made the offer for the UAS, so it may have applied end-to-end encryption or included info (like key management stuff) that the application server isn't supposed to use. So application servers need a way to do an offer/answer exchange with the UAC that's separate from the offer/answer exchange between the two UAs 🔐
UASs that use the offer/answer exchange carrying regular media to send and receive early media can cause media clipping, as described in Section 2.1.1 of [8]. Some UACs can't receive early media from different UASs at the same time. So when an INVITE forks and several UASs start sending early media, the UAC mutes all the UASs except one (usually picked at random). If the UAS that accepts the INVITE (the one that sends a 200 OK) was muted, a new offer/answer exchange is needed to unmute it. That usually causes media clipping 😭 So UASs need a way to do an offer/answer exchange with the UAC for early media that's separate from the one used for regular media ✨
One possible fix would be to set up a different dialog using a globally routable URI to do an independent offer/answer exchange. That dialog would be labelled as a dialog for early media and would be somehow related to the original dialog at the UAC. But doing all the offer/answer exchanges inside the original dialog has a lot of perks:
- It is simpler.
- It does not have synchronization problems, because all the early dialogs are terminated when the session is accepted.
- It does not require globally routable URIs.
- It does not introduce service interaction issues related to services that may be wrongly applied to the new dialog.
- It makes firewall management easier.
This way of doing offer/answer exchanges for early media is called the application server model [8]. The model uses the early-session disposition type defined in the next section 🌈
4. The Early Session Disposition Type 🌸
We're defining a new disposition type for the Content-Disposition header field: early-session 💖 User agents MUST use early-session bodies to set up early media sessions the same way they use session bodies to set up regular sessions, as described in RFCs 3261 [2] and 3264 [3]. Specifically, early-session bodies MUST follow the offer/answer model and MAY appear in the same messages that session bodies do, except for 2xx responses to an INVITE and ACKs. Still, it is NOT RECOMMENDED to include early offers in INVITEs, because they can fork, and the UAC could get multiple early answers that set up early media streams at roughly the same time 🙃 Also, using the same transport address (IP address plus port) in a session body and in an early-session body is NOT RECOMMENDED. Using different transport addresses (like different ports) to receive early and regular media makes it easy to detect when regular media starts 🎯
If a User Agent (UA) needs to refuse an early-session offer, it MUST do that by refusing all the media streams in it. When SDP [7] is used, that's done by setting the port number of all the media streams to zero.
This is the same mechanism that UACs use to refuse regular offers that arrive in a response to an empty INVITE. 💅
An early media session set up using early-session bodies MUST be terminated when its corresponding early dialog is terminated or when it transitions to a regular dialog 🦋
It is RECOMMENDED that UAs generating regular and early session descriptions use the same codecs in both, as long as that's possible. That way, the remote UA doesn't have to change codecs when the early session turns into a regular session 🫶
5. Preconditions 🫶
RFC 3312 [4] defines a framework for preconditions for SDP. Early-sessions MAY contain preconditions, which are treated the same way as preconditions in regular sessions. In other words, the UAs don't exchange media, and the called user isn't alerted until the preconditions are met 🔥
6. Option Tag 🔥
We're defining an option tag for use in Require and Supported header fields: early-session ✨ A UA that adds the early-session option tag to a message is saying that it understands the early-session disposition type 👑
7. Example 🎀
Okay bestie, let's walk through the message flow between two UAs 💖 INVITE (1) carries an early-session option tag in its Supported header field, plus the body in Figure 2. The UAS replies with a response that has two body parts (Figure 3): one with disposition type session and one with early-session. The session part answers the offer in the INVITE. The early-session part is an offer to set up an early media session ✨ When the UAC gets the 183 (Session Progress) response, it sends back the answer to that early-session offer in a PRACK (Figure 4). The early media session ends when the early dialog turns into a regular dialog, which is when the UAS sends the (5) 200 (OK) response for the INVITE. Iconic 💅
A B
| |
|--------(1) INVITE-------->|
| offer |
| |
|<--(2) Session Progress----|
| early-offer |
| answer |
| |
|---------(3) PRACK-------->|
| early-answer |
| |
|<--------(4) 200 OK--------|
| |
| * * |
| ************************* |
|* Early Media *|
| ************************* |
| * * |
| |
|<--------(5) 200 OK--------|
| |
|----------(6) ACK--------->|
| |
Figure 1: Message flowContent-Type: application/sdp
Content-Disposition: session
v=0
o=alice 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
Figure 2: OfferContent-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
--boundary1
Content-Type: application/sdp
Content-Disposition: session
v=0
o=Bob 2890844725 2890844725 IN IP4 host.example.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30000 RTP/AVP 0
--boundary1
Content-Type: application/sdp
Content-Disposition: early-session
v=0
o=Bob 2890844714 2890844714 IN IP4 host.example.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30002 RTP/AVP 0
--boundary1--
Figure 3: Early offer and answerContent-Type: application/sdp
Content-Disposition: early-session
v=0
o=alice 2890844717 2890844717 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20002 RTP/AVP 0
Figure 4: Early answer8. Security Considerations 🔐
Here's the tea: the security stuff for early-session bodies in SIP is the same as for regular session bodies. They're part of the offer/answer model, so no new drama 😭
SIP uses the offer/answer model [3] to set up early sessions in both the gateway and the application server models. UAs make a session description with the transport address (IP address plus port) where they want to receive media, then send it to their peer in a SIP message. When media packets show up at that transport address, the UA assumes they're coming from whoever sent the SIP message with the session description. But attackers may try to read the SIP message contents and send packets to the transport address in the session description. To stop that, UAs SHOULD encrypt their session descriptions (e.g., using S/MIME) 🛡️
Even if a UA encrypts its session descriptions, an attacker may still try to guess the transport address the UA is using and send media packets there. Guessing is sometimes easier than it sounds, since many UAs always grab the same initial media port 👀 To stop this, UAs SHOULD use media-level authentication mechanisms (e.g., Secure Realtime Transport Protocol (SRTP)[6]). Also, UAs that want their communications to stay confidential SHOULD use media-level encryption mechanisms (e.g, SRTP [6]) 🔒
Attackers may also try to make a UA send media to a victim as part of a DoS attack. They can do this by sending the UA a session description containing the victim's transport address. To prevent this attack, the UA SHOULD engage in a handshake with the owner of the transport address received in a session description (just verifying they're willing to receive media) before sending a large amount of data to that address. This check can be done with a connection oriented transport protocol, with Simple Traversal of the UDP Protocol through NAT (STUN)[5] in an end-to-end fashion, or with the key exchange in SRTP [6] 🚨
Heads up: in any event, the previous security considerations are not early media specific. They apply to the use of the offer/answer model in SIP to establish sessions in general.
Now for the early media-specific risk, which is kind of like "toll fraud" in the Public Switched Telephone Network (PSTN) 💀 Some operators charge differently for early media and regular media. So if UAs are allowed to swap early media for free but have to pay for regular media sessions, rogue UAs may try to set up a bidirectional early media session and never send a 2xx response for the INVITE. Sneaky, right? 🙈
On the flip side, some application servers (e.g., Interactive Voice Response systems) use bidirectional early media to collect info from callers (e.g., the Personal Identification Number (PIN) code of a calling card). So we do not recommend that operators disallow bidirectional early media. Instead, operators should consider a remedy of charging early media exchanges that last too long, or stopping them at the media level (according to the operator's policy) 🫶
9. IANA Considerations 📋
This document defines a new Content-Disposition header field disposition type (early-session) in Section 4. That value has been registered in the IANA registry for Content-Dispositions with the following description:
early-session The body describes an early communications
session, for example, an RFC 2327 SDP bodyThis document also defines a SIP option tag (early-session) in Section 6. It has been registered in the SIP parameters registry (http://www.iana.org/assignments/sip-parameters) under "Option Tags", with the following description:
early-session A UA adding the early-session option tag to a
message indicates that it understands the early-
session content disposition.10. Acknowledgements 🌸
Big thanks to Francois Audet, Christer Holmberg, and Allison Mankin for leaving useful comments on this document 🫶
11. References 📚
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[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. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.
[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.11.2. Informational References
[7] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[8] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004.Author's Address 🧚
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.comFull Copyright Statement ⭐
Copyright (C) The Internet Society (2004).
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 💜
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't say it has made any independent effort to identify any such rights. Info on the IETF's procedures for rights in IETF Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org 📨
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🫶✨
📦 where this page comes from
- ietf: rfc3959 2004-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms