RFC 7195
Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)
RFC 7195: Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) 🎀
okay so this one is an Internet Standards Track doc from May 2014 🌸, written by M. Garcia-Martin (Ericsson) and S. Veikkolainen (Nokia). It's published under ISSN 2070-1721, and its header doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅
Abstract
This memo describes use cases, requirements, and protocol extensions for using the SDP offer/answer model to set up audio and video media streams over circuit-switched bearers in the PSTN ✨
Status of This Memo
This is an Internet Standards Track document. It's a product of the IETF, so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741. Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7195.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🔥
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🧚
Table of Contents
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Requirements ....................................................5
4. Overview of Operation ...........................................5
4.1. Example Call Flow ..........................................6
5. Protocol Description ............................................7
5.1. Level of Compliance ........................................7
5.2. Extensions to SDP ..........................................7
5.2.1. Connection Data .....................................7
5.2.2. Media Descriptions ..................................9
5.2.3. Correlating the PSTN Circuit-Switched
Bearer with SDP ....................................10
5.2.3.1. The "cs-correlation" Attribute ............11
5.2.3.2. Caller ID Correlation Mechanism ...........12
5.2.3.3. User-User Information Element
Correlation Mechanism .....................13
5.2.3.4. DTMF Correlation Mechanism ................14
5.2.3.5. External Correlation Mechanism ............15
5.2.3.6. Extensions to Correlation Mechanisms ......16
5.3. Negotiating the Correlation Mechanisms ....................17
5.3.1. Determining the Direction of the
Circuit-Switched Bearer Setup ......................17
5.3.2. Populating the "cs-correlation" Attribute ..........18
5.3.3. Considerations for Correlations ....................18
5.4. Considerations for Usage of Existing SDP ..................19
5.4.1. Originator of the Session ..........................19
5.4.2. Contact Information ................................20
5.5. Considerations for Usage of Third Party Call
Control (3PCC) ............................................20
5.6. Offer/Answer Mode Extensions ..............................20
5.6.1. Generating the Initial Offer .......................21
5.6.2. Generating the Answer ..............................23
5.6.3. Offerer Processing the Answer ......................26
5.6.4. Modifying the Session ..............................27
5.7. Formal Syntax .............................................28
6. Examples .......................................................30
6.1. Single PSTN Audio Stream ..................................30
6.2. Advanced SDP Example: Circuit-Switched Audio and
Video Streams .............................................32
7. Security Considerations ........................................33
8. IANA Considerations ............................................35
8.1. Registration of the New "cs-correlation" SDP Attribute ....35
8.2. Registration of a New "nettype" Value .....................36
8.3. Registration of a New "addrtype" Value ....................36
8.4. Registration of a New "proto" Value .......................36
9. Acknowledgments ................................................37
10. References ....................................................37
10.1. Normative References .....................................37
10.2. Informative References ...................................381. Introduction ✨
SDP [RFC4566] is built for describing multimedia sessions, whether you're announcing them, inviting people to them, or starting them in some other way 💖 It's mostly used to describe media streams carried over the Real-Time Transport Protocol (RTP) [RFC3550], using the audio and video profiles from "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551].
But SDP isn't married to RTP 🦋 It can also describe other media transport protocols. Earlier work already did this for ATM bearer connections [RFC3108] and for the Message Session Relay Protocol [RFC4975].
SDP usually rides along inside Session Initiation Protocol (SIP) [RFC3261] messages so the endpoints can agree on a shared media description. "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264] is the framework that lets two endpoints swap SDP media descriptions and agree on which media streams to use, plus the media-related parameters 🌈
Sometimes you'd want the media stream to go over a circuit-switched bearer connection even when the session signaling runs over an IP bearer 🍓 Picture two mobile devices that can do both circuit-switched and packet-switched calls over a low-bandwidth radio bearer. That radio bearer might be terrible for real-time audio or video, while a circuit-switched bearer would give a much better perceived quality of service. So in this scenario, SDP and its higher-layer session control protocol (for example, SIP [RFC3261]) run over normal IP connectivity, and the audio or video comes through the classic circuit-switched bearer 😭
This document only covers circuit-switched bearers in the PSTN, not circuit-switched networks in general 👑 The mechanisms here require a PSTN call signaling protocol to be in use, such as ITU-T Q.931 [ITU.Q931.1998] or 3GPP TS 24.008 [TS.24.008].
Setting up the signaling relationship in the IP domain, instead of only setting up a circuit-switched call, also lets you negotiate other IP-based media in the same session that aren't sensitive to jitter and delay. Think text messaging or presence information 💜
Later on, the mobile device might wander into an area with a high-bandwidth packet-switched bearer, like a Wireless Local Area Network (WLAN) connection. At that point the device may do a handover and move the audio or video media streams onto the high-speed bearer. That means a fresh SDP offer/answer exchange, which renegotiates the media streams 🔥
There are other use cases too. An endpoint might have both circuit-switched and packet-switched connectivity, but the same audio or video codecs won't work on both access networks. For instance, the circuit-switched audio or video stream supports narrow-bandwidth codecs, while the packet-switched access can use any audio or video codec the endpoint has implemented. In that case, it could be useful for the endpoint to describe different codecs for each access type, then agree on the bearer with the remote endpoint 🧚
Third party call control is another use case, where setup time gets better when the circuit-switched bearer in the PSTN is described together with one or more codecs ⭐
The rest of the document is laid out like this: Section 2 covers the document conventions, Section 3 lists the requirements, Section 4 gives an overview of the proposed solutions, and Section 5 has the protocol description. Section 6 shows examples of circuit-switched audio or video streams in SDP. Sections 7 and 8 cover Security and IANA considerations, respectively 🎀
2. Conventions Used in This Document 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119], and they show the requirement levels for compliant implementations 🫶
3. Requirements 💅
This section lists the general requirements specific to audio or video media streams over circuit-switched bearers. Each one gets its own REQ label 🌸
- REQ-1: Endpoints MUST have a mechanism available to negotiate and agree on an audio or video media stream that gets established over a circuit-switched bearer ✨
- REQ-2: The mechanism MUST let the endpoints combine circuit-switched audio or video media streams with other complementary media streams, such as text messaging 💖
- REQ-3: The mechanism MUST let the endpoint negotiate the direction of the circuit-switched bearer. In other words, it decides which endpoint is active when the circuit-switched bearer gets initiated 🦋
- REQ-4: The mechanism MUST be independent of the type of circuit-switched access, such as Integrated Services Digital Network (ISDN) or Global System for Mobile Communication (GSM) 🌈
- REQ-5: There MUST be a mechanism that helps an endpoint match an incoming circuit-switched bearer with the one negotiated in SDP, so it isn't mixed up with some other unrelated incoming call 🍓 If correlating by programmatic means isn't possible, the human user may do the correlation instead 🙈
- REQ-6: It MUST be possible for endpoints to advertise a different list of audio or video codecs for the circuit-switched audio or video stream than the list used for a packet-switched audio or video stream 🧚
- REQ-7: It MUST be possible for endpoints to NOT advertise the list of available codecs for circuit-switched audio or video streams 👑
4. Overview of Operation ✨
okay so this memo is basically a glow-up for SDP [RFC4566]! 💅 It lets you describe an audio or video stream that runs over a circuit-switched bearer, aka the old-school phone network. Two brand new things get added so c= and m= lines can handle it: a network type called PSTN and a protocol type also called PSTN. The details live in Section 5.2. Circuit-switched bearers are connection-oriented, so the memo borrows the connection-oriented extensions from RFC 4145 [RFC4145] to sort out which side is active and which is passive when the call gets set up. That part is in Section 5.3.1. 🦋
4.1. Example Call Flow 📞
Let's look at the example in Figure 1 🎀 Endpoint A has access to both an IP bearer and a circuit-switched bearer for talking to other endpoints. It decides the circuit-switched one gives better perceived quality for voice, so it sends an SDP offer describing an audio stream over a circuit-switched bearer.
Endpoint A Endpoint B
| (1) SDP offer (PSTN audio) |
|----------------------------------->|
| |
| (2) SDP answer (PSTN audio) |
|<-----------------------------------|
| |
| PSTN call setup |
|<-----------------------------------|
| |
| |
|<===== media over PSTN bearer =====>|
| |
Figure 1: Example FlowEndpoint B gets the offer and realises its own IP bearer is not up to the job for real-time audio 😭 Good news, though: it has a PSTN circuit-switched bearer available for audio. So it answers with its own SDP description of an audio stream over a circuit-switched bearer. 🌸
During the offer/answer dance, A and B also agree on which way the circuit-switched bearer should be set up. In this example Endpoint B is the active party, which just means it's the one that places the circuit-switched call to the other endpoint. 📲 The offer/answer exchange carries identifiers or references that can be used on the circuit-switched network to address the other endpoint. It also carries info that lets an endpoint tell that an incoming circuit-switched bearer setup belongs to the session the two of them are already building. Main character energy, honestly. ✨
Endpoint B sets up the circuit-switched bearer towards Endpoint A using whatever mechanisms are defined for the network type in question. When Endpoint A gets that incoming connection attempt, it can work out that the attempt is related to the session it is in the middle of establishing with B. 🧚
Endpoint A accepts the circuit-switched connection, and the bearer setup is complete 🎉 Both endpoints can now use the circuit-switched connection for two-way audio.
If, for some reason, Endpoint B wants to reject the offered stream, it sets the port number of that stream to zero, as specified in RFC 3264 [RFC3264]. And if B doesn't understand some of the SDP attributes defined in this document, it ignores them, as specified in RFC 4566 [RFC4566]. Honestly, that's just good manners. 💜
5. Protocol Description 🎀
5.1. Level of Compliance 💅
Implementations that are compliant with this specification MUST implement the SDP extensions described in Section 5.2 and MUST implement the considerations discussed in Sections 5.3, 5.4, and 5.6. No skipping, bestie! 🫶
5.2. Extensions to SDP 🦋
This section gives you the syntax and semantics of the extensions needed to describe audio or video media streams over circuit-switched bearers in SDP. It's the actual rulebook. 📖
5.2.1. Connection Data 📞
SDP [RFC4566] says the connection data line looks like this:
c=<nettype> <addrtype> <connection-address>Here, <nettype> is the network type, <addrtype> is the address type, and <connection-address> is the connection address, which depends on the address type. 🌈
Right now the only network type defined is IN, which means Internet. The address types IP4 and IP6 tell you what kind of IP address you're looking at. 🌐
This memo adds a brand new network type for circuit-switched bearers in the PSTN, and its mnemonic is PSTN. ☎️
For the address type, we first thought about describing E.164 telephone numbers. So we define a new E164 address type, and it's only meant for use with the PSTN network type. An E164 connection address contains an E.164 number represented according to the ITU-T E.164 [ITU.E164.2010] recommendation. 🔥
Quick fun fact: an international E.164 number usually has a leading + sign. For consistency's sake, we also require the E.164 number to be prepended with a +, even when routing in the PSTN wouldn't actually need it. 💖
Sometimes an endpoint only knows it has a circuit-switched bearer and doesn't know the E.164 number that's been allocated to it. In that case, a dash (-) is used to indicate an unknown connection address. This keeps the connection data line consistent with SDP syntax. 🙈
Please note that the E164 address type defined in this memo is used exclusively with the PSTN network type, following the regular offer/answer procedures [RFC4566]. 💜
Note: RFC 3108 [RFC3108] also defines address type "E.164". This definition is distinct from the one defined by this memo and shall not be used with <nettype> "PSTN".
This memo only uses the international form of E.164 numbers, meaning ones that include a country code and, as said above, start with a + sign. Implementations that follow this specification and use the E164 address type together with the PSTN network type MUST use the 'global-number-digits' construction specified in RFC 3966 [RFC3966] to represent international E.164 numbers. That format requires the + sign, and it also lets you include one or more 'visual-separator' constructions to make the number easier for humans to read (see Section 5.7). Very organised of it. 🍓
Also, <connection-address> MUST NOT be omitted when it's unknown, because leaving it out would break the basic syntax of SDP [RFC4566]. In that case, it MUST be set to a -. 🫶
Here are some examples of the extended connection data line:
c=PSTN E164 +441134960123
c=PSTN E164 -When the <addrtype> is E164, the connection address is one of the following:
- an international E.164 number (prepended with a '+' sign)
- the value
-, signifying that the address is unknown - any other value resulting from the production rule of connection-address in RFC 4566 [RFC4566], but in all cases any value encountered will be ignored. 🙃
5.2.2. Media Descriptions 🎶
SDP [RFC4566] says the media description line looks like this:
m=<media> <port> <proto> <fmt> ...The <media> subfield carries the media type. To set up an audio bearer, you use the existing audio media type. For a video bearer, you use the existing video media type. ✨
The <port> subfield is the transport port the media stream gets sent to. Circuit-switched access doesn't have port numbers, so this subfield doesn't carry anything meaningful. To keep things compliant with SDP syntax anyway, implementations SHOULD set the <port> subfield to the discard port value 9, and MUST ignore it on reception. Ignore the port, bestie, it's just there to look pretty 🙈
According to RFC 3264 [RFC3264], a port number of zero in the offer of a unicast stream means the stream is offered but must not be used. If a port number of zero shows up in the answer of a unicast stream, that means the stream is rejected. These rules still apply when the media line represents a circuit-switched bearer. 🔥
The <proto> subfield is the transport protocol. The circuit-switched bearer uses whatever transport protocol it has available. This subfield SHOULD be set to the mnemonic PSTN, which keeps it syntactically correct with SDP [RFC4566] and tells everyone that circuit-switched protocols are in use on the PSTN. 📞
The <fmt> subfield is the media format description. In the classic SDP setup for describing RTP-based media streams, when <proto> is RTP/AVP or RTP/SAVP, the <fmt> subfield holds the payload types defined in the RTP audio profile [RFC3551]. 🌸
When RTP/AVP is used in the <proto> field, the <fmt> subfield holds the RTP payload type numbers. Here, we use <fmt> to list the codecs available over the circuit-switched bearer, by reusing the conventions and payload type numbers defined for RTP/AVP. The RTP audio and video media types, when applied to PSTN circuit-switched bearers, just stand for an audio or video codec. If the endpoint can work out the list of available codecs for circuit-switched media streams, it MUST use the matching payload type numbers in the <fmt> subfield. 🎀
Sometimes the endpoint can't figure out the list of available codecs for circuit-switched media streams. In that case, to stay syntactically compliant with SDP [RFC4566], the endpoint MUST include a single dash (-) in the <fmt> subfield. 💀
As RFC 4566 [RFC4566] says, the media format descriptions are listed in priority order. 👑
Here are some examples of media descriptions for circuit-switched audio streams:
m=audio 9 PSTN 3 0 8
m=audio 9 PSTN -And here's one for a circuit-switched video stream:
m=video 9 PSTN 34
m=video 9 PSTN -5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP ✨
okay bestie, so the endpoints should be able to match up the circuit-switched bearer with the session negotiated over SDP 🎀 why? so they don't ring for an incoming circuit-switched bearer that's actually part of the session already controlled by SDP (and SIP) 🙈 no double rings, no cap 💅
There are a few ways to do this correlation. This memo gives us three mechanisms that can be combined (they're not mutually exclusive, iykyk 💜), plus a fourth for when the others just aren't possible or don't work out: correlation done by external means, usually by the human user 🫶 Other correlation mechanisms might exist too, and they'll get specified whenever the need pops up ✨
Every mechanism has the same vibe: some unique info gets sent in the SDP and in the circuit-switched signaling protocol. If those pieces match, the circuit-switched bearer is part of the session from the SDP exchange. If they don't, there's no guarantee the bearer is related to that session 😭
The first one is the Caller ID exchange between the endpoints. The Caller ID is also available as the Calling Party Number in the circuit-switched signaling 📞
The second one puts a value in SDP that's also sent in the User-User Information Element, which is part of the bearer setup signaling in the PSTN 🦋
The third one puts a string in SDP representing Dual-Tone Multi-Frequency (DTMF) digits, which get sent right after the circuit-switched bearer is established 🔢
The fourth one declares support for cases where correlation is done by external means. Typically that means the human gets to decide 🙋♀️ This is how some current conferencing systems work: after you log on to the conference, the system calls back your phone number to set up audio, and it's up to you to accept or reject the incoming call. By declaring explicit support for this mechanism, endpoints can only use it when that possibility actually exists ✨
Endpoints may opt to implement any combination of the correlation mechanisms in Sections 5.2.3.2, 5.2.3.3, 5.2.3.4, and 5.2.3.5, including the option to implement none at all 🌸
5.2.3.1. The cs-correlation Attribute 💖
In order to support the correlation mechanisms, we define a new media-level SDP attribute called cs-correlation. There MUST be at most one cs-correlation attribute per media description.
This cs-correlation attribute MAY contain zero or more subfields -- callerid, uuie, dtmf, or external -- to specify additional information required by the Caller ID, User-User Information Element, DTMF, or external correlation mechanisms, respectively. The list of correlation mechanisms may be extended by other specifications; see Section 5.2.3.6 for more details.
The following sections give more detailed info about these subfields 🧚
The values callerid, uuie, dtmf, and external refer to the correlation mechanisms defined in Sections 5.2.3.2, 5.2.3.3, 5.2.3.4, and 5.2.3.5, respectively. The formal Augmented Backus-Naur Format (ABNF) syntax of the cs-correlation attribute is presented in Section 5.7.
5.2.3.2. Caller ID Correlation Mechanism 📞
The Caller ID correlation mechanism is an exchange of the Calling Party Number as an international E.164 number in SDP, followed by the Calling Party Number Information Element showing up in the call setup signaling of the circuit-switched connection. If both pieces match, the circuit-switched bearer is correlated to the session described in SDP.
An example of an international E.164 number in the cs-correlation attribute looks like this:
a=cs-correlation:callerid:+441134960123The presence of the callerid subfield means the endpoint supports using the Calling Party Number to correlate a PSTN call with the session being negotiated. The callerid subfield MAY be accompanied by the international E.164 number of the party inserting the parameter.
Heads up, bestie: there are NO guarantees this correlation mechanism works or is even available, due to a number of problems 😬
- The endpoint might not know its own E.164 number, in which case it can't fill in the SDP appropriately 🤷
- The Calling Party Number Information Element in the circuit-switched signaling might not be available, e.g., due to policy restrictions of the network operator or caller restriction due to privacy 🔒
- The Calling Party Number Information Element might be available, but the digit representation of the E.164 number could differ from the one expressed in the SDP, due to, e.g., a missing country code. To mitigate this, implementations should consider only some of the rightmost digits of the E.164 number for correlation. For example,
+44-113-496-0123and0113-496-0123could be considered the same number. This is also how some cellular phones behave: they correlate the incoming calling party with a number stored in the phone book, so they can show the caller's name 📱 Please refer to ITU-T E.164 recommendation [ITU.E164.2010] for consideration of the relevant number of digits to consider.
5.2.3.3. User-User Information Element Correlation Mechanism 🦋
A second correlation mechanism is based on including in SDP a string that represents the User-User Information Element that's part of the call setup signaling of the circuit-switched bearer. The User-User Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and 3GPP TS 24.008 [TS.24.008], among others. The User-User Information Element has a maximum size of 35 or 131 octets, depending on the actual message of the PSTN protocol where it's included and the network settings.
The mechanism works like this. An endpoint creates a User-User Information Element, according to the requirements of the call setup signaling protocol. The same value is included in the SDP offer or SDP answer, in the uuie subfield of the cs-correlation attribute. When the SDP offer/answer exchange is complete, each endpoint has become aware of the value that will be used in the User-User Information Element of the call setup message of the PSTN protocol. The endpoint that initiates the call setup attempt includes this value in the User-User Information Element. The recipient of the call setup attempt can extract the User-User Information Element and correlate it with the value previously received in the SDP. If both values match, then the call setup attempt corresponds to the one indicated in the SDP 🔍
According to ITU-T Q.931 [ITU.Q931.1998], the User-User Information Element (UUIE) identifier is composed of a first octet identifying this as a User-User Information Element, a second octet containing the length of the user-user contents, a third octet containing a Protocol Discriminator, and a value of up to 32 or 128 octets (depending on network settings) containing the actual User Information (see Figure 4-36 in [ITU.Q931.1998]). The first two octets of the UUIE MUST NOT be used for correlation; only the octets carrying the Protocol Discriminator and the User Information value are input to the creation of the value of the uuie subfield in the cs-correlation attribute. Therefore, the value of the uuie subfield in the cs-correlation attribute MUST start with the Protocol Discriminator octet, followed by the User Information octets. The value of the Protocol Discriminator octet is not specified in this document; it is expected that organizations using this technology will allocate a suitable value for the Protocol Discriminator 🧩
Once the binary value of the uuie subfield in the cs-correlation attribute is created, it MUST be base 16 (also known as "hex") encoded before it is inserted in SDP. Please refer to RFC 4648 [RFC4648] for a detailed description of base 16 encoding. The resulting encoded value needs to have an even number of hexadecimal digits and MUST be considered invalid if it has an odd number 🔢
Note: The encoding of theuuiesubfield of thecs-correlationattribute is largely inspired by the encoding of the same value in the User-to-User header field in SIP, according to "A Mechanism for Transporting User to User Call Control Information in SIP" [SIP-UUI].
As an example, an endpoint willing to send a UUIE containing a Protocol Discriminator with the hexadecimal value of %x56 and a hexadecimal User Information value of %xA390F3D2B7310023 would include an a=cs-correlation attribute line as follows:
a=cs-correlation:uuie:56A390F3D2B7310023Note that the value of the User-User Information Element is considered an opaque string and is only used for correlation purposes 🤐 Typically, call signaling protocols impose requirements on the creation of a User-User Information Element for end-user protocol exchange. The details regarding the generation of the User-User Information Element are outside the scope of this specification.
Please note that there are no guarantees this correlation mechanism works. On one side, policy restrictions might not make the User-User information available end to end in the PSTN. On the other hand, the generation of the User-User Information Element is controlled by the PSTN circuit-switched call protocol, which might not offer enough freedom to generate different values from one endpoint to another or from one call to another in the same endpoint. This might result in the same value of the User-User Information Element for all calls 🥲
5.2.3.4. DTMF Correlation Mechanism ✨
okay so this is the third way to match the circuit-switched bearer up with the session described in SDP 💅 It's based on agreeing on a sequence of digits during the SDP offer/answer exchange, then sending those digits as DTMF tones (ITU-T Recommendation Q.23 [ITU.Q23.1988]) over the circuit-switched bearer once it's set up. If the digit sequence received through the bearer matches the string negotiated in the SDP, the bearer gets correlated with the session described in the SDP. It's giving voice conference PIN vibes, the thing where you punch in a code with your keypad to get into the call 🎀
The way it works is kind of iconic 🦋 An endpoint picks a DTMF digit sequence. That same sequence goes into the SDP offer or SDP answer, inside a "dtmf" subfield of the "cs-correlation" attribute. Once the SDP offer/answer exchange wraps up, both endpoints know exactly which DTMF sequence is about to get sent right after the circuit-switched bearer is set up. The endpoint that starts the call setup attempt sends the DTMF digits using the procedures defined for whatever circuit-switched bearer technology is being used. The recipient (the passive side of the bearer setup) collects the digits and compares them to the value it got earlier in the SDP. If they match, then yep, that call setup attempt is the one the SDP was talking about 🥰
Note: Implementations are advised to select a number of DTMF digits that provide enough assurance that the call is related but do not prolong the bearer setup time unnecessarily. A number of 5 to 10 digits is a good compromise.
Here's a quick example. An endpoint that wants to send the DTMF tone sequence "14D*3" would add an "a=cs-correlation" attribute line like this:
a=cs-correlation:dtmf:14D*3Now, if the endpoints agree to use the DTMF digit correlation mechanism but the passive side either gets no DTMF digits after the circuit-switched bearer is set up successfully, or gets digits that don't match the "dtmf" attribute value (including getting way too many digits), the passive side SHOULD consider that this DTMF mechanism has failed to correlate the incoming call 💀 bestie that's a no from the DTMF crew.
5.2.3.5. External Correlation Mechanism 🌸
the fourth correlation mechanism leans on external means to correlate the incoming call with the session. Endpoints get to pick which correlation mechanisms they support, so sometimes no other common mechanism gets found, or the one they picked just doesn't work because the PSTN network doesn't support the feature it needs. In those cases, a human user can decide to accept or reject the incoming call, which kind of "correlates" the call with the session 🙈 Not every endpoint is run by a human, though, and there may be no other external means for the endpoint to do the correlation. So we're explicitly defining support for this external mechanism. ✨
If endpoints want to use this external correlation mechanism, they use the "external" subfield in the "cs-correlation" attribute. Unlike the other three correlation mechanisms, the "external" subfield does NOT take a value (it's giving no value, just vibes 🫶). Here's an example of what the attribute line looks like:
a=cs-correlation:externalEndpoints that only want to use the three explicit correlation mechanisms defined in this document ("callerid", "uuie", and/or "dtmf") would leave the "external" mechanism out of the offer/answer exchange.
The external mechanism usually depends on the human user deciding whether or not the call is related to the ongoing session. Once the user accepts the call, that bearer is considered related to the session. There's a small chance that the user gets another circuit-switched call at the same time that has nothing to do with the ongoing session. The user can reject that call if they're able to tell (for example, from the calling line identification) that it isn't related, and then keep waiting for another call attempt. If the user accepts an incoming circuit-switched call but it turns out to be unrelated to the session, the endpoints have to rely on the human user to handle it (usually the user just hangs up 📞).
5.2.3.6. Extensions to Correlation Mechanisms 🦋
new values for the "cs-correlation" attribute are allowed to be specified later. The registration policy for new values is "Specification Required"; see Section 8. Any such specification MUST include a description of how the SDP offer/answer mechanism is used to negotiate the use of the new values, and it has to take into account how endpoints figure out which side will become active or passive (see Section 5.3 for more details). Main character energy for the new values, honestly 👑
If, during the offer/answer negotiation, either endpoint runs into an unknown value in the "cs-correlation" attribute, it MUST consider that mechanism as unsupported and MUST NOT include that value in subsequent offer/answer negotiation. Not it, not that value, moving on 💅
5.3. Negotiating the Correlation Mechanisms 🍓
the four correlation mechanisms above (based on Called Party Number, User-User Information Element, DTMF digit sending, and external) are non-exclusive, which means they can be used independently of each other 🌈 But before anyone can fill in the "cs-correlation" attribute, the endpoints need to agree on which endpoint will become the active party, meaning the one that sets up the circuit-switched bearer.
5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup 🧚
so the endpoints don't both try to start a connection at the exact same time (chaos, no thank you 😭), the direction the circuit-switched bearer gets set up in MUST be negotiated during the offer/answer exchange.
The framework in RFC 4145 [RFC4145] lets the endpoints agree on which endpoint acts as the active endpoint when a TCP connection is being initiated. RFC 4145 [RFC4145] was originally designed for TCP connections, but it can be pretty easily extrapolated to connection establishment for circuit-switched bearers. This specification uses the concepts from RFC 4145 [RFC4145] to agree on the direction of establishing a circuit-switched bearer ✨
RFC 4145 [RFC4145] defines two new attributes in SDP: "setup" and "connection". The "setup" attribute says which endpoint should start the PSTN circuit-switched bearer's connection establishment. Four values are defined in Section 4 of RFC 4145 [RFC4145]: "active", "passive", "actpass", and "holdconn". For the full scoop on this attribute, check Section 4 of RFC 4145 [RFC4145].
The "connection" attribute says whether a new connection is needed or an existing one gets reused. It can take the values "new" or "existing". For a detailed breakdown, see Section 5 of RFC 4145 [RFC4145] 🫶
Implementations that are compliant with this specification MUST support the "setup" and "connection" attributes specified in RFC 4145 [RFC4145], but applied to circuit-switched bearers in the PSTN. No skipping, bestie 💖
We define the active party as the one that initiates the circuit-switched bearer after the offer/answer exchange. The passive party is the one receiving the circuit-switched bearer. Either party can say it wants to be the active or passive party during the offer/answer exchange, using the procedures described in Section 5.6 🌸
5.3.2. Populating the "cs-correlation" Attribute 💜
by defining values for the subfields in the "cs-correlation" attribute, the endpoint is basically saying "I'm down to be the active party, and I can use these values in the Calling Party Number, in the User-User Information Element, or as DTMF tones during the circuit-switched bearer setup" 💅
So here's how the rules go:
- An endpoint that can only become the active party in the circuit-switched bearer setup MUST include all correlation mechanisms it supports in the "cs-correlation" attribute and MUST also specify values for the "callerid", "uuie", and "dtmf" subfields. Notice that the "external" subfield does not accept a value.
- An endpoint that can only become the passive party in the circuit-switched bearer setup MUST include all correlation mechanisms it supports in the "cs-correlation" attribute but MUST NOT specify values for the subfields.
- An endpoint that is willing to become either the active or passive party (by including the
a=setup:actpassattribute in the offer) MUST include all correlation mechanisms it supports in the "cs-correlation" attribute and MUST also specify values for the "callerid", "uuie", and "dtmf" subfields. Notice that the "external" subfield does not accept a value.
5.3.3. Considerations for Correlations 🔥
passive endpoints should expect an incoming circuit-switched (CS) call to set up the audio bearer. Passive endpoints MAY suppress the incoming CS alert during certain time periods. Extra restrictions can be applied too, like the passive endpoint not alerting incoming calls from the number that got observed during the offer/answer negotiation 👀
Sometimes an endpoint isn't willing to include one or more correlation mechanisms in the "a=cs-correlation" attribute line, even if it supports them. For example, some mechanisms can be left out if the endpoint is sure the PSTN network doesn't support carrying the correlation identifier. Also, the DTMF-based mechanism needs the call to be accepted before DTMF tones can be sent, so some endpoints may have a policy against it because of costs tied to received calls, which makes the DTMF mechanism unusable for them 💸
Note that it cannot be guaranteed that the correlation mechanisms relying on caller identification, User-User Information Element, and DTMF sending will succeed even if the usage of those was agreed beforehand. This is due to the fact that correlation mechanisms require support from the circuit-switched bearer technology used.
So, even a single positive indication from any of these mechanisms SHOULD be interpreted by the passive endpoint as the circuit-switched bearer establishment being related to the ongoing session, even if the other correlation mechanisms fail 🎉
If, after successfully negotiating any of the "callerid", "uuie", or "dtmf" correlation mechanisms in the SDP offer/answer exchange, an endpoint gets an incoming circuit-switched bearer establishment with no correlation information present, the endpoint first checks whether the offer/answer exchange also successfully negotiated the "external" correlation mechanism. If it did, the endpoint should let the decision be made by external means, typically the human user. If the "external" correlation mechanism was NOT successfully negotiated, the endpoint should treat the call as unrelated to the ongoing session in the IP domain 🥺
5.4. Considerations for Usage of Existing SDP 🌷
5.4.1. Originator of the Session ✨
okay so SDP [RFC4566] has this origin line, the o= line, and it looks like this:
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>the two fields we care about are <nettype> and <addrtype>. they tell you what kind of network and what kind of address you're dealing with 🌐. usually this is the IP address of whoever started the session, and yes, even if the audio or video is going over a circuit-switched bearer, the originator is still sending its SDP over an IP bearer 💻. so the <nettype> and <addrtype> fields in the o= line should be filled in with the IP address of the signaling source. no PSTN in the origin line, bestie 💅
5.4.2. Contact Information 📞
SDP [RFC4566] has a p= line, and it's allowed to carry the phone number of whoever's in charge of the conference. the thing is, it's not built for telling the media where to go 🙃. so we picked the c= line to hold the PSTN-specific connection addresses instead. the p= line is giving contact info, the c= line is giving the actual address, and we keep them separate 🎀
5.5. Considerations for Usage of Third Party Call Control (3PCC) 📲
"Best Current Practices for Third Party Call Control (3PCC) in the Session Initiation Protocol (SIP)" [RFC3725] walks through a bunch of flows that can show up in third party call control scenarios, and it recommends some flows for specific situations 🧠.
one of the assumptions in [RFC3725] is that an SDP offer might have a "black hole" connection address 🕳️. that's an address where anything you send just never leaves the host that sent it. for IPv4, the "black hole" connection address is 0.0.0.0 or a domain name inside the .invalid DNS top level domain.
when you're using an E.164 address scheme with third party call control, and the User Agent needs to say "I don't know my phone number," it MUST put a - in the <addrtype> of the SDP c= line 🙈.
Note: This may result in the recipient of the initial offer rejecting such offer if the recipient of the offer was not aware of its own E.164 number. Consequently, it will not be possible to establish a circuit-switched bearer, since neither party is aware of its E.164 number.
5.6. Offer/Answer Mode Extensions 🦋
in this section we add extensions to the offer/answer model from "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264], so PSTN addresses can be used with the offer/answer model 💜.
5.6.1. Generating the Initial Offer 🌸
the offerer wants a PSTN audio or video stream, so it MUST fill in the c= and m= lines like this 👑.
the endpoint MUST set the <nettype> in the c= line to PSTN and the <addrtype> to E164. it SHOULD also put its own international E.164 number in the <connection-address> field, with a leading + ✨. if the endpoint doesn't know its own E.164 number, it MUST set the <connection-address> to - 🫶.
in the m= line, the endpoint MUST set the <media> subfield to audio or video, depending on what kind of media it's sending, and the <proto> subfield to PSTN 🎧. the <port> subfield SHOULD be set to 9, which is the discard port 🗑️. and the values audio or video in the <media> subfield MUST NOT be set by the endpoint unless it knows those bearer types are actually available on the circuit-switched network 🚫.
the <fmt> subfield carries the payload type numbers the endpoint wants to use. these numbers point at the codecs the endpoint wants on the PSTN media stream. so if the endpoint wants the GSM codec, it adds payload type number 3 to the list 🎶. the list of payload types MUST only contain codecs the endpoint can actually use on the PSTN bearer 💯. if the endpoint isn't aware of which codecs are available for the circuit-switched media streams, it MUST include a dash (-) in the <fmt> subfield 🤷♀️.
the mapping table for static payload type numbers is first specified in [RFC3551] and is kept up to date by IANA 📚. for dynamic payload types, the endpoint MUST define the set of valid encoding names and related parameters using the a=rtpmap attribute line. check out Section 6 of RFC 4566 [RFC4566] for the details 🔍.
when the offerer generates the offer, it MUST include an a=cs-correlation attribute line in the SDP offer 💖. it MUST NOT include more than one cs-correlation attribute per media description 🙅♀️. the a=cs-correlation line SHOULD list every correlation mechanism the offerer supports, written as subfields 🌈. see Section 5.3.3 for more on how to use the correlation mechanisms 🧚.
the current subfields are callerid, uuie, dtmf, and external. they map to the correlation mechanisms in Sections 5.2.3.2, 5.2.3.3, 5.2.3.4, and 5.2.3.5, in that order 📋.
if the offerer supports any of the correlation mechanisms in this memo and is willing to be the active party, it MUST add the callerid, uuie, dtmf, and/or external subfields, and it MUST give them values like this:
- the international E.164 number goes in the
calleridsubfield. - the contents of the User-User Information Element go in the
uuiesubfield. - the DTMF tone string goes in the
dtmfsubfield. - the endpoint MUST NOT specify any value for the
externalsubfield 🙅♀️.
if the offerer can only be the passive party in the circuit-switched bearer setup, it MUST add at least one of the possible correlation mechanisms, but MUST NOT specify values for those subfields 🧸.
for example, say the offerer is cool with using the User-User Information Element and DTMF digit-sending, but can only be the passive party, and it can also let the human user decide whether correlation happens. then it includes these lines in the SDP:
a=cs-correlation:uuie dtmf external
a=setup:passivenow if the offerer is down to use the User-User Information Element and DTMF correlation, can be either the active or passive side, and can also let the human decide about correlation, it includes these lines instead:
a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3 external
a=setup:actpassthe setup attribute gets negotiated the way Section 4.1 of RFC 4145 [RFC4145] says 🤝.
the offerer tells everyone which role or roles it's willing to play, and then the answerer, taking that willingness into account, picks which roles both endpoints will actually play during the circuit-switched bearer setup 🎭.
an "active" endpoint is one that will set up the circuit-switched bearer. a "passive" endpoint is one that will receive it 📡.
if an offerer doesn't know its international E.164 number, it MUST set the setup attribute to active 📞. if it does know its number, it SHOULD set the value to either actpass or passive 💅.
also, holdconn is a valid value for the setup attribute. it means the connection shouldn't be established for now 😴.
the offerer uses the connection attribute to decide whether a brand new circuit-switched bearer should be set up 🪄. for the initial offer, the offerer MUST use the value new 🫶.
5.6.2. Generating the Answer ✨
Okay so if the offer had a circuit-switched audio or video stream in it, the answerer first has to figure out whether it can even accept and use those streams on the circuit-switched network 📞. If the answerer doesn't support circuit-switched media, or just isn't willing to use it for the session, it MUST build an answer where the port number for that media stream is set to zero, following Section 6 of [RFC3264] 🙅♀️. And if the answerer is willing to use circuit-switched media, it MUST ignore the port number it received (unless that port number is set to zero, which is a whole different vibe 💀).
If the offer had "-" as the payload type number, that means the offerer isn't willing or able to define any specific payload type 🙈. This mostly happens when the endpoint doesn't know about the codecs that'll end up on the circuit-switched bearer, or doesn't want to define them. The circuit-switched signaling protocols have their own way of negotiating or indicating codecs, so an answerer SHOULD accept those offers and SHOULD set the payload type to "-" in the answer 💖.
If the answerer really wants to pick a codec for the circuit-switched media, it MAY set the respective payload numbers in the <fmt> subfield in the answer. Honestly though, this is NOT RECOMMENDED 🙃.
When the offer comes in, the answerer MUST work out whether it becomes the active or the passive party 🎭.
If the SDP in the offer says the offerer can only be the active party, the answerer needs to check whether it can be the passive one. If it can't, for example because it doesn't know its international E.164 number, the answerer MUST reject the circuit-switched media by setting the port number to zero in the answer 😭. If it does know its international E.164 number, it MUST include the "setup" attribute in the answer with the value "passive" or "holdconn". It MUST also put its E.164 number in the c= line 📱.
If the SDP in the offer says the offerer can only be the passive party, the answerer MUST verify that the offerer's E.164 number is in the c= line of the offer. If it is, the answerer MUST include the "setup" attribute in the answer and set it to "active" or "holdconn". If it isn't, the recipient of the offer isn't willing to set up a connection to that E.164 number, whether because of a priori knowledge of cost or other reasons. So call establishment isn't possible, and the answerer MUST reject the circuit-switched media by setting the port number to zero in the answer 🚫.
If the SDP in the offer says the offerer can be either the active or the passive party, the answerer picks its role. If the offer includes an international E.164 number in the c= line, the answerer SHOULD become the active party. If the answerer doesn't become the active party and does know its E.164 number, it MUST become the passive party. If the answerer becomes neither the active nor the passive party, it MUST reject the circuit-switched media by setting the port number to zero in the answer 🪄.
For each media description where the offer includes a "cs-correlation" attribute, the answerer MUST select from the offer those correlation mechanisms it supports, and include them in the answer as one a=cs-correlation attribute line containing only the mechanisms it is willing to use 🧩. The answerer MUST only add one "cs-correlation" attribute in those media descriptions where the offer also included one. The answerer MUST NOT add any mechanisms that weren't in the offer. If the offer has more than one "cs-correlation" attribute per media description, the answerer MUST discard all but the first for that media description. Also, the answerer MUST discard all unknown "cs-correlation" attribute values 🗑️.
If the answerer becomes the active party, it MUST add a value to any of the possible subfields 💅.
If the answerer becomes the passive party, it MUST NOT add any values to the subfields in the "cs-correlation" attribute 🤫.
After generating and sending the answer, if the answerer became the active party, it:
- MUST extract the E.164 number from the
c=line of the offer and MUST establish a circuit-switched bearer to that address. - if the SDP answer contained a value for the
"callerid"subfield, MUST set the Calling Party Number Information Element to that number. - if the SDP answer contained a value for the
"uuie"subfield, MUST send the User-User Information Element according to the rules for the circuit-switched technology in use, with the value set to what was received in the SDP offer. - if the SDP answer contained a value for the
"dtmf"subfield, MUST send those DTMF digits according to the circuit-switched technology in use.
If, on the other hand, the answerer became the passive party, it:
- MUST be prepared to receive a circuit-switched bearer.
- if the offer contained a value for the
"callerid"subfield, MUST compare that value to the Calling Party Number Information Element of the circuit-switched bearer. If the received Calling Party Number Information Element matches the"callerid"value, the call SHOULD be treated as correlated to the ongoing session 🔍. - if the offer contained a value for the
"dtmf"subfield, MUST be prepared to receive and collect DTMF digits once the circuit-switched bearer is set up. The answerer MUST compare the received DTMF digits to the value of the"dtmf"subfield. If they match, the call SHOULD be treated as correlated to the ongoing session 🎹. - if the offer contained a value for the
"uuie"subfield, MUST be prepared to receive a User-User Information Element once the circuit-switched bearer is set up. The answerer MUST compare the received UUIE to the value of the"uuie"subfield. If they match, the call SHOULD be treated as correlated to the ongoing session 🫶. - if the offer contained an
"external"subfield, MUST be prepared to receive a circuit-switched call and use the external means (typically, the human user) for accepting or rejecting the call 🧑🤝🧑.
If the answerer becomes the active party, generates an SDP answer, and then finds out that the circuit-switched call cannot be established, the answerer MUST create a new SDP offer where the circuit-switched stream is removed from the session (by setting the corresponding port in the m= line to zero), and send it to its counterpart 🔄. This keeps both parties (and any potential intermediaries) synchronized on the state of the session 🌸.
5.6.3. Offerer Processing the Answer 🎀
When the answer comes back, if the SDP doesn't contain an a=cs-correlation attribute line, the offerer should take that as a sign that the other party doesn't support, or isn't willing to use, the procedures in this document for this session. The offerer MUST then revert to normal processing of SDP 🌈.
When receiving the answer, the offerer MUST first determine whether it becomes the active or passive party, as described in Section 5.3.1 🧭.
If the offerer becomes the active party, it:
- MUST extract the E.164 number from the
c=line and MUST establish a circuit-switched bearer to that address. - if the SDP answer contained a value for the
"uuie"subfield, MUST send the User-User Information Element according to the rules for the circuit-switched technology in use, with the value set to what was received in the SDP answer. - if the SDP answer contained a value for the
"dtmf"subfield, MUST send those DTMF digits according to the circuit-switched technology in use.
If the offerer becomes the passive party:
- It MUST be prepared to receive a circuit-switched bearer.
- Heads up, this one's important 🚨: if delivery of the answer is delayed for some reason, the circuit-switched call attempt may arrive at the offerer before the answer has been processed. Since the correlation mechanisms are negotiated as part of the offer/answer exchange, the answerer can't know whether or not the incoming call attempt is correlated with the session being negotiated. So the offerer SHOULD answer the circuit-switched call attempt only after it has received and processed the answer.
- If the answer contained a value for the
"dtmf"subfield, the offerer MUST be prepared to receive and collect DTMF digits once the circuit-switched bearer is set up. The offerer SHOULD compare the received DTMF digits to the value of the"dtmf"subfield. If they match, the call SHOULD be treated as correlated to the ongoing session. - If the answer contained a value for the
"uuie"subfield, the offerer MUST be prepared to receive a User-User Information Element once the circuit-switched bearer is set up. The offerer SHOULD compare the received UUIE to the value of the"uuie"subfield. If they match, the call SHOULD be treated as correlated to the ongoing session. - If the answer contained an
"external"subfield, the offerer MUST be prepared to receive a circuit-switched call and use the external means (typically, the human user) for accepting or rejecting the call.
Per "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264], the offerer needs to be ready to receive media as soon as the offer has been sent 📨. It may happen that the answerer, if it became the active party, starts a circuit-switched bearer setup that arrives at the offerer before the answer does. But the offerer needs to receive the answer and look at the correlation mechanisms so it can correlate the circuit-switched call to the session properly 🧩. So if the offerer gets an incoming circuit-switched call, it MUST NOT accept the call before the answer has been received 🛑. If no answer shows up within an implementation-specific time, the offerer MUST either modify the session according to [RFC3264] or terminate it according to the session signaling procedures in question (for terminating a SIP session, see Section 15 of [RFC3261]) 💜.
5.6.4. Modifying the Session 🦋
Okay so, if one of the parties wants to change the session later on, like adding a new media stream or tweaking properties on a stream that's already there, they can do it using the mechanisms in "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264]. Easy peasy 🎀
If there's already a circuit-switched bearer between the endpoints and the offerer wants to reuse it, the offerer MUST set the value of the "connection" attribute to "existing". Reusing what's already there is so efficient, bestie 🧚
If either party removes the circuit-switched media from the session (by setting the port number to zero), it MUST terminate the circuit-switched bearer using whatever mechanism is appropriate for the technology in question. No loose ends allowed 💅
If either party wants to drop and reestablish an existing call, that party MUST first remove the circuit-switched media from the session by setting the port number to zero. Then it uses another offer/answer exchange where it MUST set the "connection" attribute to "new". If the media types are different (for example, a different codec will be used for the circuit-switched bearer), the media descriptions for terminating the existing bearer and the new bearer can be in the same offer. Two-in-one offer, we love a multitasker 🌸
If either party would like to remove existing RTP-based media from the session and replace it with a circuit-switched bearer, it would create a new offer to add the circuit-switched media as described in Section 5.6.1 above. It replaces the RTP-based media description with the circuit-switched media description, as specified in RFC 3264 [RFC3264]. Main character glow-up 👑
Once the offer/answer exchange is done but the circuit-switched bearer is not established yet, there may be a stretch of time when no media is available. Also, it may happen that correlating the circuit-switched call fails for reasons discussed in Section 5.3.3. In that case, even if the offer/answer exchange was successful, endpoints are not able to receive or send media. It's up to the implementation to decide the behavior here. If nothing else is done, the user most likely hangs up after a while if there's no other media in the session. 😭 Note that this may also happen when switching from one RTP media to another RTP media (for example, when a firewall blocks the new media stream).
If either party would like to remove existing circuit-switched media from the session and replace it with RTP-based media, it would modify the media description as per the procedures defined in RFC 3264 [RFC3264]. The endpoint MUST then terminate the circuit-switched bearer using whatever mechanism is appropriate for the technology in question. Clean swap, no drama 🫶
5.7. Formal Syntax 🌈
Okay, here's the formal Augmented Backus-Naur Form (ABNF) [RFC5234] syntax that supports the extensions in this specification. It's built on top of the SDP [RFC4566] and tel URI [RFC3966] grammars. Implementations that are compliant with this specification MUST be compliant with this syntax. Non-negotiable, bestie 🔥
Figure 2 shows the formal syntax of the extensions defined in this memo.
; extension to the connection field originally specified
; in RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
; CRLF defined in RFC 5234
;nettype and addrtype are defined in RFC 4566
connection-address =/ global-number-digits / "-"
; global-number-digits specified in RFC 3966
;subrules for correlation attribute
attribute =/ cs-correlation-attr
; attribute defined in RFC 4566
cs-correlation-attr = "cs-correlation:" corr-mechanisms
corr-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech /
dtmf-mech / external-mech /
ext-mech
caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = "+" 1*15DIGIT
; DIGIT defined in RFC 5234
uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*65(HEXDIG HEXDIG)
;This represents up to 130 HEXDIG
; (65 octets)
;HEXDIG defined in RFC 5234
;HEXDIG defined as 0-9, A-F
dtmf-mech = "dtmf" [":" dtmf-value]
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
;0-9, A-D, '#' and '*'
external-mech = "external"
ext-mech = ext-mech-name [":" ext-mech-value]
ext-mech-name = token
ext-mech-value = token
; token is specified in RFC 4566
Figure 2: Syntax of the SDP Extensions6. Examples ✨
Heads up, bestie: in the examples below, if an SDP line is too long to fit on one line, a breaking character "" shows that it continues on the next line. That character is only there so it displays nicely. "Implementations MUST write a single line without breaks." So when you actually write it, keep it all on one line 🙈
6.1. Single PSTN Audio Stream 🍓
Endpoint A Endpoint B
| |
| (1) SDP offer (PSTN audio) |
|--------------------------------->|
| |
| (2) SDP answer (PSTN audio) |
|<---------------------------------|
| |
| PSTN call setup |
|<---------------------------------|
| |
|<==== media over PSTN bearer ====>|
| |
Figure 3: Basic FlowFigure 3 is a basic example of a single audio media stream over a circuit-switched bearer. Endpoint A generates an SDP offer, which is shown in Figure 4. The offer describes a PSTN circuit-switched bearer in the "m=" and "c=" lines, and it also indicates its international E.164 number format. Endpoint A also says it can initiate the circuit-switched bearer or be the recipient of it, in the "a=setup" attribute line. The SDP offer also includes correlation identifiers that this endpoint will insert in the Calling Party Number and/or User-User Information Element of the PSTN call setup, if it eventually initiates the PSTN call. Endpoint A also includes "external" as one correlation mechanism, which means it can use the human user to do correlation in case other mechanisms fail. Human backup plan, iconic 💜
v=0
o=alice 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +441134960123
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+441134960123 \
uuie:56A390F3D2B7310023 external
Figure 4: SDP Offer (1)Endpoint B generates an SDP answer (Figure 5), describing a PSTN audio media on port 9 without information on the media subtype on the "m=" line. The "c=" line contains B's international E.164 number. In the "a=setup" line, Endpoint B indicates that it is willing to become the active endpoint when establishing the PSTN call. It also includes the "a=cs-correlation" attribute line, which contains the values it's going to include in the Calling Party Number and User-User Information Element of the PSTN call establishment. Endpoint B is also able to do correlation by external means, in case other correlation mechanisms fail. Both sides came to slay ✨
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +441134960124
a=setup:active
a=connection:new
a=cs-correlation:callerid:+441134960124 \
uuie:74B9027A869D7966A2 external
Figure 5: SDP Answer with Circuit-Switched MediaWhen Endpoint A receives the answer, it sees that B is willing to become the active endpoint when setting up the PSTN call. Endpoint A temporarily stores B's E.164 number and the User-User IE value of the "cs-correlation" attribute, then waits for a circuit-switched bearer establishment. Waiting game, but make it cute 🦋
Endpoint B initiates a circuit-switched bearer using whatever circuit-switched technology is available to it. The Called Party Number is set to A's number, and the Calling Party Number is set to B's own number. Endpoint B also sets the User-User Information Element value to the one contained in the SDP answer. 📞
When Endpoint A receives the circuit-switched bearer establishment, it examines the UUIE and the Calling Party Number. By comparing those with the values received during the offer/answer exchange, it determines that the call is related to the SDP session. Match made in heaven 💖
It may also be that neither the UUIE nor the Calling Party Number is received by the called party, or that the format of the Calling Party Number is changed by the PSTN. Implementations may still accept such call establishment attempts as being related to the session that was established in the IP network. Since it can't be guaranteed that the values used for correlation always pass through the network intact, they should be treated as additional hints that the circuit-switched bearer is actually related to the session. Hints, not receipts, so keep that in mind 🌸
6.2. Advanced SDP Example: Circuit-Switched Audio and Video Streams 🎬
Okay so this one is the big boss example, and it's giving full group-chat drama. Endpoint A and Endpoint B are about to negotiate audio AND video over circuit-switched bearers 😭🫶
Endpoint A Endpoint B
| |
| (1) SDP offer (PSTN audio and video) |
|------------------------------------------->|
| |
| (2) SDP answer (PSTN audio) |
|<-------------------------------------------|
| |
| PSTN call setup |
|<-------------------------------------------|
| |
|<======== media over PSTN bearer ==========>|
| |
Figure 6: Circuit-Switched Audio and Video StreamsFigure 6 shows how it looks when you negotiate audio and video media streams over circuit-switched bearers 📞✨
v=0
o=alice 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
a=setup:actpass
a=connection:new
c=PSTN E164 +441134960123
m=audio 9 PSTN -
a=cs-correlation:dtmf:1234536
m=video 9 PSTN 34
a=rtpmap:34 H263/90000
a=cs-correlation:callerid:+441134960123
Figure 7: SDP Offer with Circuit-Switched Audio and Video (1)Now here's the tea 🍵 When Endpoint B gets the offer from Figure 7, it rejects the video stream because the device doesn't support video yet 💀 but it accepts the circuit-switched audio stream 🎧 Endpoint A said it can be either the active or the passive party, so Endpoint B gets to pick which role it wants. Since the offer had Endpoint A's international E.164 number, Endpoint B decides it'll be the active party and set up the circuit-switched bearer itself 📲 It also adds a brand new value to the "dtmf" subfield of the "cs-correlation" attribute, which it's going to send as DTMF tones once the bearer setup is complete 🎹✨ The answer looks like this in Figure 8 👇
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
a=setup:active
a=connection:new
c=PSTN E164 +441134960124
m=audio 9 PSTN -
a=cs-correlation:dtmf:654321
m=video 0 PSTN 34
a=cs-correlation:callerid:+441134960124
Figure 8: SDP Answer with Circuit-Switched Audio and Video (2)7. Security Considerations 🔐
Okay bestie, security is serious business so let's be real 💅
This document is an extension to RFC 4566 [RFC4566] and RFC 3264 [RFC3264]. So the security considerations of those documents apply too, no skipping them 🙏
This memo gives us mechanisms to agree on a correlation identifier (or identifiers) that help figure out whether an incoming circuit-switched bearer is related to an ongoing session in the IP domain 🦋 Now the scary part 😱 If an attacker copies the correlation identifier and sets up a call within the time window when the receiving endpoint is expecting one, the attacker might be able to hijack the circuit-switched bearer 💀 These kinds of attacks aren't specific to the mechanisms in this memo, though. Caller ID spoofing is a well-known attack in the PSTN, so it's not new 🙄 Users should be just as careful about revealing sensitive info as they would be on any other phone call 📞 Also, mechanisms that might be used in the IP domain to secure the media, like Secure RTP (SRTP) [RFC3711], are not available in the CS domain 🚫 so no SRTP for your circuit-switched calls, sorry not sorry 😭
For setting up a circuit-switched bearer, the active endpoint needs to know the passive endpoint's phone number. Phone numbers are sensitive info 🙈 and some people may choose not to reveal them when calling with supplementary services like Calling Line Identification Restriction (CLIR) in GSM 🫣 Implementations should respect the caller's calling line identification preferences if possible, by leaving the phone number out of the SDP "c=" line when the caller has chosen to use CLIR 🤫 If that isn't possible, implementations may show a prompt telling the user their phone number may be sent to the other party 💬
As with IP addresses, if you want to protect an SDP containing phone numbers carried in SIP, implementers are advised to follow the security mechanisms defined in [RFC3261]. Don't skip this one, it's giving important ⚠️
Here's the scariest bit 😨 It's possible an attacker sets up a circuit-switched session where the attacked endpoint ends up dialing a circuit-switched number, maybe even a premium-rate one 💸 To lower the damage from this attack, endpoints MUST authenticate and trust remote endpoints users who try to remain passive in the circuit-switched connection establishment 🛡️ It is RECOMMENDED that endpoints have local policies that block active setup of circuit-switched connections to certain numbers (for example international, premium, and long distance) 🌍 And it is strongly RECOMMENDED that the end user is asked for consent before the endpoint starts a circuit-switched connection 🙋♀️ Consent first, always, periodt 💖
8. IANA Considerations 📋
IANA has registered a bunch of SDP tokens using the following data, so here's the lowdown 🧚
8.1. Registration of the New "cs-correlation" SDP Attribute 🌸
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Attribute name: cs-correlation
Long-form attribute name: PSTN Correlation Identifier
Type of attribute: media level only
Subject to charset: No
Description: This attribute provides the Correlation Identifier
used in PSTN signaling
Appropriate values: see Section 5.2.3.1
Specification: RFC 7195IANA created a subregistry for the "cs-correlation" attribute under the "Session Description Protocol (SDP) Parameters" registry 🗂️ The initial values for that subregistry are shown below, and IANA registered these values accordingly 💅
Value of "cs-correlation" attribute Reference Description
----------------------------------- --------- -------------------
callerid RFC 7195 Caller ID
uuie RFC 7195 User-User
Information Element
dtmf RFC 7195 Dual-Tone
Multi-Frequency
external RFC 7195 ExternalAs per the terminology in [RFC5226], the registration policy for new values of the "cs-correlation" attribute is "Specification Required" 📝✨
8.2. Registration of a New "nettype" Value 🌐
IANA registered a new "nettype" in the "Session Description Protocol (SDP) Parameters" registry [IANA] 🎀 According to RFC 4566 [RFC4566], the registration data looks like this:
Type SDP Name Reference
-------------- ------------------ ---------
nettype PSTN RFC 71958.3. Registration of a New "addrtype" Value 📞
IANA also registered a new "addrtype" in the "Session Description Protocol (SDP) Parameters" registry [IANA] 💖 Again, according to RFC 4566 [RFC4566], here's the registration data:
Type SDP Name Reference
-------------- ------------------ ---------
addrtype E164 RFC 7195Note: This document defines the "E164" addrtype in the context of the "PSTN" nettype only. RFC 3108 [RFC3108] also defines address type "E.164". This definition is distinct from the one defined by this memo and shall not be used with <nettype> "PSTN". Two E.164s, one vibe, don't mix them up 🙅♀️
8.4. Registration of a New "proto" Value 🦋
IANA registered a new "proto" in the "Session Description Protocol (SDP) Parameters" registry [IANA] 🧚♀️ Following RFC 4566 [RFC4566], the registration data is:
Type SDP Name Reference
-------------- ------------------ ---------
proto PSTN RFC 7195The related "fmt" namespace reuses the conventions and payload type number defined for RTP/AVP 🎶 In this document, the RTP audio and video media types, when applied to PSTN circuit-switched bearers, just mean an audio or video codec in its native format sitting directly on top of a single PSTN bearer 🎧📹
Sometimes the endpoint can't figure out the list of available codecs for circuit-switched media streams 🤷♀️ In that case, to stay syntactically compliant with SDP [RFC4566], the endpoint MUST include a single dash ("-") in the <fmt> subfield 🫶
9. Acknowledgments 🫶
The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg, Ingemar Johansson, Christer Holmberg, Alf Heidermark, Tom Taylor, Thomas Belling, Keith Drage, and Andrew Allen for sharing their insight and comments on this document 💜 Literal legends, all of them 👑
10. References 📚
10.1. Normative References
- [ITU.Q931.1998] International Telecommunications Union, "Digital Subscriber Signalling System No. 1 - ISDN User-Network Interface Layer 3 Specification for Basic Call Control", ITU-T Recommendation Q931, May 1998.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
- [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
- [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References ✨
okay bestie, these are the "good to know" sources, the ones the spec points you to for extra context without making them mandatory 📚💅
- [IANA] IANA, "Session Description Protocol (SDP) Parameters Registry",
<http://www.iana.org/assignments/sdp-parameters>. - [ITU.E164.2010] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 2010. 🌍
- [ITU.Q23.1988] International Telecommunications Union, "Technical features of push-button telephone sets", ITU-T Technical Recommendation Q.23, 1988. ☎️
- [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001. 🦋
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞✨
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🎶
- [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 🎥
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔐💜
- [RFC3725] 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. 🧚
- [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. 💬
- [SIP-UUI] Johnston, A. and J. Rafferty, "A Mechanism for Transporting User to User Call Control Information in SIP", Work in Progress, April 2014. 🚧
- [TS.24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.008 3.20.0, December 2005. 📱
Authors' Addresses 🎀
Meet the two people who wrote this whole thing, the real brains behind it 🧠👑
Miguel A. Garcia-Martin
Ericsson
Calle Via de los Poblados 13
Madrid, ES 28033
Spain
EMail: miguel.a.garcia@ericsson.com
Simo Veikkolainen
Nokia
P.O. Box 226
NOKIA GROUP, FI 00045
Finland
Phone: +358 50 486 4463
EMail: simo.veikkolainen@nokia.comThat's the whole spec, bestie! You made it through all 9 parts 🌈💖🫶
📦 where this page comes from
- ietf: rfc7195 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms