RFC 3372
Session Initiation Protocol for Telephones (SIP-T): Context and Architectures
RFC 3372: Session Initiation Protocol for Telephones (SIP-T): Context and Architectures 🎀
Okay bestie, this one is RFC 3372, called Session Initiation Protocol for Telephones (SIP-T): Context and Architectures 💅. It came from the Network Working Group, written by A. Vemuri (Qwest Communications) and J. Peterson (NeuStar). It's a Best Current Practice, filed as BCP 63, and it's dated September 2002 🌸. The title block doesn't list anything it obsoletes or updates, so it stands on its own ✨.
Status of This Memo 📜
This doc is an Internet Best Current Practice for the Internet Community 🫶. It also asks people to talk about it and send in suggestions for making it better. Anyone can distribute it, with no limits 🦋.
Copyright Notice ©
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract ✨
Gateways that connect the PSTN (Public Switched Telephone Network) with SIP networks are super popular right now 🔥, so people wanted a set of shared practices to keep behaviour consistent across different implementations 💖. This document sorts out the different ways PSTN-SIP gateways get used 🗂️, walks through some use cases 🧚, and names the mechanisms needed for interworking 🌈. Those mechanisms show how SIP handles both 'encapsulation' (carrying PSTN signaling across a SIP network) and 'translation' (gatewaying) 👑.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SIP-T for ISUP-SIP Interconnections . . . . . . . . . . . . . 4
3. SIP-T Flows . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 SIP Bridging (PSTN - IP - PSTN) . . . . . . . . . . . . . . . 8
3.2 PSTN origination - IP termination . . . . . . . . . . . . . . 9
3.3 IP origination - PSTN termination . . . . . . . . . . . . . . 11
4. SIP-T Roles and Behavior . . . . . . . . . . . . . . . . . . . 12
4.1 Originator . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Terminator . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Intermediary . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Behavioral Requirements Summary . . . . . . . . . . . . . . . 15
5. Components of the SIP-T Protocol . . . . . . . . . . . . . . . 16
5.1 Core SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Translation . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Support for mid-call signaling . . . . . . . . . . . . . . . . 17
6. SIP Content Negotiation . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 231. Introduction 🦋
Okay so SIP [1] is an application-layer control protocol 💅. It can set up, change and tear down multimedia sessions or calls 📞. Those sessions include multimedia conferences, Internet telephony and similar stuff 🎀. SIP is one of the key protocols behind Voice over IP (VoIP) 🌈. Doing telephony call signaling and carrying the audio over IP is a huge upgrade on old-school telephony ✨, but a VoIP network can't just live alone 🙈. A SIP telephony network has to interwork with the PSTN, and that's non-negotiable bestie 👑.
Gateways that interwork between the PSTN and SIP networks are popular 🔥, which is why people wanted a set of common practices that keep behaviour consistent across implementations 💖. SIP expertise is kind of rare outside the IETF 🧚, so the IETF is the best place to stage this work 🌸. SIP is also still a bit of a moving target compared with the core PSTN protocols 🙈. The IETF working groups that focus on SIP (SIP and SIPPING) are the ones best placed to figure out whether any new SIP extensions are actually justified for PSTN interworking 💜. This framework covers the overall context where PSTN-SIP interworking gateways might get deployed, gives use cases, and identifies the mechanisms needed for interworking 🦋.
Feature transparency is a big deal for any SIP telephony network with respect to the PSTN ✨. Classic telecom services like call waiting, freephone numbers, etc., are built into PSTN protocols such as Signaling System No. 7 (SS7 [6]) 📞. A SIP network should offer them in a way that doesn't cause any debilitating difference in user experience, while still keeping SIP flexible 🌈. SIP needs the primitives to deliver these services when the terminating point is a regular SIP phone (see definition in Section 2 below) and not a device that speaks SS7 fluently 💅. It's also essential that SS7 information is available at gateways, the points of SS7-SIP interconnection, so features that SIP doesn't otherwise support stay transparent 👑. If possible, SS7 information should be available in its entirety, without any loss, to trusted parties in the SIP network across the PSTN-IP interface 🫶. One big reason for this is that certain networks use proprietary SS7 parameters to send certain information through their networks 🙈.
Routability is the other key characteristic 🧚. A SIP request that sets up a telephone call should carry enough information in its headers so proxy servers in the SIP network can route it to the right destination 💖. Most commonly this means call parameters like the dialed number have to get carried over from SS7 signaling into SIP requests 📞. Routing in a SIP network may also be influenced by mechanisms like TRIP [8] or ENUM [7] 🌸.
SIP-T (SIP for Telephones) is the effort that builds a framework for plugging legacy telephony signaling into SIP messages 🎀. SIP-T delivers those two characteristics through techniques called 'encapsulation' and 'translation' 🦋. At a SIP-ISUP gateway, SS7 ISUP messages get encapsulated inside SIP so that info needed for services doesn't get thrown away from the SIP request 💜. But proxy servers that make routing decisions for SIP requests can't be expected to understand ISUP 😭, so at the same time, some critical info gets translated from an ISUP message into the matching SIP headers so the request can be routed 🔥.
Pure SIP has everything it needs to set up and tear down calls 💅, but it has no baseline mechanism for carrying mid-call information along the SIP signaling path during the session 🙈. Mid-call stuff like the ISUP INF/INR query is one example 🧚. That kind of info doesn't change the state of SIP calls or the parameters of the sessions SIP starts ✨. Still, a way to send that optional application-layer information is needed 🌈.
Here's the problem we're solving: giving ISUP transparency across SS7-SIP interworking 👑.
SS7-SIP Interworking Requirements SIP-T Functions
==================================================================
Transparency of ISUP Encapsulation of ISUP in the
Signaling SIP body
Routability of SIP messages with Translation of ISUP information
dependencies on ISUP into the SIP header
Transfer of mid-call ISUP signaling Use of the INFO Method for mid-
messages call signaling
Table 1: SIP-T features that fulfill PSTN-IP inter-connection
RequirementsThis doc spells out the requirements above, but it doesn't provide the mechanisms to meet them 🫠. Instead, it serves as a framework for the documents that do provide those mechanisms 🧚, and all of them are referenced in Section 5 💜.
Also, lots of signaling modes get used in telephony, like SS7 ISUP, BTNUP, Q.931, MF and more 📞. This document focuses on SS7 ISUP and only aims to specify behaviour across ISUP-SIP interfaces 🎀. The SIP-T scope might grow over time to cover other signaling systems too 🌈✨
2. SIP-T for ISUP-SIP Interconnections ✨
okay so SIP-T is not a brand new protocol 🙈 it's a set of mechanisms for getting traditional telephone signaling and SIP to talk to each other. the whole point is protocol translation and feature transparency at every spot where the PSTN meets SIP 💖 it's meant for when a VoIP network (a SIP network, for this doc) has to interface with the PSTN 📞
with SIP-T there are three basic ways calls can move through gateways 🦋 first, calls that start in the PSTN can go through a gateway and end up at a SIP endpoint, like an IP phone. then it works the other way too: an IP phone can make a call that goes through a gateway and ends in the PSTN. and lastly, an IP network using SIP can act as a transit network between gateways. so a call can start and end in the PSTN but cross a SIP network somewhere in the middle, main character energy 👑
the SS7 interfaces on a particular gateway decide which ISUP variants that gateway supports 🔥 and whether or not it supports a certain version of ISUP determines if it can keep feature transparency while terminating a call. big deal, bestie 💅
these are the main players in a SIP-T-enabled network 🌈
- PSTN (Public Switched Telephone Network): this is the whole interconnected mess of local, long-distance and international phone companies 📞 in the examples, the term Local Exchange Carrier (LEC) is used for a piece of it (usually a regional division) 🌸
- IP endpoints: any SIP user agent that can act as an originator or recipient of calls 💜 so these count as IP endpoints:
- Gateways: a telephony gateway is the point where signaling protocols get converted (like ISUP and SIP), and it also handles circuit-switched and packet-switched audio media ✨ the term Media Gateway Controller (MGC) also shows up in the examples and diagrams to mean big clusters of decomposed gateways and control logic that are really common today 🧚 so for example, a SIP-ISUP gateway speaks ISUP to the PSTN and SIP to the Internet, and it's responsible for converting between the two types of signaling, plus swapping any bearer audio media along the way 🎀
- SIP phones: the term for all the end-user devices that originate or terminate SIP VoIP calls 📱
- Interface points between networks where administrative policies get enforced (these could be middleboxes, proxy servers, or gateways) 🔒
- Proxy Servers: a proxy server is a SIP intermediary that routes SIP requests to where they need to go 🦋 for example, a proxy might send a SIP request to another proxy, a gateway, or a SIP phone 💖
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------Figure 1: Motivation for SIP-T in ISUP-SIP interconnection
okay this next part is the 🧠 bit. in Figure 2 a VoIP cloud is acting as a transit network for phone calls that start in a pair of LECs, and SIP is the VoIP protocol that sets these calls up and tears them down 📞 at the edge of the network, an MGC turns the ISUP signals into SIP requests and sends them to a proxy server, which then routes the calls on to other MGCs 💅 the figure only shows two MGCs, but real VoIP deployments would commonly have lots of these PSTN interconnection points (usually to spread things across PSTN rate centers) 🌈
so for a call that starts in LEC1 and ends in LEC2, the originator in SIP-T is the gateway that generates the SIP request for the VoIP call, and the terminator is the gateway that consumes that SIP request. that makes MGC1 the originator and MGC2 the terminator 🎀 and note that one or more proxies may be used to route the call from the originator to the terminator ✨
here's the key idea 🔑 to seamlessly connect the IP network with the PSTN, it's important to preserve the SS7 information that was received inside the SIP requests at the originating gateway, and then reuse that SS7 information when signaling to the PSTN at the terminating gateway 😭 by encapsulating the ISUP information in the SIP signaling, the SIP network can make sure that no SS7 information critical to instantiating features gets lost when SIP bridges calls between two segments of the PSTN 🫶
now, real talk 🤔 if the only thing that mattered was exchanging ISUP between gateways, then any protocol for transporting signaling information could do the job, and you wouldn't need SIP or SIP-T at all 🙈 SIP-T gets used because it borrows the intrinsic benefits of SIP: request routing and call control using proxy servers (including forking), easy SIP service creation, SIP's capability negotiation systems, and so on 💜 translating info from the received ISUP message parameters into SIP header fields lets SIP intermediaries look at that info as they handle requests 👀 so SIP-T helps set up calls and enables new telephony services over the IP network, and it gives you a feature-rich way to interconnect with the PSTN at the same time ✨ ate and left no crumbs 💅
finally, the Figure 2 scenario is just one of several flows where SIP-T can be used 🦋 voice calls don't always both start and end in the PSTN (through gateways), and SIP phones can be endpoints in a SIP-T session too 📱 the following flows get more detail in later sections 👑
- PSTN origination - PSTN termination: the originating gateway receives ISUP from the PSTN and preserves that information (through encapsulation and translation) in the SIP messages it sends toward the terminating gateway 🌸 the terminator pulls the ISUP content out of the SIP message it receives and reuses that information in signaling sent to the PSTN 💖
- PSTN origination - IP termination: the originating gateway receives ISUP from the PSTN and preserves that ISUP information in the SIP messages (through encapsulation and translation) that it sends to the terminating SIP user agent 🧚 the terminator has no use for the encapsulated ISUP, so it ignores it 🙈
- IP origination - PSTN termination: a SIP phone starts a VoIP call that gets routed by one or more proxy servers to the right terminating gateway 📞 the terminating gateway converts it to ISUP signaling and sends the call to an appropriate PSTN interface, based on the information present in the received SIP header 🎀
- IP origination - IP termination: this is a case for pure SIP 💅 SIP-T (either encapsulation or translation of ISUP) doesn't come into play, since there's no PSTN interworking 🌈
3. SIP-T Flows 🦋
okay so these next sections dig into the essential SIP-T flows in detail ✨ a thing to know: proxy servers are usually the ones routing SIP requests (based on the Request-URI), so the originator generally doesn't know where a SIP request will eventually end up 🫣 which means the originator doesn't pick a flow from the ones described here, either through static configuration or on a per-call basis 🙅♀️ instead, each call gets routed by the SIP network on its own, and it can end up running any of the flows below depending on what the network's routing logic decides 👑
3.1 SIP Bridging (PSTN - IP - PSTN) 🌸
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|---| |---|
/|MGC| VoIP Network |MGC|\
/ --- --- \
/ * * \
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| PSTN | *** *** | PSTN |
-------- ********************* ---------Figure 2: PSTN origination - PSTN termination (SIP Bridging)
this is the scenario where a SIP network connects two segments of the PSTN, and it's called 'SIP bridging' 🌉 when a call headed for the SIP network starts in the PSTN, an SS7 ISUP message eventually shows up at the gateway that's the point of interconnection with the PSTN network 📞 from SIP's point of view, this gateway is the user agent client for that call setup request 💖 traditional SIP routing in the IP network figures out the right termination point (here, a gateway), sets up a SIP dialog, and starts negotiating a media session between the origination and termination endpoints 🦋 then the egress gateway signals ISUP to the PSTN, reusing any encapsulated ISUP that was in the SIP request it got, as appropriate ✨
here's a super basic call flow for SIP bridging 👇
PSTN MGC#1 Proxy MGC#2 PSTN
|-------IAM------>| | | |
| |-----INVITE---->| |
| | | |-----IAM----->|
| |<--100 TRYING---| |
| | | |<----ACM------|
| |<-----18x-------| |
|<------ACM-------| | | |
| | | |<----ANM------|
| |<----200 OK-----| |
|<------ANM-------| | | |
| |------ACK------>| |
|====================Conversation=================|
|-------REL------>| | | |
|<------RLC-------|------BYE------>| |
| | | |-----REL----->|
| |<----200 OK-----| |
| | | |<----RLC------|
| | | | |3.2 PSTN origination - IP termination ✨
okay so this one is a call that starts in the PSTN and ends up ringing a SIP phone 📞 bestie, the diagram is giving main character energy 💅
********************
*** ***
* *
* *
* *
* *
|----| |-----|
/|MGC | VoIP Network |proxy|\
/ ---- ----- \
/ * * \
/ * * \
/ * * \
-------- * * -------------
| PSTN | ** ** | SIP phone |
-------- ********************* -------------Figure 3: PSTN origination - IP termination
so a call comes in from the PSTN and lands on a SIP phone 🦋 ngl, heads up that in Figure 5 the proxy server is the registrar for that SIP phone 🫶
here's a simple call-flow showing the ISUP and SIP signaling for a PSTN-originated call that terminates at a SIP endpoint ✨
PSTN MGC Proxy SIP phone
|----IAM----->| | |
| |--------INVITE------>| |
| | |-------INVITE------->|
| |<------100 TRYING----| |
| | |<-------18x----------|
| |<---------18x--------| |
|<----ACM-----| | |
| | |<-------200 OK-------|
| |<-------200 OK-------| |
|<----ANM-----| | |
| |---------ACK-------->| |
| | |---------ACK-------->|
|=====================Conversation========================|
|-----REL---->| | |
| |----------BYE------->| |
|<----RLC-----| |---------BYE-------->|
| | |<-------200 OK-------|
| |<-------200 OK-------| |
| | | |3.3 IP origination - PSTN termination 🌸
this flow is the reverse: the call starts on a SIP phone and ends up in the PSTN 🎀 unlike the previous two flows, there's no ISUP encapsulation in the request, so the terminating gateway only translates the SIP headers to work out the values for the ISUP parameters 🧚
********************
*** ***
* *
* *
* *
* *
|-----| |----|
/|proxy| VoIP Network |MGC |\
/ ----- ---- \
/ * * \
/ * * \
/ * * \
------------ * * ---------
|SIP phone | ** ** | PSTN |
------------ ********************* ---------Figure 4: IP origination - PSTN termination
here's a simple call-flow showing the different legs of the call 🍓
SIP phone Proxy MGC PSTN
|-----INVITE----->| | |
| |--------INVITE-------->| |
|<---100 TRYING---| |-----IAM---->|
| |<------100 TRYING------| |
| | |<----ACM-----|
| |<---------18x----------| |
|<------18x-------| | |
| | |<----ANM-----|
| |<--------200 OK--------| |
|<-----200 OK-----| | |
|-------ACK------>| | |
| |----------ACK--------->| |
|========================Conversation===================|
|-------BYE------>| | |
| |----------BYE--------->| |
| | |-----REL---->|
| |<--------200 OK--------| |
|<-----200 OK-----| |<----RLC-----|4. SIP-T Roles and Behavior 👑
so there are three distinct kinds of elements (from a functional point of view) in a SIP VoIP network that talks to the PSTN 💜
- The originators of SIP signaling
- The terminators of SIP signaling
- The intermediaries that route SIP requests from the originator to the terminator
the behavior for the Section 4.1, Section 4.2 and Section 4.3 intermediary roles in a SIP-T call is covered in the sections below 🫶
4.1 Originator 🎀
the originating user agent client is the one that generates the SIP call setup requests (a.k.a. INVITEs) 📞 when a call starts in the PSTN, a gateway is the UAC. otherwise, some native SIP endpoint is the UAC. either way, the originator usually can't predict what kind of entity the terminator will be, meaning whether the final destination of the request is in a SIP network or the PSTN 🤷♀️
for calls that start in the PSTN (see Figure 3 and Figure 5), the originating gateway has to preserve the ISUP information by encapsulating it in the SIP request it creates 🔥 it's also responsible for identifying the version of ISUP it received (ETSI, ANSI, etc.) and providing that info in the encapsulated ISUP (usually by adding a multipart MIME body with the right MIME headers) 💅 then it builds the headers of the SIP INVITE from the ISUP parameters it got from the PSTN, as appropriate (see Section 5). for example, it might set the To: header field in the INVITE to reflect the dialed number (Called Party Number) from the received ISUP IAM 🌈
in other cases (like Figure 7), a SIP phone is the originator of a VoIP call 📱 usually the SIP phone sends requests to a SIP proxy that's in charge of routing them to an appropriate destination. there's no ISUP to encapsulate at the user agent client, since there's no PSTN interface 🙈 the call might end up in the telephone network and need ISUP signaling to get there, but the originator has no way to know that, and it would be foolhardy to require every SIP VoIP user agent to be able to generate ISUP 😭 so an IP endpoint like a SIP phone is not responsible for generating encapsulated ISUP. instead, an originator must generate the SIP signaling while doing ISUP encapsulation and translation when possible (meaning when the call started in the PSTN) ✨
Originator requirements: encapsulate ISUP, translate information from ISUP to SIP, multipart MIME support (for gateways only) 🍓
4.2 Terminator 💅
the SIP-T terminator is the consumer of the SIP calls 💖 it's a standard SIP UA, and it can be either a gateway that interworks with the PSTN or a SIP phone 🦋
for PSTN terminations (see Figure 3 and Figure 7), the egress gateway terminates the call on its PSTN interface 🔥 the terminator generates the ISUP needed to signal the PSTN from the incoming SIP message. some ISUP parameter values can be gleaned from the SIP headers or pulled straight from an encapsulated ISUP body 🧚 generally speaking, a gateway uses any encapsulated ISUP as a template for the message it will send, but it overwrites parameter values in that template as it translates the SIP headers, and it adds any parameter values that reflect its local policies (see Appendix A item 1) 👑
for IP terminations (Figure 5), the SIP UAS that receives SIP messages with encapsulated ISUP typically ignores the ISUP message 🙈 this does create a general requirement, though: devices like SIP phones need to handle multipart MIME messages and unknown MIME types gracefully (this is a baseline SIP requirement, but it's also a spot where vendors have been known to take shortcuts 👀)
Terminator requirements: standard SIP processing, interpretation of encapsulated ISUP (for gateways only), support for multipart MIME, graceful handling of unknown MIME content (for non-gateways only) 🌸
4.3 Intermediary ✨
okay so intermediaries like proxy servers are the ones trusted with routing messages to each other, plus gateways and SIP phones 🧚. each proxy makes a forwarding decision for a SIP request based on values of various headers, or 'routable elements' (including the Request-URI, route headers, and potentially many other elements of a SIP request) 💅
SIP-T does add some extra stuff to think about when forwarding a request, and that can mean new features and requirements for intermediaries 👀. feature transparency of ISUP is literally the heart of SIP-T 💖. when the ISUP variants on the originating and terminating PSTN interfaces are compatible, feature transparency happens automatically ✨. so proxy servers might start caring about which ISUP variant is encapsulated with a request, because the variant itself could become a routable element 🦋. where the call terminates also matters, since ending up closer to the final destination (rate considerations) is a big deal 💸. choosing one option over the other is a trade-off between simplicity of operation and cost 🙈. sometimes getting a reasonable rate means a SIP-T call has to span dissimilar PSTN interfaces (SIP bridging across different gateways that don't support any ISUP variants in common) 🌈. to get the best mix of feature transparency and rate, some intermediary operators might want to look at practices like these:
a) ISUP feature transparency may need ISUP variant translation (conversion), meaning conversion from one ISUP variant to another so the call can terminate over a gateway interface that doesn't support the ISUP variant of the originating PSTN interface. (See Appendix A item 2.) in theory the conversion can happen anywhere along the path of the request, but it's best done as close as possible to the terminating gateway 🎀. this can be done by delivering the call to an application that might perform the conversion between variants. feature transparency here depends on having resources available to do the ISUP conversion, and it adds to the call set-up time ⏳.
b) the other option is to sacrifice ISUP transparency by handing the call off to a gateway that doesn't support the version of the originating ISUP. the terminating MGC would then just ignore the encapsulated ISUP and use the information in the SIP header to terminate the call 🫶.
so yeah, it can be really useful for proxy servers to be smart enough to make a judicious choice from the options they have 🧠👑.
Proxy requirements: ability to route based on choice of routable elements 🌸
4.4 Behavioral Requirements Summary 📋
if the SIP-T originator is a gateway that received an ISUP request, it must always perform both encapsulation and translation ISUP, no matter where the originator might guess the request will terminate 🙌.
if the terminator doesn't understand ISUP, it just ignores it and does standard SIP processing 🫠. if the terminator does understand ISUP and needs to signal to the PSTN, it should reuse the encapsulated ISUP as long as it understands the variant 💜. the terminator should go through these steps:
- Extract the ISUP from the message body, and use this ISUP as a message template. note that if there's no encapsulated ISUP in the message, the gateway should use a canonical template for the message type in question (a pre-populated ISUP message configured in the gateway) instead 🍓.
- Translate the headers of the SIP request into ISUP parameters, overwriting any values in the message template ✍️.
- Apply any local policies in populating parameters 🎀.
an intermediary must be able to route a call based on the choice of routable elements in the SIP headers 🦋.
5. Components of the SIP-T Protocol 🧩
the mechanisms in the following sections are the components of SIP-T that provide the protocol functions the requirements call for 💅.
5.1 Core SIP ☎️
SIP-T uses the methods and procedures of SIP as defined by RFC 3261 ✨.
5.2 Encapsulation 📦
encapsulating the PSTN signaling is one of the major requirements of SIP-T 🫶. SIP-T uses multipart MIME bodies so SIP messages can carry multiple payloads (Session Description Protocol or SDP [5], ISUP, etc.) 🌈. there are tons of ISUP variants out there today, so the ISUP MIME type lets recipients recognize the ISUP type (and figure out whether they support the variant) in the most expeditious way possible 🏃♀️💨. one scheme for doing ISUP encapsulation with multi-part MIME has been described in [2] 📚.
5.3 Translation 🔁
translation covers all aspects of signaling protocol conversion between SIP and ISUP 💖. basically there are two pieces to the problem 🧩:
- ISUP SIP message mapping: this describes a mapping between ISUP and SIP at the message level. in SIP-T deployments, gateways are trusted with generating a specific ISUP message for each SIP message received, and vice versa. we need to spell out the rules that govern the mapping between ISUP and SIP messages (i.e., which ISUP message gets sent when a particular SIP message is received: an IAM must be sent on receipt of an
INVITE, aRELforBYE, and so on) 📨. a potential mapping between ISUP and SIP messages has been described in [10] 💅. - ISUP parameter-SIP header mapping: a SIP request that sets up a telephone call should contain info that lets proxy servers in the SIP network route it to its destination, like the telephone number the originating user dialed 📞. it's important to standardize a set of practices that defines how information gets translated from ISUP to SIP (for example, the Called Party Number in an ISUP IAM must be mapped onto the SIP
Toheader field and Request-URI, etc.) 🎯. this gets way more complicated because intermediaries may transform the headers of a SIP request (especially an INVITE), so the SIP headers and encapsulated ISUP bodies can end up expressing conflicting values. basically, part of the encapsulated ISUP might become irrelevant and obsolete 🥲.
5.4 Support for mid-call signaling 🎶
pure SIP has no provision for carrying mid-call control information that gets generated during a session 😬. the INFO [3] method should be used for this purpose. heads up though, INFO isn't suitable for managing overlap dialing (for one way of implementing overlap dialing, see [11]) ⚠️. also, using INFO for signaling mid-call DTMF signals is not recommended (see RFC2833 [9] for a recommended mechanism) 🙅♀️.
6. SIP Content Negotiation 🎭
the originator of a SIP-T request might pack both SDP and ISUP elements into the same SIP message using the MIME multipart format 📦. traditionally in SIP, if the terminating device doesn't support a multipart payload (multipart/mixed) and/or the ISUP MIME type, it rejects the SIP request with a 415 Unsupported Media Type that lists the media types it supports (by default, application/SDP) 🙅♀️. then the originator has to re-send the SIP request after stripping out the ISUP payload (so only the SDP payload is left), and that version gets accepted 😮💨.
that's a super cumbersome flow 😭, so it's really desirable to have a mechanism where the originator can signify which bodies are required and which are optional. then the terminator can quietly discard the optional bodies it doesn't understand (which lets a SIP phone ignore an ISUP payload when processing ISUP isn't critical) 🫧. this depends on the terminator supporting a Content-type of multipart/mixed and having access to the Content-Disposition header to express criticality 💜.
- Support for ISUP is optional. Therefore, UA2 accepts the INVITE irrespective of whether it can process the ISUP 🍃.
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=optional;)
<--18x- Support for ISUP is preferred. UA2 doesn't support the ISUP and rejects the INVITE with a
415 Unsupported Media Type. UA1 strips off the ISUP and re-sends the INVITE with SDP only, and this is the one that gets accepted 🎉.
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
INVITE-->
(Content-type: application/sdp)
<--18x- Support for ISUP is mandatory for call establishment. UA2 doesn't support the ISUP and rejects the INVITE with a
415 Unsupported Media type. UA1 then directs its request to UA3 🏃♀️💨.
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
UA1 UA3
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)note that the message exchanges above aren't complete. only the messages relevant to this discussion are shown 🙈. specifics of the ISUP MIME type can be found in [2]. the version and base parameters aren't shown here, but they must be used in accordance with the rules of [2] 📖✨.
7. Security Considerations 🔐
okay bestie, this section is SERIOUS but also kind of iconic 💅 SIP-T can work as an interdomain signaling mechanism, and it might run on top of the trust relationships that already exist between administrative domains. In a lot of legal environments, ISUP distribution is restricted to licensed carriers. SIP-T is tricky here because it bridges carrier signaling with end-user signaling 😭 Any administrative domain that implements SIP-T should have a solid security setup in place, including the parts that handle fraud and billing policies across domains, so that sending ISUP information doesn't cause any security violations 🛡️✨
Transporting ISUP inside SIP bodies can open the door to abuse, fraud, and privacy problems, especially when SIP-T requests can be generated, inspected, or modified by any SIP endpoint at all 🙈 To deal with this, ISUP MIME bodies should be secured, preferably with S/MIME [4]. This is also covered in the Security Considerations of the core SIP specification [1] 🔥 The authentication properties of S/MIME let the recipient of a SIP-T message confirm that the ISUP MIME body came from an authorized entity 💜 Encryption means that only carriers holding a particular decryption key can inspect the encapsulated ISUP MIME bodies in a SIP request 🌸
SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and SHOULD support encryption (CMS EnvelopedData). 🎀
8. IANA Considerations 🌈
this one's short and sweet 🧚 This document introduces no new considerations for IANA.
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, May 2002.
- [2] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
- [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
- [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
- [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
Non-Normative References 🦋
- [6] International Telecommunications Union, "Signaling System No. 7; ISDN User Part Signaling procedures", ITU-T Q.764, September 1997,
http://www.itu.int. - [7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
- [8] Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
- [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
- [10] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP Mapping", Work in Progress.
- [11] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of ISUP Overlap Signaling to SIP", Work in Progress.
Appendix A. Notes 📝
- Some terminating MGCs may alter the encapsulated ISUP in order to remove any conditions specific to the originating circuit. For example, continuity test flags in the Nature of Connection Indicators, etc. 💖
- Even so, the relevance of ANSI-specific information in an ETSI network (or vice versa) is questionable. Clearly, the strength of SIP-T is realized when the encapsulated ISUP involves the usage of proprietary parameters. 👑
Appendix B. Acknowledgments 🫶
we thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan Rosenberg, Dean Willis, Robert F. Penfield, Steve Donovan, Allison Mankin, Scott Bradner and Steve Bellovin for their valuable comments ✨
the original 'SIP+' proposal for interconnecting portions of the PSTN with SIP bridging was developed by Eric Zimmerer 🧚
Authors' Addresses 🎀
Aparna Vemuri-Pattisam
Qwest Communications
6000 Parkwood Pl
Dublin, OH 43016 US
EMail: Aparna.Vemuri@Qwest.com
vaparna10@yahoo.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520 US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/Full Copyright Statement ©️
Copyright (C) The Internet Society (2002). All Rights Reserved. 🌸
this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English 🌍
the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💜
this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 🙈
Acknowledgement 💅
funding for the RFC Editor function is currently provided by the Internet Society. 🍓
📦 where this page comes from
- ietf: rfc3372 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms