RFC 3960

Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)

📅 published December 2004, from ietf

RFC 3960 💖 Early Media and Ringing Tone Generation in SIP

  • RFC number: 3960 🎀
  • Authors: G. Camarillo (Ericsson) and H. Schulzrinne (Columbia University) ✨
  • Category: Informational 🦋
  • Date: December 2004 🌸

It doesn't have Obsoletes or Updates fields in its header, so it's a standalone doc. 💅

Status of This Memo ✨

This memo is just information for the Internet community. It is NOT a standard of any kind, and it's free to share, no limits. 🫶

Copyright (C) The Internet Society (2004). 💜

Abstract 🌸

This doc is all about handling early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also covers the inputs you need to think about when writing local policies for ringing tone generation. 🎀

Table of Contents 📋

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Session Establishment in SIP . . . . . . . . . . . . . . . . .  3
3.  The Gateway Model. . . . . . . . . . . . . . . . . . . . . . .  4
    3.1.  Forking. . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.2.  Ringing Tone Generation. . . . . . . . . . . . . . . . .  5
    3.3.  Absence of an Early Media Indicator. . . . . . . . . . .  7
    3.4.  Applicability of the Gateway Model . . . . . . . . . . .  8
4.  The Application Server Model . . . . . . . . . . . . . . . . .  8
    4.1.  In-Band Versus Out-of-Band Session Progress Information.  9
5.  Alert-Info Header Field. . . . . . . . . . . . . . . . . . . .  9
6.  Security Considerations. . . . . . . . . . . . . . . . . . . .  9
7.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    8.1.  Normative References . . . . . . . . . . . . . . . . . . 11
    8.2.  Informative References . . . . . . . . . . . . . . . . . 11
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
    Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. Introduction 🦋

Okay so, early media is media (think audio and video) that gets swapped before the called user accepts the session. Inside a dialog, early media starts the moment the initial INVITE is sent and keeps going until the User Agent Server (UAS) generates a final response. It can go one way or both ways, and it can come from the caller, the callee, or both. 💅

The main callee-generated examples are ringing tone and announcements (like queuing status). Caller-generated early media usually means voice commands or dual tone multi-frequency (DTMF) tones to drive interactive voice response (IVR) systems. 📞

The basic SIP spec (RFC 3261 [1]) only supports very simple early media mechanisms. Those simple mechanisms have a bunch of problems with forking and security, and they don't cover the requirements of most apps. 😭 This doc goes beyond what RFC 3261 [1] defines and describes two models of early media in SIP: the gateway model and the application server model. ✨

Both early media models in this document are better than the one in RFC 3261 [1], but the gateway model still has issues. Mainly, it doesn't play nicely with forking. 🙈 It's still needed, though, 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 issues. It uses the early-session disposition type, which is specified in [2]. 🔥

Here's the roadmap. Section 2 covers the offer/answer model when there's no early media, and Section 3 introduces the gateway model, where the early media session is set up using the early dialog created by the original INVITE. Sections 3.1, 3.2, and 3.4 cover the gateway model's limitations and when it's appropriate to use it. Section 4 introduces the application server model, which, as mentioned, fixes some gateway model issues. Section 5 talks about how the Alert-Info header field works in both early media models. 🗺️

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [9]. 📜

2. Session Establishment in SIP 🎀

Before we get into both early media models, let's quickly recap how session establishment works in SIP. This keeps the features that are intrinsic to SIP (like media being played before the 200 (OK) to avoid media clipping) separate from early media operations. 🧠

SIP [1] uses the offer/answer model [3] to negotiate session parameters. One of the user agents, the offerer, prepares a session description called the offer. The other user agent, the answerer, replies with another session description called the answer. This two-way handshake lets both user agents agree on the session parameters they'll use to exchange media. 🤝

The offer/answer model is decoupled from the messages that carry the session descriptions. For example, the offer can ride in an INVITE request and the answer can arrive in the 200 (OK) response to that INVITE. Or, the offer can be sent in the 200 (OK) for an empty INVITE, with the answer sent in the ACK. When reliable provisional responses [4] and UPDATE requests [5] are used, there are many more ways to swap offers and answers. 🌈

Media clipping happens when the user (or the machine generating media) thinks the media session is already up, but the setup isn't finished yet. The user starts talking, and the first few syllables or even the first few words get lost. 😩

When the offer/answer exchange happens in the 200 (OK) response and the ACK, media clipping is unavoidable. The called user starts talking at the same moment the 200 (OK) is sent, but the UAS can't send any media until the answer from the User Agent Client (UAC) shows up in the ACK. 💔

Good news: media clipping does NOT show up in the most common offer/answer exchange (an INVITE with an offer and a 200 (OK) with an answer). UACs are ready to play incoming media packets as soon as they send an offer, because they can't count on the 200 (OK) arriving before they start playing out media for the caller. SIP signalling and media packets usually travel different paths, so media packets might show up before the 200 (OK) does. 🦋

There's another kind of media clipping, not related to early media either, that happens in the caller-to-callee direction. When the callee picks up and starts talking, the UAS sends a 200 (OK) response with an answer, at the same time as the first media packets. If those first media packets reach the UAC before the answer, and the caller starts talking, the UAC can't send media until the 200 (OK) response from the UAS arrives. 😬

3. The Gateway Model 🌸

SIP uses the offer/answer model to negotiate session parameters (as described in Section 2). An offer/answer exchange that happens before a final response to the INVITE is sent sets up an "early" media session. Early media sessions end when a final response to the INVITE is sent. If that final response is a 200 (OK), the early media session turns into a regular media session. If it's a non-200 class final response, the early media session just gets torn down. 🔥

Not surprisingly, media exchanged within an early media session is called early media. The gateway model manages early media sessions using offer/answer exchanges in reliable provisional responses, PRACKs, and UPDATEs. 🧚

The gateway model is seriously limited when forking is involved, as described in Section 3.1. So, using it is only acceptable when the User Agent (UA) can't tell early media apart from regular media, as described in Section 3.4. In any other situation (which is the majority of UAs), the application server model described in Section 4 is strongly recommended instead. 👑

3.1. Forking 🍓

Without forking, and assuming the initial INVITE contains an offer, the gateway model doesn't cause media clipping. Following normal SIP procedures, the UAC is ready to play any incoming media as soon as it sends the initial offer in the INVITE. The UAS sends the answer in a reliable provisional response and can send media as soon as there's media to send. Even if the first media packets reach the UAC before the 1xx response, the UAC will still play them. ✨

Note that, in some situations, the UAC needs to receive the answer before it can play any media. UAs in that situation (for example, when QoS, media authorization, or media encryption is required) use preconditions to avoid media clipping. 🔐

On the other hand, if the INVITE forks, the gateway model may cause media clipping. This happens when the UAC gets different answers to its offer in several provisional responses from different UASs. Now the UAC has to deal with bandwidth limits and pick which early media session to use. 😵‍💫

If the UAC gets early media from different UASs, it has to present it to the user. If the early media is audio, playing several audio streams to the user at once can be super confusing. 🙉 Other media types (like video), on the other hand, can be presented to the user at the same time. For example, the UAC can build a mosaic out of the different inputs. 🖼️

Even with media types that can be played together, if the UAC has limited bandwidth, it won't be able to receive early media from all the different UASs at once. So, a lot of the time, the UAC has to choose a single early media session and "mute" the ones sending UPDATE requests. 🎚️

It's hard to decide which early media sessions carry the more important information from the caller's perspective. In fact, in some scenarios, the UA can't even match media packets to their particular SIP early dialog. So, UACs typically pick one early dialog at random and mute the rest. 🎲

If one of the muted early media sessions turns into a regular media session (meaning the UAS sends a 2xx response), media clipping is likely. The UAC typically sends an UPDATE with a new offer (once it gets the 200 (OK) for the INVITE) to unmute the media session. The UAS can't send any media until it gets that offer from the UAC. So if the caller starts talking before the UAC's offer arrives, their words will get lost. 😭

Having the UAS send the UPDATE to unmute the media session (instead of the UAC) doesn't avoid media clipping in the backward direction, and it causes possible race conditions. 🏃‍♀️💨

3.2. Ringing Tone Generation ✨

okay so in the PSTN, telephone switches usually play ringing tones for the caller to show the callee is being alerted 📞 when, where, and how those tones get generated has been standardized. like, the callee's local exchange generates a standardized ringing tone while the callee is being alerted. it makes total sense for a standardized approach to give users this feedback in a homogeneous environment like the PSTN, where all the terminals have a similar user interface 💅

this homogeneity is NOT found among SIP user agents 🙈 SIP UAs have different capabilities and different user interfaces, and they may be used to set up sessions that don't involve audio at all. so the way a SIP UA shows the user what's happening during session establishment is a matter of local policy. for example, a UA with a Graphical User Interface (GUI) might display a message on the screen when the callee is being alerted, while another UA might show a picture of a phone ringing instead 🖼️ many SIP UAs choose to copy the look and feel of PSTN phones, so they play a ringing tone for the caller when the callee is being alerted. that UAC is supposed to generate ringing tones locally for its user as long as no early media is received from the UAS. if the UAS sends early media (like an announcement or a special ringing tone), the UAC is supposed to play that instead of generating the ringing tone locally 🎀

here's the tricky part 😭 sometimes it's hard for a UAC to know whether it's going to receive early media or whether it should generate local ringing. a UAS can send early media without using reliable provisional responses (very simple UASs do this), or it can send an answer in a reliable provisional response without any plan to send early media (this happens when preconditions are used). so just by looking at the SIP signalling, a UAC can't be sure whether there will be early media for a particular session. the UAC needs to check whether media packets are arriving at a given moment 👀

An implementation could even choose to look at the contents of the media packets, since they could carry only silence or comfort noise. 🤫

so with all that in mind, a UAC should develop its local policy for local ringing generation 🧚 for example, a POTS ("Plain Old Telephone Service")-like SIP User Agent (UA) could implement the following local policy:

  1. Unless a 180 (Ringing) response is received, never generate local ringing.
  2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
  3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session. 🔔

at first glance, this policy might look hard to implement in decomposed UAs (i.e., media gateway controller and media gateway) 😵‍💫 but it's the same policy described in Section 2, which must be implemented by any UA. so any UA should play incoming media packets (and stop local ringing tone generation if it was happening) to avoid media clipping, even if the 200 (OK) response hasn't arrived yet. the tools to implement this early media policy are already available to any UA that uses SIP 🙌

also, while it's not desirable to standardize one common local policy that every SIP UA follows, a particular subset of more or less homogeneous SIP UAs could use the same local policy by convention. examples of these subsets could be "all the PSTN/SIP gateways" or "every 3GPP IMS (Third Generation Partnership Project Internet Multimedia System) terminal" 🌈 however, defining the particular common policy that these groups of SIP devices may use is outside the scope of this document 🫶

3.3. Absence of an Early Media Indicator 🦋

SIP, unlike other signalling protocols, does NOT provide an early media indicator 😭 there's no information about whether early media is present or absent in SIP. an indicator like that could be used to avoid generating a local ringing tone at the UAC when the UAS intends to provide an in-band ringing tone or some kind of announcement. but in most cases, such an indicator would be of little use because of the way SIP works 🙃

one big reason a potential early media indicator wouldn't help much is the loose coupling between SIP signalling and the media path 🔗 SIP signalling takes a different path than the media. the media path is usually optimized to reduce end-to-end delay (e.g., minimum number of intermediaries), while the SIP signalling path usually goes through a bunch of proxies providing different services for the session. so it's very likely that the media packets carrying early media reach the UAC before any SIP message that could contain an early media indicator 💨

that said, sometimes SIP responses reach the UAC before any media packet does. there are situations where the UAS wants to send early media but can't do it right away. for example, UAs using Interactive Connectivity Establishment (ICE) [6] may need to exchange several Simple Traversals of the UDP Protocol through NAT (STUN) messages before they can exchange media 🛜 in this situation, an early media indicator would keep the UAC from generating a local ringing tone during that time. however, while the early media isn't arriving at the UAC, the user wouldn't know the remote user is being alerted, even though a 180 (Ringing) had been received 😬 so a better solution is to apply a local ringing tone until the early media packets can be sent from the UAS to the UAC. this solution doesn't require any early media indicator ✨

Note that migrations from local ringing tone to early media at the UAC happen in the presence of forking as well: one UAS sends a 180 (Ringing) response, and later, another UAS starts sending early media. 🍓

3.4. Applicability of the Gateway Model 🌸

Section 3 described some of the limitations of the gateway model 🥲 it causes media clipping in forking scenarios and requires media detection to generate local ringing properly. these issues are addressed by the application server model, described in Section 4, which is the recommended way to generate early media that isn't continuous with the regular media generated during the session 👑

so the gateway model is acceptable in situations where the UA can't tell early media apart from regular media 💁‍♀️ a PSTN gateway is a classic example. the PSTN gateway receives media from the PSTN over a circuit and sends it to the IP network. the gateway isn't aware of the contents of the media, and it doesn't know exactly when the transition from early to regular media happens. from the PSTN's point of view, the circuit is a continuous source of media 🔁

4. The Application Server Model 💜

the application server model means the UAS behaves like an application server to set up early media sessions with the UAC 🧚‍♀️ the UAC indicates support for the early-session disposition type (defined in [2]) using the early-session option tag. this way, UASs know they can keep offer/answer exchanges for early media (early-session disposition type) separate from regular media (session disposition type) 🎀

sending early media using a different offer/answer exchange than the one used for regular media helps avoid media clipping when forking happens 🙌 the UAC can reject or mute new offers for early media without muting the sessions that will carry media once the original INVITE is accepted. the UAC can also prioritize media received over those latter sessions. this way, the application server model transitions from early to regular media at the right moment ⭐

having a separate offer/answer exchange for early media also helps UACs decide whether local ringing should be generated 🔔 if a new early session gets established and that early session contains at least one audio stream, the UAC can assume there will be incoming early media, so it can skip generating local ringing.

An alternative model would add a new stream, with an "early media" label, to the original session between the UAC and the UAS using an UPDATE instead of establishing a new early session. We chose to establish a new early session to stay coherent with the mechanism used by application servers that are NOT co-located with the UAS. This way, the UAS uses the same mechanism as any application server in the network to interact with the UAC. 🤓

4.1. In-Band Versus Out-of-Band Session Progress Information 🎶

even when the application server model is used, a UA still has to choose which early media sessions get muted and which ones are rendered to the user 🎛️ to make that choice easier, it is strongly recommended that information that isn't essential for the session not be sent using early media. for instance, UAs should not use early media to send special ringing tones 🙅‍♀️ the status code and the reason phrase in SIP can already tell the remote user about the progress of session establishment, without the problems that come with early media 💖

5. Alert-Info Header Field 🏷️

the Alert-Info header field lets you specify alternative ringing content, like a ringing tone, for the UAC. this header field tells the UAC which tone should be played if local ringing is generated, but it does NOT tell the UAC when to generate local ringing 🫠 a UAC should follow the rules described above for ringing tone generation in both models. if, after following those rules, the UAC decides to play local ringing, it can then use the Alert-Info header field to generate it 🔥

6. Security Considerations 🔒✨

Okay bestie, security time, and this part is seriously important 😭. SIP uses the offer/answer model [3] to set up early sessions in both the gateway and the application server models. UAs (User Agents) make a session description with the transport address (that's the 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 address, the UA assumes they come from whoever sent the SIP message with the session description. But attackers may try to read the SIP message and send packets to that transport address anyway 👀. So to stop that, UAs SHOULD encrypt their session descriptions (e.g., using S/MIME) 🔐.

Even if a UA encrypts its session descriptions, an attacker might still guess the transport address and send media packets there 🙈. Guessing is sometimes easier than it sounds, because lots of UAs always grab the same initial media port 💀. To prevent this, UAs SHOULD use media-level authentication mechanisms such as the Secure Realtime Transport Protocol (SRTP)[7] 🛡️. And UAs that want their communications to stay confidential SHOULD use media-level encryption mechanisms (e.g, SRTP [7]) 💜.

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 stop this, the UA SHOULD engage in a handshake with the owner of the transport address it received in a session description (just checking that they're willing to receive media) before sending a large amount of data to that address 🤝. This check can be done by using a connection oriented transport protocol, by using STUN [8] in an end-to-end fashion, or by the key exchange in SRTP [7] ✨.

Heads up: the security considerations above are not early media specific. They apply to the usage of the offer/answer model in SIP to establish sessions in general, so keep that in mind 🫶.

Now for the early media specific risk, which is kind of like "toll fraud" in the PSTN 🤑. This one tries to exploit the different charging policies some operators apply to early and regular media. When UAs are allowed to exchange 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 200 (OK) response for the INVITE 😈. Sneaky, but not iconic.

On the other hand, some application servers (e.g., Interactive Voice Response systems) use bidirectional early media to collect information from callers, like the 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) 💅.

7. Acknowledgments 🫶

Jon Peterson shared useful ideas on separating the gateway model from the application server model 💖.

Paul Kyzivat, Christer Holmberg, Bill Marshall, Francois Audet, John Hearty, Adam Roach, Eric Burger, Rohan Mahy, and Allison Mankin gave useful comments and suggestions 🌸. Thank you, legends 👑.

8. References 📚

8.1. Normative References

[1] 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.

[2] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.

[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

8.2. Informative References

[4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.

[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.

[6] Rosenberg, J., "Interactive connectivity establishment (ICE): a methodology for network address translator (NAT) traversal for the session initiation protocol (SIP)", Work in progress, July 2003.

[7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[8] 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.

[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses 🧚

Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland

EMail: Gonzalo.Camarillo@ericsson.com

Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA

EMail: schulzrinne@cs.columbia.edu

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 regarding 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 the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from 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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 💖✨

📦 where this page comes from