RFC 3581

An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

📅 published August 2003, from ietf

RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing 🎀

Okay bestie, first the basics 💅 This is RFC 3581, and it comes from the Network Working Group. The authors are J. Rosenberg (dynamicsoft) and H. Schulzrinne (Columbia University). It's a Standards Track document dated August 2003, and the header doesn't list anything it obsoletes or updates, so it's a standalone glow-up ✨

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🌸

SIP (the Session Initiation Protocol) runs over UDP and TCP, among others 🦋 When it's used with UDP, responses to requests go back to the source address the request came from, and to the port written into the topmost Via header field value of the request. That's not ideal in lots of situations, most notably when the client is stuck behind a Network Address Translator (NAT) 🙈 This extension adds a new parameter for the Via header field called "rport". It lets a client ask the server to send the response back to the source IP address and port the request came from. Iconic 👑

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . . .  3
4.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . . .  4
5.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
9.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . .  6
    9.1.  Problem Definition . . . . . . . . . . . . . . . . . . .  8
    9.2.  Exit Strategy  . . . . . . . . . . . . . . . . . . . . .  8
    9.3.  Brittleness Introduced by this Specification . . . . . .  9
    9.4.  Requirements for a Long Term Solution  . . . . . . . . . 10
    9.5.  Issues with Existing NAPT Boxes  . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    11.1. Normative References . . . . . . . . . . . . . . . . . . 11
    11.2. Informative References . . . . . . . . . . . . . . . . . 11
12. Intellectual Property and Copyright Statements . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. Introduction ✨

SIP [1] runs over UDP and TCP 💅 With UDP, responses to requests get sent to the source address the request came from, and to the port written into the topmost Via header field value of the request. That makes it a "hybrid" way of working out where a response goes. Half the info (the IP address) comes from the IP packet headers, and the other half (the port) comes from the SIP message headers. SIP is set up this way so a server can listen for all messages, both requests and responses, on one IP address and one port, which helps with scalability 📈 Still, it isn't great in many cases, most notably when the client is behind a NAT. Then the response won't traverse the NAT properly, because it won't match the binding that was made with the request 😭

Also, right now there's no way for a client to look at a response and find out which source port the server saw in the matching request. SIP gives the client the source IP address the server saw, but not the port. That address goes in the "received" parameter of the topmost Via header field value of the response. It's been handy for basic NAT traversal, debugging, and supporting multi-homed hosts, but it's incomplete without the port 🫠

So this extension adds a new Via header field parameter called "rport". It lets a client ask the server to send the response back to the source IP address and port the request came from. rport is basically the sibling of received, except it holds a port number instead of an IP address 🧚

2. Terminology 📖

Here's the vibe check on the key words 💅 In this doc, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" get read as described in BCP 14, RFC 2119 [2]. They show the requirement levels for compliant implementations, so pay attention to them 🎀

3. Client Behavior 💜

The client behavior here affects the transport processing defined in Section 18.1 of SIP (RFC 3261) [1].

A client that follows this spec (clients include UACs and proxies) MAY include an "rport" parameter in the top Via header field value of requests it generates. This parameter MUST have no value. It's a flag that tells the server this extension is supported and requested for the transaction 🚩

When the client sends the request over UDP, the client MUST be prepared to receive the response on the same IP address and port it used to fill in the source IP address and source port of the request 🦋 For backwards compatibility, the client MUST still be prepared to receive a response on the port indicated in the sent-by field of the topmost Via header field value, as specified in Section 18.1.1 of SIP [1].

When there's a NAT between the client and server, the request creates (or refreshes) a binding in the NAT. This binding must remain in existence for the duration of the transaction, or the client won't get the response 😭 Most UDP NAT bindings seem to time out after about one minute. That's longer than non-INVITE transactions last, so responses to a non-INVITE request will arrive while the binding is still alive. INVITE transactions can take an arbitrarily long time to finish, though, so the binding may expire before a final response shows up 🙈 To keep the binding fresh, the client SHOULD retransmit its INVITE every 20 seconds or so. Those retransmissions will need to keep going even after a provisional response comes back 🌈

A UA MAY run the binding lifetime discovery algorithm in Section 10.2 of RFC 3489 [4] to figure out the actual binding lifetime in the NAT. If the lifetime is longer than 1 minute, the client SHOULD increase the interval for request retransmissions, up to half of the discovered lifetime. If it's shorter than one minute, it SHOULD decrease the interval for request retransmissions to half of the discovered lifetime. Heads up that discovering binding lifetimes can be unreliable, so see Section 14.3 of RFC 3489 [4] 💀

4. Server Behavior 🍓

The server behavior here affects the transport processing defined in Section 18.2 of SIP [1].

When a server that follows this spec (which can be a proxy or UAS) receives a request, it checks the topmost Via header field value. If that value has an "rport" parameter with no value, the server MUST set the value of the parameter to the source port of the request. This is analogous to how a server inserts the "received" parameter into the topmost Via header field value. In fact, the server MUST insert a "received" parameter containing the source IP address the request came from, even if it's identical to the value of the "sent-by" component. Note that this processing happens regardless of transport protocol 🫶

When a server tries to send a response, it checks the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and to the port in the "rport" parameter. The response MUST be sent from the same address and port that the corresponding request was received on. This effectively adds a new processing step between bullets two and three in Section 18.2.2 of SIP [1] ✨

The response must be sent from the same address and port that the request was received on, so it can traverse symmetric NATs 🔥 When a server is listening for requests on multiple ports or interfaces, it will need to remember the one the request came in on. For a stateful proxy, storing that info for the duration of the transaction is no big deal 💅 A stateless proxy, though, doesn't store state between a request and its response, so it can't remember the address and port a request arrived on. To properly implement this spec, a stateless proxy can encode the destination address and port of a request into the Via header field value it inserts. When the response arrives, it can extract that info and use it to forward the response 🧚

5. Syntax 🎀

The syntax for the "rport" parameter is:

response-port = "rport" [EQUAL 1*DIGIT]

This extends the existing definition of the Via header field parameters, so the BNF now looks like this:

via-params        =  via-ttl / via-maddr
                     / via-received / via-branch
                     / response-port / via-extension

6. Example ✨

okay so let's walk through a full example bc it's so satisfying 🦋 a client sends an INVITE to a proxy server that looks like this (well, the important bits anyway):

INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff

this INVITE goes out with a source port of 4540 and a source IP address of 10.1.1.1. the proxy lives at 192.0.2.2 (proxy.example.com) and it's listening on BOTH port 5060 and port 5070 👀 the client sends the request to port 5060. then the request hits a NAT on the way to the proxy, so the source IP now shows up as 192.0.2.1 and the source port shows up as 9988. the NAT is basically rewriting the sender's info 🙈 the proxy forwards the request, but not before it adds a value to the "rport" parameter in the proxied request:

INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
 ;branch=z9hG4bKkjshdyff

this request makes a response, and the response shows up back at the proxy:

SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
 ;branch=z9hG4bKkjshdyff

the proxy strips off its own top Via header field value, then checks the next one 💅 and that one has BOTH a "received" parameter and an "rport" parameter. so the server follows the rules in Section 4 and sends the response to IP address 192.0.2.1, port 9988, sending it from port 5060 on 192.0.2.2:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
 ;branch=z9hG4bKkjshdyff

this packet matches the binding that the first request made, so the NAT rewrites the destination address back to 10.1.1.1 and the destination port back to 4540. then it forwards the response to the client, which is listening for it on that address and port. and the client gets it properly 😭🎀 iconic, honestly.

7. Security Considerations 🔒

okay bestie, this part is serious so read it with me 🫶 when a server uses this spec, the responses it sends will now include the source port where the request came from. and sometimes the source address and port of a request is sensitive info. if it IS sensitive, requests SHOULD be protected by using SIP over TLS [1]. in that case this spec doesn't give you any response routing functions (those only work with TCP), it just gives the client info about the source port as the server saw it.

now the scary-ish part 💀 someone could try to mess with a client's service by being a man-in-the-middle and changing the "rport" parameter in a Via header of a request the client sent. removing that parameter stops clients behind NATs from getting service. adding it usually has no impact. but if an attacker can pull off a man-in-the-middle attack, they have a zillion other ways to deny service anyway, like just dropping the request. so tbh this attack doesn't seem significant 💅

8. IANA Considerations 📋

there are no IANA considerations associated with this specification ✨ nothing to register, nothing to update, we're chillin 🌸

9. IAB Considerations 🧚

the IAB has studied a class of protocols called Unilateral Self Address Fixing (UNSAF) protocols [5]. these let a client behind a NAT learn the IP address and port that a NAT will allocate for a particular request, so it can use that info in application layer protocols. an example of an UNSAF protocol is Simple Traversal of UDP Through NATs (STUN) [4].

any protocol is an UNSAF protocol if it reveals, to a client, the source IP address and port of a packet sent through that NAT. this spec wasn't designed for that purpose, but it CAN be used as an UNSAF protocol 👀 using the "rport" parameter (defined here) and the "received" parameter (defined in RFC 3261 [1]) in the topmost Via header field value of a response, a client sending a request can learn its address as the server that sent the response saw it.

there are two uses for this info. the first is registrations. picture a client behind a NAT that wants to register with a proxy/registrar on the other side of the NAT. the client has to include, in its registration, the address where it should receive incoming SIP requests from the proxy. but since it's behind a NAT, none of the addresses on its interfaces are reachable from the proxy 😭 if the client gives the proxy an address the proxy CAN reach, the client can receive incoming requests. with this spec, a client behind a NAT can learn its address and port as the proxy that gets the REGISTER request sees them. then it can do an additional registration using that address in a Contact header. this lets the client receive incoming requests like INVITE on the IP address and port it used as the source of its registration. this approach only works when servers send requests to a UA from the same address and port where the REGISTER was received 💖

in lots of cases, the server you send the registration to won't be the registrar itself, but a proxy that forwards the request to the registrar. in that case, any incoming requests for the client have to go through the proxy the registration was sent to directly. the Path header extension to SIP [3] lets the proxy say that it must be on the path of those requests 🛣️

the second use is record routing, which fixes the same problem as above but between two proxies. a proxy behind a NAT that forwards a request to a server can use OPTIONS, for example, to learn its address as that server sees it. that address can go into the Record-Route header field of requests sent to that server. this lets the proxy receive requests from that server on the same IP address and port it used as the source of the OPTIONS request ✨

because of this potential usage, this doc has to consider the issues raised in [5] 🫶

9.1. Problem Definition 🎯

from [5], any UNSAF proposal must provide:

Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't".

this spec is mainly aimed at letting SIP responses be received when a request goes through a NAT. for that main job, this spec is NOT an UNSAF proposal. BUT as a side effect, it can be used as an UNSAF protocol, and in that usage it would address two issues:

  • Provide a client with an address that it could use in the Contact header of a REGISTER request when it is behind a NAT.
  • Provide a proxy with an address that it could use in a Record-Route header in a request, when it is behind a NAT.

9.2. Exit Strategy 🚪

from [5], any UNSAF proposal must provide:

Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.

the SIP working group has recognized that using this spec to support registrations and record-routing through NATs is not appropriate 🙅‍♀️ it has a bunch of known problems, documented below. the way to get rid of potential usage of this spec for address fixing is to provide a proper solution to the problems that might motivate using it for address fixing. specifically, good solutions for registrations and record-routing in the presence of NATs need to be developed, and those solutions would not rely on address fixing.

requirements for those solutions are already under development [6] 👑

implementors of this spec are encouraged to follow that work for better solutions to registrations and record-routing through NAT 🌈

9.3. Brittleness Introduced by this Specification 🥀

from [5], any UNSAF proposal must provide:

Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.

ok so this spec, if it's used for address fixing, adds several points of brittleness into a SIP system 😬

  • If used for UDP registrations, a client will need to re-register frequently to keep the NAT bindings fresh. in many cases, these registrations will need to happen nearly one hundred times more often than the typical refresh interval of a registration. this adds load to the system and hurts scalability.
  • A client can't accurately figure out the binding lifetime of a NAT it's registering (or record-routing) through. so there may be periods of unreachability between the time a binding expires and the next registration or OPTIONS refresh gets sent. this may result in missed calls, messages, or other info 📵
  • If the NAT is of the symmetric variety [4], a client will only be able to use its address to receive requests from the server it sent the request to. if that server is one of many in a cluster, the client may not be able to receive requests from the other servers in the cluster. this may result in missed calls, messages, or other info 💔
  • If the NAT is of the symmetric variety [4], a client will only be able to use its address to receive requests if the server sends requests to the client from the same address and port that the server received the registrations on. this server behavior is not mandated by RFC 3261 [1], although it appears to be common in practice 🤷‍♀️
  • If the registrar and the server the client sent its REGISTER request to are not the same, the approach will only work if the server uses the Path header field [3]. there isn't an easy and reliable way for the server to determine that the Path header should be used for a registration. using Path when the address in the topmost Via header field is a private address will usually work, but it may result in Path being used when it isn't actually needed.

9.4. Requirements for a Long Term Solution 🌟

from [5], any UNSAF proposal must provide:

Identify requirements for longer term, sound technical solutions -- contribute to the process of finding the right longer term solution.

the brittleness described in Section 9.3 led to these requirements for a long term solution 💜

  • The client should not need to specify its address. Registrations and record routing require the client to specify the address where it should receive requests. a sound technical solution should let a client explicitly say that it wants to receive incoming requests on the connection the outgoing request was sent over. that way the client doesn't need to specify its address 🙌
  • The solution must deal with clusters of servers. in many commercially deployed SIP systems, there will be multiple servers, each at different addresses and ports, handling incoming requests for a client. the solution must explicitly consider this case 🧩
  • The solution must not require increases in network load. there can't be a penalty for a sound technical solution 🚫📉

9.5. Issues with Existing NAPT Boxes 🧚

okay so this bit is about how existing NAPT boxes (the NA[P]T ones) would deal with this. From [5], any UNSAF proposal must provide a discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts, plus experience reports 📝.

ngl, as far as the authors know right now, this spec has only very limited use for address fixing 🙈. So no specific practical issues have actually been raised yet 💅.

10. Acknowledgements ✨

the authors want to give a big thank you to Rohan Mahy and Allison Mankin for their comments and contributions to this work 🫶🎀.

11. References 📚

11.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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
  • [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.

11.2. Informative References

  • [5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
  • [6] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress.

12. Intellectual Property Statement 🔐

the IETF doesn't take a position on whether any intellectual property or other rights that someone might claim over the technology in this document are valid or in scope, or on whether a license under those rights would or wouldn't be available 🤷‍♀️. It also doesn't say it has tried to find any of those rights. If you want the IETF's procedures for rights in standards-track and standards-related documents, check out BCP-11 📖. Copies of rights claims that were made available for publication, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights, can be obtained from the IETF Secretariat 💼.

the IETF also invites any interested party to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology required to practice this standard 👀. Send that info to the IETF Executive Director 💌.

13. Authors' Addresses 📮

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ  07054
US

Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI:   http://www.jdrosen.net


Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY  10027
US

EMail: schulzrinne@cs.columbia.edu
URI:   http://www.cs.columbia.edu/~hgs

Copyright (C) The Internet Society (2003). All Rights Reserved. 🌈

okay so this document, and translations of it, can be copied and shared with others 💜. Derivative works that comment on or explain it, or help with implementing it, can be made, copied, published, and distributed, in whole or in part, with no restrictions of any kind. The only catch is that the copyright notice and this paragraph have to be included on all those copies and derivative works 📋. However, this document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed), or when it's translated into languages other than English 🌍.

The permissions above are limited, but they're perpetual, and the Internet Society or its successors or assignees won't revoke them ♾️.

This document and the information in it are 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