RFC 4458
Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
RFC 4458 🎀 Part 1 of 4
Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) 💖
Okay bestie, here's the deets. This one was written by C. Jennings (Cisco Systems), F. Audet (Nortel Networks), and J. Elwell (Siemens plc) in April 2006. It's Informational, so it's sharing info with the Internet community and it doesn't set any official standard 🦋 It also doesn't obsolete or update any other RFC. The title block doesn't list anything it replaces or changes.
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 💅
Copyright Notice 🌸
Copyright (C) The Internet Society (2006).
Abstract 🦋
SIP is super popular for starting connections to stuff like voicemail or interactive voice recognition systems 📞 This spec gives you a convention for building SIP service URIs that ask for a specific service, based on who the call got redirected from. Iconic. 👑
Table of Contents 💜
1. Introduction ....................................................3
2. Mechanism (User Agent Server and Proxy) .........................4
2.1. Target .....................................................4
2.2. Cause ......................................................4
2.3. Retrieving Messages ........................................5
3. Interaction with Request History Information ....................5
4. Limitations of Voicemail URI ....................................6
5. Syntax ..........................................................6
6. Examples ........................................................7
6.1. Proxy Forwards Busy to Voicemail ...........................7
6.2. Endpoint Forwards Busy to Voicemail ........................9
6.3. Endpoint Forwards Busy to TDM via a Gateway ...............11
6.4. Endpoint Forwards Busy to Voicemail with History Info .....13
6.5. Zero Configuration UM System ..............................14
6.6. Call Coverage .............................................15
7. IANA Considerations ............................................15
8. Security Considerations ........................................16
8.1. Integrity Protection of Forwarding in SIP .................16
8.2. Privacy Related Issues on the Second Call Leg .............17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................181. Introduction ✨
Okay so, a bunch of apps like Unified Messaging (UM) systems and Interactive Voice Recognition (IVR) systems grew out of old-school telephony 📼 They store and let you interact with voice, video, faxes, email, and instant messages 💌 People usually reach for SIP to start talking to these apps. When a SIP call gets routed to one of them, the app has to pull a few bits of info out of the session initiation message so it can actually deliver the service you asked for 🧚
This doc uses UM as the main example, but other apps can totally use this mechanism too 💅 UM needs to know which mailbox to use, plus the reason the caller ended up there. Lots of voicemail systems play different greetings depending on whether you were busy or just didn't pick up 🙈 All of that info can ride along in the SIP signaling that the call control sends when it reroutes the call to UM. The problem is there's no convention for how the mailbox and the requested service get written down 😭 Every vendor could make it configurable so any site could make it work, but that's super unrealistic if you want call control, gateway, and unified messaging systems from different vendors to play nice together. So this spec defines a convention for putting the mailbox and service info into the SIP URI, so vendors and operators can build systems that actually interoperate 🫶
Now the TDM stuff. If we didn't have to work with Time Division Multiplexing (TDM)-based voicemail systems, or let TDM systems use VoIP unified messaging systems, this would be a little easier 🍓 The VoIP-to-TDM case goes like this: the SIP system has to tell a Public Switched Telephone Network (PSTN) gateway two things. One is the subscriber's mailbox identifier, which usually looks like a phone number. The other is the address of the voicemail system in the TDM network, which is also a phone number 📞
You might be wondering why the To header can't just say which mailbox to use. Good question, bestie 🧠 The thing is, call control proxies can't modify the To header, and User Agent Clients (UACs) often set it wrong because they don't know about the subscribers in the domain they're trying to call. That's because the call often gets its URI translated multiple times during routing before it ends up as an identifier the UM system actually understands 🌀
2. Mechanism (User Agent Server and Proxy) 🎀
Here's the vibe: the mechanism encodes the info for the desired service right into the SIP Request-URI that gets sent to the UM system 💜 Two chunks of info get packed in. The first is the target mailbox to use. The second is the SIP status code that caused the retargeting, which also tells you what service is wanted. The userinfo and hostport parts of the Request-URI identify the voicemail service. The target mailbox goes in the target parameter, and the reason goes in the cause parameter ✨ For example, say a proxy wants to use Bob's mailbox because his phone was busy. The URI sent to the UM system could look something like this:
sip:voicemail@example.com;target=bob%40example.com;cause=4862.1. Target 🦋
Target is a URI parameter that tells you the address of the retargeting entity. In the UM context, that can be the mailbox number 📬 Like, if you've got a voicemail system on the PSTN, the user portion holds the phone number of the voicemail system, and the target holds the phone number of the subscriber's mailbox 🫶
2.2. Cause 💅
Cause is a URI parameter that tells the User Agent Server (UAS) receiving the message which service it should perform. Here are the values that are defined for this URI parameter 👑
+---------------------------------+-------+
| Redirecting Reason | Value |
+---------------------------------+-------+
| Unknown/Not available | 404 |
| User busy | 486 |
| No reply | 408 |
| Unconditional | 302 |
| Deflection during alerting | 487 |
| Deflection immediate response | 480 |
| Mobile subscriber not reachable | 503 |
+---------------------------------+-------+Mapping to PSTN protocols matters a LOT here 🔥 It matters for gateways that connect the IP network to existing TDM customer equipment, like Private Branch Exchanges (PBXs) and voicemail systems. It also matters for gateways that connect the IP network to the PSTN itself 🌈 Integrated Services Digital Network User Part (ISUP) has signaling encodings for this info that you can treat as roughly equivalent for what we need here. So this spec uses the names of the Redirecting Reason values defined in ITU-T Q.732.2-5 [8]. In this spec those are called "Causes" 🧚 Heads up: the word "Cause" has nothing to do with PSTN "Cause values" (per ITU-T Q.850 [9] and RFC 3398 [5]). Instead, they get mapped to the ITU-T Q.732.2-5 Redirecting Reasons. ISUP interoperates with other PSTN networks, like Q.931 [10] and QSIG [11], using well-known rules, so it makes sense to use the ISUP names as the most appropriate superset 💖
Now the fallback stuff. If there's no appropriate mapping to a cause value defined in this spec in a network, it would be mapped to 302 "Unconditional" 🙈 Same deal in reverse: if the mapping goes from one of the causes defined here to a PSTN system that doesn't have an equivalent reason value, it would be mapped to that network's equivalent of "Unconditional" 💀 And if a new cause parameter ever needs to be defined, this spec will have to be updated 🍓
The user portion of the URI SHOULD be used as the address of the voicemail system on the PSTN, while the target SHOULD be mapped to the original redirecting number on the PSTN side 📞
The redirection counters SHOULD be set to one unless additional information is available 🔢
2.3. Retrieving Messages 📬
Okay this one's fun. The UM system MAY use the fact that the From header is the same as the URI target as a hint that the user wants to retrieve messages 👀 Like, if the caller is literally the mailbox owner, they're probably checking their voicemail. Main character behavior 💅
3. Interaction with Request History Information 🌸
The Request History mechanism [6] gives you more info about multiple retargetings. It's totally reasonable to have systems where both the info in this spec and the History information are included, and where one or both get used 🫶
History-Info is a way to give the UAS and UAC info about how a request got retargeted 🦋 That info includes the initial Request-URI and any retarget-to URIs. It lives in the History-Info header field, which (except where privacy considerations get in the way) gets built up as the request moves along. Then, once it reaches the UAS, it gets returned in certain responses ✨
When History-Info is deployed at the relevant SIP entities, it's meant to give you a complete trace of the retargeting for a SIP request, along with the SIP response codes that led to each retarget 🔍
History-Info can totally complement this spec, bestie 💜 Here's how: when a proxy puts a URI with the parameters defined in this spec into the Request-URI of a forwarded request, the proxy can also add a History-Info header field entry to that forwarded request, and the URI in that entry will include these parameters. So even if a downstream proxy replaces the Request-URI while rerouting, the History-Info header field still has these parameters, which could be useful to the UAS 🧚 That said, UASes that use this info may find it in the History-Info header, in the Request-URI, or in both. It depends on whether the proxy can generate History-Info, or on how downstream proxies behave. So applications need to take that into account 🥺
4. Limitations of Voicemail URI ✨
okay so this part is kinda the honest-friend section 🫶 The spec says the proxy asking for the service has to figure out whether the UM system it's targeting actually understands this syntax. Right now the proxy only knows that because somebody configured it. So realistically this only works when the proxy has been told about the UM system, and when the UM is in the same administrative domain. If either of those is missing, it's giving "not gonna work" 💀
It also only works for pretty simple services. Like, it can't say something as specific as "Do not offer to connect to the target's colleague because that address has already been tried." That's a whole vibe check the proxy just can't express 🙈
The good news is the limitations in this section get handled by History-Info [6] ✨ so the drama has a happy ending.
5. Syntax 🎀
the ABNF[4] grammar for these parameters is below. The definitions of pvalue and Status-Code come from the ABNF in RFC 3261[1], so go check there if you want the full picture 💜
target-param = "target" EQUAL pvalue
cause-param = "cause" EQUAL Status-CodeQuick heads up though: some characters have to be escaped if they show up in the value of the target parameters. The "@" character is the main example, so it's a little bit of extra work but totally manageable 🍓
6. Examples 🦋
this section is all about example use cases for the solution in this document. UM is the main example we're using, but other applications can totally use this mechanism too 🧚 The examples are there to show how applicable this solution could be, not to put it in a box, so don't read them as the only way it works 💅
also, the examples only show service retargeting on busy, but you can easily adapt them to show other kinds of retargeting ✨
some of the examples have URIs broken across more than one line. That was just for formatting and it is not a valid SIP message 🙈 A few characters in the URIs aren't escaped correctly either, purely to make things easier to read. All the examples use sip: with UDP transport, again just for readability. Just know that sips: with TLS transport is the preferable option 🔒
6.1. Proxy Forwards Busy to Voicemail 📞
okay so in this one Alice calls Bob. Bob's proxy figures out that Bob is busy, so the proxy forwards the call to Bob's voicemail 💌 Alice's phone is at 192.0.2.1 and Bob's phone is at 192.0.2.2. The important thing to look at is the URI in message F7 👀
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 486 Busy F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:+15555551002@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Content-Length: 0F7: INVITE proxy.example.com -> um.example.com
INVITE sip:voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*6.2. Endpoint Forwards Busy to Voicemail 📱
in this example Alice calls Bob again, but this time Bob is busy and forwards the session straight to his voicemail himself 💅 Alice's phone is at 192.0.2.1 and Bob's phone is at 192.0.2.2. The important thing to note is the URI in the Contact in message F3 ✨
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | 302 Moved F3 | |
| 302 Moved F4 |<-------------| |
|<---------------| | |
| ACK F5 | | |
|--------------->| ACK F6 | |
| |------------->| |
| INVITE F7 |
|-------------------------------------------------->|
* Rest of flow not shown *F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*F3: 302 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486;>
Content-Length: 0F7: INVITE proxy.example.com -> um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*6.3. Endpoint Forwards Busy to TDM via a Gateway 🌈
in this one the voicemail is reached through a gateway to a TDM network 🧚 Bob's number is +1 555 555-1002, and voicemail's number on the TDM network is +1-555-555-2000.
The call flow is the same as in Section 6.2 except for the Contact URI in F4 and the Request URI in F7 💜
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 302 Moved F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486>
Content-Length: 0F7: INVITE proxy.example.com -> gw.example.com
INVITE sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486\
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*6.4. Endpoint Forwards Busy to Voicemail with History Info 🦋
Okay so this one shows how History Info works together with service retargeting 💅 The scenario is the same as Section 6.1 🌸
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4>;index=1.1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*F7: INVITE proxy.example.com -> um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4?Reason=SIP%3Bcause%3D302;\
text="Moved Temporarily">;index=1.1
<sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486>;index=2
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*6.5. Zero Configuration UM System ✨
In this one, the UM system has zero configuration info specific to any user 🧚 The proxy is set up to pass along a URI that gives the prompt to play, plus an email address in the user portion of the URI where the recorded message should be sent 💌
The call flow is the same as in Section 6.1, except that the URI in F7 changes to specify the user part as Bob's email address, and the Netann [7] URI play parameter specifies where the greeting to play can be fetched from.
F7: INVITE proxy.example.com -> voicemail.example.com
INVITE sip:voicemail@example.com;target=mailto:bob%40example.com;\
cause=486;play=http://www.example.com/bob/busy.wav SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15555551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*In addition, if the proxy wanted to tell the UM about a Voice XML (VXML) script it should run, it could add a parameter to the URI in the message above that looks like this:
voicexml=http://www.example.com/bob/busy.vxml6.6. Call Coverage 📞
In a Call Coverage example, someone on the PSTN calls an 800 number 📱 The gateway sends the call to the proxy, which figures out that the helpdesk is the target 🎀 Alice and Bob are staffing the help desk and get tried one after the other, but neither of them picks up, so the call gets forwarded to the helpdesk's voicemail 📨
The details of this flow are trivial and not shown. The key item in this example is that the INVITE to Alice and Bob looks as follows:
INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\
cause=302 SIP/2.07. IANA Considerations 📋
This specification adds two new values to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [3] 🌈
Parameter Name Predefined Values Reference
____________________________________________
target No [RFC4458]
cause Yes [RFC4458]8. Security Considerations 🔐
Okay, this part is SERIOUS 😭 This document is about transactions involving at least three parties, and that makes the privacy issues way more complicated 💀
The new URI parameters defined in this document are generally sent from a Proxy or call control system to a Unified Messaging (UM) system or to a gateway to the PSTN and then to a voicemail system. These new parameters tell the UM what service the proxy wants performed. Just like any message sent from the proxy to the UM needs to be integrity protected, these messages need to be integrity protected too, so attackers can't do stuff like send a voicemail meant for a company's CEO to an attacker's mailbox 🚨 RFC 3261 provides a TLS mechanism that's suitable for this integrity protection 🔒
The signaling from the Proxy to the UM or gateway will reveal who is calling whom, and maybe some info about a user's presence based on whether the call was answered or sent to voicemail 👀 This info can be protected by encrypting the SIP traffic between the Proxy and the UM or gateway. Again, RFC 3261 has mechanisms for doing this using TLS 🫶
Implementations should implement and use TLS 🔐✨
8.1. Integrity Protection of Forwarding in SIP 🛡️
The forwarding of a call in SIP brings up a very strange trust issue 🙈 Think about the normal case: A calls B, the call gets forwarded to C by a network element in B's domain, and then C answers the call. A called B but ended up talking to C. This scenario can be hard to tell apart from a man-in-the-middle attack 😱
There are two possible solutions. One is that B sends information back to A saying "don't call me, call C," and signs it as B. The problem is that this solution reveals that B has forwarded to C, which B often may not want to do. For example, B may be a work phone that has been forwarded to a mobile or home phone. The user doesn't want to reveal their mobile or home phone number but, even more importantly, doesn't want to reveal that they're not in the office 🏢
The other possible solution is that A needs to trust B only to forward to a trusted identity. This requires a hop-by-hop transitive trust, so each hop will only send to a trusted next hop and each hop will only do things the user at that hop wanted. This solution is enforced in SIP using the SIPS URI and TLS-based hop-by-hop security. It protects from an off-axis attack, but if one of the hops isn't trustworthy, the call may be diverted to an attacker 🕵️
Any redirection of a call to an attacker's mailbox is serious 🚫 It's trivial for an attacker to make its mailbox look very much like the real mailbox and forward the messages to the real mailbox, so the fact that the messages have been intercepted or even tampered with escapes detection. Approaches such as the SIPS URL and the History-Info[6] can help protect against these attacks 🛡️
8.2. Privacy Related Issues on the Second Call Leg 🎭
In the case where A calls B and gets redirected to C, people sometimes suggest there's a requirement for the call leg from B to C to be anonymous 🤔 The SIP case isn't the PSTN, and there's no call leg from B to C. Instead, there's a VoIP session between A and C. If A put a To header field value containing B in the initial invite message, then unless something special is done about it, C would see that To header field value. If the person who answers phone C says "I think you dialed the wrong number; who were you trying to reach?", A will probably say B 🙄
If A doesn't want C to see that the call was to B, A needs a special relationship with the forwarding Proxy to get it to not reveal that info. The call should go through an anonymization service that provides session or user level privacy (as described in RFC 3323 [2]) before going to C. It's not hard to figure out how to meet this requirement, but it's unclear why anyone would want this service 🤷♀️
The scenario where B wants to make sure C doesn't see that the call was to B is easier to deal with, but a bit weird 🙃 The usual argument is that Bill wants to forward his phone to Monica but doesn't want Monica to find out his phone number. It's hard to imagine Monica would want to accept all of Bill's calls without knowing how to call Bill to complain. The only person Monica will be able to complain to is Hillary, when she tries to call Bill. Several popular web portals send SMS alert messages about things like stock prices and weather to mobile phone users today. Some of these contain no information about the account on the web portal that started them, which makes it nearly impossible for the mobile phone owner to stop them. This anonymous message forwarding has turned out to be a really bad idea even where no malice is present 💔 Clearly some people are pretty dubious about the need for this, but never mind: let's look at how it's solved 💅
In the general case, the proxy needs to route the call through an anonymization service and everything gets cleaned up ✨ Any anonymization service that performs the "Privacy: Header" Service in RFC 3323 [2] must remove the cause and target URI parameters from the URI. Privacy of the parameters, when they form part of a URI within the History-Info header, is covered in History-Info [6] 🔐
This specification does not discuss the security considerations of mapping to a PSTN Gateway. Security implications of mapping to ISUP, for example, are discussed in RFC 3398 [5] 📡
9. Acknowledgements 💜
Many thanks to Mary Barnes, Steve Levy, Dean Willis, Allison Mankin, Martin Dolly, Paul Kyzivat, Erick Sasaki, Lyndsay Campbell, Keith Drage, Miguel Garcia, Sebastien Garcin, Roland Jesske, Takumi Ohba, and Rohan Mahy 🫶🌷
10. References 📚
10.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] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
- [3] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
- [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
10.2. Informative References ✨
Okay, now the bibliography bit 📚 These are the "for more context" sources, not the must-reads:
[5]Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.[6]Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.[7]Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.[8]"Stage 3 description for call offering supplementary services using signalling system No. 7: Call diversion services", ITU-T Recommendation Q.732.2-5, December 1999.[9]"Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part", ITU-T Recommendation Q.850, May 1998.[10]"ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1998.[11]"Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol", ISO/IEC 11572, March 2000.
Authors' Addresses 🎀
Meet the squad who made this happen 🫶
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Francois Audet
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
US
Phone: +1 408 495 3756
EMail: audet@nortel.com
John Elwell
Siemens plc
Technology Drive
Beeston, Nottingham NG9 1LA
UK
EMail: john.elwell@siemens.comFull Copyright Statement 💅
Legal time, but make it quick 🙈
Copyright (C) The Internet Society (2006).
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 🦋
Patents and rights, the vibe check 🔥
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 procedures with respect to rights in RFC 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 🌸
Last but not least, who keeps the lights on ✨
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
📦 where this page comes from
- ietf: rfc4458 2006-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms