RFC 5638
Simple SIP Usage Scenario for Applications in the Endpoints
RFC 5638: Simple SIP Usage Scenario for Applications in the Endpoints 💖
okay bestie, let's get the basics down first 🎀 This one came out in September 2009. The lead editor is H. Sinnreich, Ed., who was at Adobe, and the other authors are A. Johnston and E. Shim from Avaya, plus K. Singh from Columbia University Alumni. It's part of the Network Working Group series.
The category is Informational, which means it gives information to the Internet community and doesn't specify an Internet standard. It doesn't obsolete or update anything, since there are no Obsoletes or Updates lines in its header 🧚
Abstract ✨
okay so the big idea here is that for Internet-centric stuff, you can get away with way fewer SIP-required standards for presence, IM, and audio/video calls 🦋 You only need the rendezvous and session-initiation parts of SIP, and it's giving simplicity. The trick is to stop copying how old telephony and its intelligent network work. "Simple SIP" leans on powerful computing endpoints, and desktop apps can team up with rich Internet applications (RIAs). Important telephony features can even live in the endpoints too 💅
This approach brings the number of SIP standards you have to follow down from roughly 100 (and it's still growing, ngl 💀) to about 11 🌸
The doc also covers references for NAT traversal and for security, so you're not left hanging 🫶
Status of This Memo
this memo gives information to the Internet community. It does not specify an Internet standard of any kind, and it can be distributed without limits 🌈
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
So this document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the day it was published. 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 without warranty, as described in the BSD License.
Table of Contents 🍓
1. Introduction ....................................................3
2. The Endpoint in the SIP and Web Architectures ...................5
2.1. The Telephony Gateway as a SIP Endpoint ....................6
3. Applicability for Simple SIP in the Endpoints ...................7
3.1. What Simple SIP Can Accomplish .............................7
3.2. Baseline for Simple SIP ....................................7
3.3. What Simple SIP May or May Not Accomplish ..................8
3.4. What Is Out of Scope for Simple SIP ........................8
3.5. Borderline Cases ...........................................9
4. Mandatory SIP References for Internet-Centric Usage .............9
4.1. RFC 3261: "SIP: Session Initiation Protocol" ..............10
4.2. RFC 4566: "SDP: Session Description Protocol" .............10
4.3. RFC 3264: "An Offer/Answer Model with Session
Description Protocol (SDP)" ...............................10
4.4. RFC 3840: "Indicating User Agent Capabilities in
the Session Initiation Protocol (SIP)" ....................10
4.5. RFC 3263: "Session Initiation Protocol (SIP):
Locating SIP Servers" .....................................11
4.6. RFC 3265: "Session Initiation Protocol
(SIP)-Specific Event Notification" ........................11
4.7. RFC 3856: "A Presence Event Package for the
Session Initiation Protocol (SIP)" ........................11
4.8. RFC 3863: "Presence Information Data Format (PIDF)" .......11
4.9. RFC 3428: "Session Initiation Protocol (SIP)
Extension for Instant Messaging" ..........................12
4.10. RFC 4474: "Enhancements for Authenticated
Identity Management in the Session Initiation
Protocol (SIP)" ..........................................12
4.11. RFC 3581: "An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing" ...........12
4.12. Updates to SIP-Related Protocols .........................12
5. SIP Applications in the Endpoints ..............................12
6. NAT Traversal ..................................................14
7. Security Considerations ........................................14
8. Acknowledgements ...............................................15
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................171. Introduction ✨
okay so SIP has basically become the global standard for real-time multimedia communications over the Internet and in private IP networks 🌍 Service providers and enterprise networks both adopted it, and that's a huge win. The downside is that all those different network requirements keep piling on complexity 😭 Meanwhile the Web turned into a platform for a boundless variety of rich Internet applications (RIAs), both in the browser and on the desktop 🦋 For SIP to be useful for RIAs, you can skip the unnecessary complexity that legacy voice-service providers bring by handing the interworking off to telephony gateway endpoints. This usage scenario needs you to follow the end-to-end principle of the Internet architecture at the application level, which is a fancy way of saying: put the SIP applications in the endpoints 💅
there are a few reasons, from the Web service's point of view, to put most or all SIP applications in the endpoints and only use the client-server (CS) or peer-to-peer (P2P) rendezvous function for SIP ✨
- Value proposition: SIP applications in the endpoints mix easily with RIAs, so service providers can roll out new services in a scalable and flexible way 🎀 Mixing SIP apps with RIAs also seriously boosts how valuable those SIP apps are. RIAs give users unrestricted choice, which goes way beyond the usual prepackaged network-based communication plans 👑
- Eliminating the problems associated with distributed SIP applications in various feature servers across the network allows us to greatly simplify SIP. There's also the Internet end-to-end principle, which argues that network intermediaries can't fully understand the applications and their state in the endpoints 🙈
so "Simple SIP" in this doc means the SIP functions you need to support just the rendezvous and session-setup functions, plus voice, video, basic presence, instant messaging, and security 💖 Simple SIP is all about a basic multimedia, real-time communications "call" 📞 That covers presence, IM, voice, and video for point-to-point calls and various conference apps. You might also have one or a very small number of additional servers 🧚 For example, a voice-mail server can be an auxiliary that makes a simple one-to-one call to voice mail if the callee doesn't answer, or lets you check your voice mail 💜
once the apps in the endpoints have set up basic communications, it's on them to support the available features that users pick 🌸 This paper is aimed at those scenarios. In telephony, most of the value for users and service providers comes from signaling. On the Web, though, RIAs add most of the value 🌈 Using SIP and RIAs together in the endpoints gets you the best of both worlds, honestly iconic ⭐
this approach limits the number of SIP standards to roughly 11, which are listed here as the core for simple SIP 🍓 When this was written, the Real-Time Applications and Infrastructure (RAI) area of the IETF was focused on a dedicated working group for the core SIP protocol, separate from the various SIP applications. The expectation is that this emerging work will also be the core of what's called simple SIP here, and it'll cut down even more on the references that cover the present core SIP standards 🔥
this memo wants to shield Web application developers from having to know or understand anything beyond the core SIP protocol 🫶 It keeps the total number of references to a minimum, and it also touches on related topics like examples for providing telephony services in the endpoints, NAT traversal, and security. The referenced papers are entry points to those knowledge resources, not the full story 💅 If you want a more detailed list of SIP topics, especially telephony, you can check out the big list in "A Hitchhikers' Guide to SIP", RFC 5411 [12] 🦋 That guide has over 140 references for understanding most, but not all, of the published SIP features in the IETF and elsewhere. There's also a Web site that automatically tracks the number of SIP-related RFCs [13] 👀 Other standards and commercial organizations have hugely expanded the published features of SIP too. The authors couldn't give a complete count of everything that's been published as some form of SIP-standard document 😭
NAT traversal is also a basic requirement for simple SIP 🌈 That said, since endpoints might use the Host Identity Protocol (HIP), as shown in Section 4, simple SIP may not need any standards other than the ones mentioned here ✨ The other option instead of HIP is to use SIP-specific protocols for NAT traversal, like STUN (Simple Traversal of the UDP Protocol through NAT), TURN (Traversal Using Relay NAT), and ICE (Interactive Connectivity Establishment), which are discussed in Section 4 🎀
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 💖
2. The Endpoint in the SIP and Web Architectures 🎀
okay so SIP got defined in RFC 3261 for rendezvous and session initiation, bestie 💖 The usual picture is the trapezoid model, where two endpoints sit in two different SIP service-provider domains. SIP is also super flexible, because applications beyond the rendezvous function can live either in the SIP networks (think additional feature and media servers) or in the endpoints themselves. Endpoints are our focus in this memo ✨
Ever since SIP showed up, with lots of initial similarity between SIP and HTTP, the Web has gone from a global access mechanism for static documents to a universal platform with rich interaction between the user and the client 🌈 In most cases the client is the browser, though dedicated Web desktop clients have started popping up too 💻
The Web gives access to applications as well as documents. Describing the application and network architectures of the Web is out of scope for this memo, but we'll note some new application and communication forms that emerged on the Web through a Darwinian evolution [30] rather than from being defined by standards organizations. They're called Rich Internet Applications.
Examples of RIAs include social networks, blogs, wikis, web-based office and collaboration tools, plus task apps for making to-do lists, tracking time, combining geographic info with other apps (like tracking exercise paths and recording the metrics), tracking airline flights, combining live video from events with results and comments, etc. 🙈
More info can be found at [31] and in the vast collection of books about RIAs 📚
RIAs have made the browser (and associated Web desktop apps) the dominant platform for a huge range of apps. They're universal application platforms, independent of network location, operating system, processor, or display size 🫶
Behind the better-known Web apps are tons of new technologies that can enhance SIP-based communications, for example, aggregating data at runtime from several resources on the Internet. A bunch of RIA components, like the ones on interactive Web pages, can seriously improve the user experience of SIP-based communications. That's a big contrast with the fixed interfaces in most SIP user agents (UA), like phones and desktop clients 📱
The Web network and application architecture is very different from SIP service-provider networks right now, but the one point where they both meet is the end-user device, of any shape: fixed or mobile 🧚
The desire of SIP service providers to support new services in a scalable and flexible manner is incidentally easier to implement thanks to the loose service coupling on the Web, since it's possible to characterize a service (or a mix of several service components, like in a mash-up) with a URI. That's different from network services registration being done by a central registrar. The Web architecture is also better suited for users to select and configure their applications and interaction mode with the client. The boundless variety of configurations of services and client settings on the Web contrasts with the prepackaged services and fixed user-agent configurations in present SIP services 🍓
Last but not least, program execution locally on the client is faster if the interaction with servers across the network is minimized ⚡
The motivation behind this memo is the potential of integrating SIP-based multimedia communications with access to RIAs on the Web. A few scenarios: adding SIP- and RTP-based real-time communications to RIAs, integrating (from a user perspective) the SIP location service (not to be confused with geographic location services) with other desktop- and network-based geographic location services, using social networks as part of the contact list, etc. 🦋
2.1. The Telephony Gateway as a SIP Endpoint
In order to get interoperability with the installed base of telephone networks of various kinds, integrating SIP communications into RIAs precludes, in our opinion, carrying legacy telephony features over to the Web. Interoperability between the Internet and telephone networks is best left to gateways that look to the Web as special endpoints serving large numbers of users. Plain one-to-one phone calls are already supported by Internet-to-telephony gateways. If added, PSTN (Public Switched Telephone Network) or ISDN telephony features must be exposed to Web users; visual Web display and interaction with the user is preferable to carrying the extremely complex SIP equivalents over into the Internet. On the Internet side of telephony gateways, simple SIP is all that needs to be deployed, in our opinion. Additional telephony features can be just another RIA hosted in the gateway. The market is the best indicator to show if such an effort is worthwhile to be productized 💅
Overloading simple SIP with telephony features is a non-objective, as detailed in Section 3. 😤
3. Applicability for Simple SIP in the Endpoints 🔥
This section clarifies the scope of applicability by looking at what can be done better in the endpoints, what simple SIP for user agents can and cannot accomplish, and what's out of scope. We'll use emergency calls as the example to illustrate these points on applicability. Emergency calls are also a great example for considering if and when SIP-plus-RIA applications could be used as emergency telephony enhancements or even replacements 🚑
3.1. What Simple SIP Can Accomplish
The main goal for SIP applications on the desktop or in the browser is to support the integration of SIP- and RTP-based real-time communications with RIAs. This assumes powerful endpoints, such as PC/laptop, smart mobile phones, or various dedicated devices 💪
Example of better functionality: emergency calls not limited to a Public Safety Access Point (PSAP), but extended to a medical service taking care of patients or elderly people 🏥
In this example, besides alerting the right medical provider of the emergency, vital body-sign data and video can also be transmitted. In the opposite direction, the caller may get visual and audio information and instructions for instant self-help. In this scenario, there is no need to invoke a PSAP service. A dedicated device for such scenarios may actually have an emergency medical call button, though for telephone calls to a PSAP this is not recommended [14]. Powerful endpoints may also have various means to determine the geographic location of the caller and transmit it to the emergency care provider. In this and other examples, SIP voice may be a component of several other communications means, but not always the central one; some emergency communications and data transfer may actually be performed without voice, such as instances when the "caller" cannot speak for some reason 🆘
3.2. Baseline for Simple SIP
The focus of the memo is to define the baseline for simple SIP: the establishment of a one-to-one real-time multimedia communication session for presence, IM, voice, and video. Adequate security must also be provided; authentication and encryption for the media and for parts of the signaling should be done in a manner consistent with the routing of SIP messages 🔐
3.3. What Simple SIP May or May Not Accomplish
There are border cases where simple SIP may or may not accomplish some necessary legacy function. Example: an emergency call to a PSAP over the Internet may be supported using the SOS URN [15] and the LoST protocol [16] to determine where to route the call. If, however, emergency calls must be routed over the PSTN to a country-specific telephone number, the assistance of a SIP proxy and also of a SIP-PSTN gateway is required to recognize and route the emergency call. Depending on the local jurisdiction, emergency calls from a SIP UA may require other features that are beyond the scope of this memo 🌍
3.4. What Is Out of Scope for Simple SIP
The simple usage of SIP is applicable when avoiding the traditional voice-provider approaches for charging (or monetizing) that aim to provide, manage, and charge for what is referred to as services (not applications). Some examples of such charging approaches are listed here. Simple SIP means avoiding placing any functions in the network other than the rendezvous function of SIP. This includes avoiding:
- support of legacy telephony functions, such as emulating public-telephone-switch services and voice-only private branch exchanges.
- SIP network architectures designed to support telephony-type network models. Examples include long chains of SIP proxies and feature servers (more than the two SIP servers shown in RFC 3261) that may be encountered inside and between closed Voice over IP (VoIP) networks and in-transit VoIP networks in between. Long chains of intermediaries of any type not only add complexity, they pose a security risk that increases with the number of SIP network elements. Complex server-based networks also make it more difficult to introduce new services. A special problem in SIP server chains is forking, which leads to the well-known problems of concurrency in computing; the so-called race conditions in telephony. This is amplified by redesigning the whole network every time there is a new SIP routing requirement.
Long chains of intermediaries = more security risk, the more SIP network elements there are 🚨
- support for legacy telephony models, such as identifying end-user devices for the purpose of differentiated charging by type of service or for charging for roaming between networks.
- policies and the associated policy servers and network elements for Quality of Service (QoS) to enforce service-rate-specific policies for real-time communications.
- design considerations for SIP for compatibility with legacy telephony networks, traditional telephony services, and various telephone numbering plans. This pushes the responsibility of mapping the URI to telephone numbers to edge networks where the IP-PSTN gateway functions are performed. The handling of telephony-specific functions, such as early media, are also pushed to edge gateway networks. Other design considerations for interworking with the PSTN and 'looking like the PSTN' are also avoided.
This list is not exhaustive, but it conveys the concept of what to avoid when using SIP as a simpler protocol to understand and to implement 🧚♀️
3.5. Borderline Cases
okay so there are some lowkey interesting borderline cases about what to avoid 👀 like Provisional Response Acknowledgements (PRACKs), which are specced in RFC 3262 🎀. PRACK is aimed at multi-hop SIP server networks and PSTN interworking, especially for making early media reliable 🫶. PRACK can be delegated, albeit with some limitations, to the SIP-PSTN gateway ✨. But ngl, PRACK does little to improve the user experience and has no relevance on true broadband networks with minimal SIP hop counts 🙈. So using PRACK may honestly be a decision best left to designers 💅.
Another borderline case is the issues with SIP's Non-Invite transactions, as discussed in RFC 4320 [17] 😭. Long chains of SIP intermediaries complicate the handling of provisional responses and can cause problems like storms of late responses from forked SIP forwarding paths 💀. We already said long chains of SIP intermediaries are out of scope for simple SIP, but designers may run into all kinds of scenarios (even ones they don't like), so the decision to conform the user agent (UA) to RFC 4320 is best left to them 🦋.
The list of borderline cases isn't exhaustive either, and the above are only examples. So where IS the borderline? We believe that SIP usage on the Internet, without any intermediaries designed to support closed VoIP networks, eliminates the borderline cases ✨. Enterprise SIP networks are also most useful when designed with the Internet model in mind, giving enterprise users the benefit of SIP-enhanced Web applications for productivity 💼. Handling of SIP in enterprise firewalls is out of the scope of this memo 🙅.
4. Mandatory SIP References for Internet-Centric Usage
Here's the minimal set of mandatory references to support the Internet-centric approach to SIP we outlined above 📚. The minimal set of references is what defines simple SIP 🫶.
The proposed change process [29] for SIP in the IETF RAI area will define the updated SIP core specification, and that will reduce even more the required SIP standards for what we're calling simple SIP here 🌈.
4.1. RFC 3261: "SIP: Session Initiation Protocol"
RFC 3261 [1] is the core specification for SIP 👑. The trapezoid model for SIP, found in RFC 3261, is only an example and a use case applicable to two service providers, featuring an outgoing SIP proxy and an incoming SIP proxy in each domain respectively 🗺️. However, SIP can also work in peer-to-peer (P2P) communications without SIP servers ✨.
4.2. RFC 4566: "SDP: Session Description Protocol"
SDP [2] is the standard format for representing media parameters, transport addresses, and other session data, irrespective of the protocol used to transport the SDP data 🧚. SIP is one of the protocols used to transport SDP data, so that multimedia communication sessions can be set up 🎀. Other Internet application protocols use SDP as well 💖.
4.3. RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)"
Though SDP can describe SIP sessions, getting a common description between two SIP endpoints takes a negotiation procedure 🤔. The endpoints have to agree on common media codecs, plus the IP addresses and ports where the media can be received 🎧. That negotiation procedure is specified in RFC 3264 [3] 📖. As we'll see in Section 6, this negotiation is usually way more complicated because of NAT between the SIP endpoints 😭.
4.4. RFC 3840: "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"
A SIP UA can convey its capabilities in the Contact header field 🪪, indicating if it can support presence, IM, audio, or video, and if the device is fixed, mobile, or other, such as the endpoint being an automaton (voice mail, for example) 🤖. Which SIP methods are supported may also be indicated, as specified in RFC 3840 [4] ✨. SIP registrars (SIP servers or the P2P SIP overlay) can be informed of endpoint capabilities 🙌. Missing capabilities can be displayed for the user by, for example, graying them out or leaving out the icons 🙈.
4.5. RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Servers"
RFC 3263 [5] adds key clarifications to the base SIP specification in RFC 3261 by specifying how a SIP user agent (UA) or SIP server can determine with DNS queries not only the IP addresses of the target SIP servers, but also which SIP servers can support UDP or TCP transport, as required 🗺️. TCP may be required to support secure SIP (SIPS) using Transport Layer Security (TLS) transport, or when SIP messages are too large to fit into UDP packets without fragmentation 🔐. Successive DNS queries yield finer-grain location by providing NAPTR, SRV, and A type records 🔍. Note that finding a SIP server requires several successive DNS queries to access these records 📝.
Locating SIP servers is also required for P2P SIP when a peer node wishes to communicate with a SIP UA outside its own P2P SIP overlay network 🌸.
4.6. RFC 3265: "Session Initiation Protocol (SIP)-Specific Event Notification"
RFC 3265 [6] provides an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred 🔔. The most prominent event notifications are those used for presence, though SIP events are used for many other SIP services, some of which can be useful for simple SIP 💜.
4.7. RFC 3856: "A Presence Event Package for the Session Initiation Protocol (SIP)"
RFC 3856 [7] defines the usage of SIP as a presence protocol and makes use of the SUBSCRIBE and NOTIFY methods for presence events 👀. SIP location services already contain presence information in the form of registrations, so they can be reused to establish connectivity for subscriptions and notifications 🧠. This can enable either endpoints or servers to support rich applications based on presence ✨.
4.8. RFC 3863: "Presence Information Data Format (PIDF)"
RFC 3863 [8] defines the Presence Information Data Format (PIDF) and the media type "application/pidf+xml" to represent the XML MIME entity for PIDF 📄. PIDF is used by SIP to carry presence information 💅.
4.9. RFC 3428: "Session Initiation Protocol (SIP) Extension for Instant Messaging"
The SIP extension for IM in RFC 3428 [9] consists of the MESSAGE method (defined in RFC 3428) and is only for the pager model of IM 📟. That's based on the assumption that an IM conversation state exists in the client interface in the endpoints or in the minds of the users 🧠.
4.10. RFC 4474: "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"
RFC 4474 [10] defines (1) an identity header and (2) an identity info header for SIP requests, which carry, respectively, the signature of the issuer over parts of the SIP request and the signed identity information 🔐. The signature includes the FROM header and the identity of the sender 🪄. The associated identity info header identifies the sender of the SIP request, such as INVITE 📮. The issuer of the signature can present their certificate as well 📜. It's assumed the issuer may be the domain owner 🏠. So strong authentication is provided for SIP requests 💪. Authentication for SIP responses is not defined in this document 🙈.
4.11. RFC 3581: "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing"
RFC 3581 [11] specifies an extension to SIP called "rport", so that responses are sent back to the source IP address and port from which the request originated 🦋. This correction to RFC 3261 is helpful for NAT traversal, debugging, and support of multi-homed hosts 🌈.
4.12. Updates to SIP-Related Protocols
Several of the above are being updated to benefit from the experience of large deployments and frequent interoperability testing 🛠️. We recommend readers to constantly check for revisions 👀. One update example is "Correct Transaction Handling for 200 Responses to the Session Initiation Protocol INVITE Requests" [18] ✨. This is an update to RFC 3261, and the added security risk for misbehaving SIP UAs is handled in the forwarding SIP proxy 🛡️.
5. SIP Applications in the Endpoints
Although the present adoption of SIP is mainly due to telephony applications, its roots are in the Web, and it has initial similarity to HTTP 🌐. As a result, SIP may play other roles in adequately powerful endpoints (their number keeps increasing with Moore's law) 📈. SIP-based multimedia communications may be linked with various other applications on the Web 🕸️. Either some non-SIP application or the communication feature may be perceived as the primary usage 👑. An example is mixing SIP-based real-time communications with some Web content of high interest to the user 💖.
Examples:
- In a conversation between a consumer and the contact center, a Web conference can be invoked to present to the user buying options or help information 🛍️. This information can make use of mashups to combine real-time data from various sources on the Web ✨.
- In a social network, multimedia conversations combined with Web mashups can be invoked, thus strengthening the bond between its members 🫶.
- Conversations can be invoked while watching some events on the Web in real time 📺. However, the main beneficiary in this case may be the Web site, since the conversation can prolong the time for users watching that Web site 😏.
This shows the value of combining RIAs with SIP-based communications 💫.
It is a matter for the end user's judgment whether the Web content or the associated communication capability is more important, or if a mix of both is most attractive 🤷.
Example: a Web-based enterprise directory where employees can find a wealth of data 📇. Adding SIP multimedia communications to the enterprise directory to call someone (if online and not too busy) enhances its usefulness, but is not critical to the directory 📞.
SIP applications in the endpoints can, however, accomplish most telephony functions as well 📱. This has been amply documented in SIP-related work in the IETF, such as:
- "A Call Control and Multi-party usage framework for SIP" [19] presents a large assortment of telephony applications where the call control resides in the participating endpoints that use the peer-to-peer feature invocation model 🧩. The peer-to-peer design and its principles are based on multiparty call control 🎯.
- "Session Initiation Protocol Service Examples" [20] contains a collection of SIP call flows for traditional telephony, many of which require no server support for the respective features 📞. The SIP service examples for telephony are extremely useful since they illustrate in detail the concepts and applications supported by the core simple SIP references 🎀.
In conclusion, SIP applications in the endpoints can support both a mix of real-time communications with new rich Internet applications and traditional telephony features as well 🌈✨
6. NAT Traversal ✨
Okay bestie, SIP devices sitting behind one or more NATs? At this point that's literally the norm, not the exception 💀🫶
"Best Current Practices for NAT Traversal for SIP" [22] is the big one. It sums up STUN, TURN, and ICE and gives a definitive set of 'Best Common Practices' for getting SIP and its RTP media packets through NAT devices 🔥
ICE was mainly built for SIP. Other ideas have been floated too, like NICE (generic, for non-SIP stuff) and "D-ICE" for Real Time Streaming Protocol (RTSP) streaming media 🌈. Internet games have their own NAT traversal tricks as well 🎮. This list isn't exhaustive, and each of these approaches uses its own NAT traversal protocols for each application protocol, separately 💅
So a general approach to NAT traversal that isn't tied to one application protocol is highly desirable 😭✨
One approach that's generic and works for all application protocols is to deploy the Host Identity Protocol (HIP) and solve NAT traversal only once, at the HIP level 🦋. HIP has lots of other cool features, like support for the IPv6 transition in endpoints, mobility, and multihoming, but those are beyond the scope of this paper 🧚. "Basic HIP Extensions for Traversal of Network Address Translators" [23] covers using HIP for NAT traversal in depth 📚
Using HIP-enabled endpoints can provide the functions required for NAT traversal [24] for all applications, for both IPv4 and IPv6 🌸. HIP can simplify the SIP UA because it takes the burden of NAT traversal off the SIP UA and hands it to the HIP protocol module in the endpoint. Main character energy, honestly 👑
7. Security Considerations 🔐
Okay, security time, and this part is SERIOUS 😤. All protocols discussed in this paper have their own specific security requirements that MUST be considered. The special security considerations for SIP signaling security and RTP media security are discussed here 💜
SIP security has two main parts: transport security and identity ✨
- Transport security for SIP is specified in RFC 3261. Secure SIP has the notation SIPS in the request URI and uses TLS over TCP. Note that SIP over UDP cannot be secured in this way. Transport security works only hop by hop. Specifying SIPS requires the user to trust all intermediate servers, and no end-to-end media encryption is assumed. There is no insurance for misbehaving intermediaries in the path. SIPS is therefore really adequate only in single-hop scenarios 🙈
- RFC 4474, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", which is mentioned previously, specifies the use of certificates for secure identification of the parties involved in SIP signaling requests 🎀
- The Datagram Transport Layer Security (DTLS) specified in RFC 4347 [25] has wide applicability for other applications that require UDP transport. DTLS was designed to have maximum commonality with TLS, yet it does not require TCP transport and works over UDP 🦋 The DTLS-SRTP (Secure Realtime Transport Protocol) Framework [26] can support encrypted communications between endpoints using self-signed certificates whose fingerprints are exchanged over an integrity-protected SIP signaling channel. The SRTP master secret is derived using the DTLS exchange as described in [27] 🔥
- ZRTP [28] provides key agreement for SRTP for multimedia communication with voice without depending on SIP signaling, though it can utilize an integrity-protected SIP signaling path for authentication. ZRTP does not require the use of certificates or any Public Key Infrastructure (PKI). ZRTP provides best-effort SRTP encryption without any additional SIP extensions 🌈
⚠️ Bestie, the big takeaway: SIPS only covers hop-by-hop, so trusting every middle server is a real thing you have to think about 💀
8. Acknowledgements 🫶
The authors would like to thank Cullen Jennings, Ralph Droms, and Adrian Farrel for helpful comments in the most recent stage of this memo 💖
Special thanks are due to Paul Kyzivat for challenging the authors to clarify the role of telephony network gateways, and also to Keith Drage for challenging them to discuss the use of emergency calls using simple SIP 👑
Robert Sparks has pointed to some missing references, which we have added 📚
The authors would also like to thank Jiri Kuthan, Adrian Georgescu, and others for the detailed discussion on the SIPPING WG list. As a result, we have added clarification of what simple SIP can do, what it does not aim to do, and some scenarios in between 🧚 The authors would also like to thank Wilhelm Wimmreuter for the detailed review of the initial draft, and Arjun Roychaudhury for the comments regarding the need to clarify the difference between network-based services and endpoint applications 🌸
9. References 📚
9.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] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[7] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[9] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[10] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[11] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing", RFC
3581, August 2003.9.2. Informative References
[12] Rosenberg, J., "A Hitchhiker's Guide to the Session Initiation
Protocol (SIP)", RFC 5411, February 2009.
[13] Ohlmeier, N., "VoIP RFC Watch", http://rfc3261.net/.
[14] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Work
in Progress, July 2009.
[15] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008.
[16] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig,
"LoST: A Location-to-Service Translation Protocol", RFC 5222,
August 2008.
[17] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Transaction",
RFC 4320, January 2006.
[18] Sparks, R. and T. Zourzouvillys, "Correct Transaction Handling
for 200 Responses to Session Initiation Protocol INVITE
Requests", Work in Progress, July 2009.
[19] Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A.
Johnson, "A Call Control and Multi-party usage framework for
the Session Initiation Protocol (SIP)", Work in Progress, March
2009.
[20] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service Examples", BCP
144, RFC 5359, October 2008.
[22] Boulton, C., Rosenberg, J., Camarillo, G. and F. Audet, "Best
Current Practices for NAT Traversal for Client-Server SIP",
Work in Progress, September 2008.
[23] Komu, M., Henderson, T., Tschofenig, H., Melen, J. and A.
Keraenen, "Basic HIP Extensions for Traversal of Network
Address Translators", Work in Progress, June 2009.
[24] Moskowitz, R., "HIP Experimentation using Teredo", July 2008,
http://www.ietf.org/proceedings/08jul/slides/HIPRG-3.pdf.
[25] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[26] Fischl, J., Tschofenig, H. and E. Rescorla, "Framework for
Establishing an SRTP Security Context using DTLS", Work in
Progress, March 2009.
[27] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security
(DTLS) Extension to Establish Keys for Secure Real-time
Transport Protocol (SRTP)", Work in Progress, February 2009.
[28] Zimmerman, P., Johnston, A. and J. Callas, "ZRTP: Media Path
Key Agreement for Secure RTP", Work in Progress, March 2009
[29] Peterson, J., Jennings, C. and R. Sparks, "Change Process for
the Session Initiation Protocol (SIP)", Work in Progress, July
2009.
[30] Raman, T.V., "Toward 2 exp(W), Beyond Web 2.0", Communications
of the ACM, Vol. 52, No.2, p. 52-59, February 2009.
[31] Wikipedia, "Rich Internet application",
http://en.wikipedia.org/wiki/Rich_Internet_Applications.Authors' Addresses 💌
Henry Sinnreich
Adobe Systems, Inc.
601 Townsend Street,
San Francisco, CA 94103, USA
EMail: henrys@adobe.com
Alan Johnston
Avaya
Saint Louis, MO, USA
EMail: alan@sipstation.com
Eunsoo Shim
Avaya Labs Research
233 Mount Airy Road
Basking Ridge, NJ 07920 USA
EMail: eunsooshim@gmail.com
Kundan Singh
Columbia University Alumni
1214 Amsterdam Ave., MC0401
New York, NY, USA
EMail: kns10@cs.columbia.eduThat's the whole RFC, bestie! 🌈💖 You made it through every single section 🎀
📦 where this page comes from
- ietf: rfc5638 2009-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms