RFC 4145
TCP-Based Media Transport in the Session Description Protocol (SDP)
RFC 4145 · Part 1 of 3 🎀
the title block, bestie 📋
- RFC: 4145
- Title: TCP-Based Media Transport in the Session Description Protocol (SDP)
- Authors: D. Yon (Tactical Software, LLC) and G. Camarillo (Ericsson)
- Category: Standards Track
- Date: September 2005
- Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates, so nothing to see there 💅
Status of This Memo ✨
okay so this one is an Internet standards track protocol document for the Internet community 🫶 it's asking for discussion and suggestions for improvements, so bring your ideas. for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). and distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice 🦋
Copyright (C) The Internet Society (2005).
Abstract 💜
this doc is all about how to describe media transport over TCP using the Session Description Protocol (SDP). it defines the SDP 'TCP' protocol identifier 🎀, plus two attributes. the 'setup' attribute describes the connection setup procedure, and the 'connection' attribute handles connection reestablishment. two new tools, both slay ✨
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 3
4. Setup Attribute . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. The Setup Attribute in the Offer/Answer Model. . . . . . 4
5. The Connection Attribute . . . . . . . . . . . . . . . . . . . 5
5.1. Offerer Behaviour. . . . . . . . . . . . . . . . . . . . 6
5.2. Answerer Behaviour . . . . . . . . . . . . . . . . . . . 7
6. Connection Management . . . . . . . . . . . . . . . . . . . . 8
6.1. Connection Establishment . . . . . . . . . . . . . . . . 8
6.2. Connection Reestablishment . . . . . . . . . . . . . . . 8
6.3. Connection Termination . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Passive/Active . . . . . . . . . . . . . . . . . . . . . 9
7.2. Actpass/Passive. . . . . . . . . . . . . . . . . . . . . 9
7.3. Existing Connection Reuse. . . . . . . . . . . . . . . . 10
7.4. Existing Connection Refusal. . . . . . . . . . . . . . . 10
8. Other Connection-Oriented Transport Protocols. . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 131. Introduction 🧚
so SDP gives you a general-purpose format for describing multimedia sessions, whether they're in announcements or invitations 📣 it's entirely textual, using the US-ASCII subset of UTF-8 [11], which keeps it portable across transports. SDP doesn't define a protocol, though. it defines the syntax for describing a multimedia session with enough info to actually join it 🎧 session descriptions can travel over basically any existing application protocol, like SAP [9], SIP [10], RTSP [6], email, HTTP [8], etc.
SDP [4] defines two protocol identifiers, RTP/AVP and UDP. both are unreliable and connectionless. those are great for media streams, but some apps need TCP more ✨ so this doc adds a brand new protocol identifier, 'TCP', to describe TCP connections in SDP.
TCP brings two new questions when you describe a session: how and when should the endpoints do the TCP connection setup procedure? 🤔 this document answers that with two new attributes, 'setup' and 'connection'.
2. Terminology 📖
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3], and they indicate requirement levels for compliant implementations. these are the official requirement words, so pay attention to them 💅
3. Protocol Identifier 🎀
here's the ABNF for an 'm' line, as specified by RFC 2327 [4]:
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLFthis doc adds a new value for the proto field: 'TCP' 🌸
the 'TCP' protocol identifier is kind of like 'UDP' because it only describes the transport protocol, not the upper-layer protocol. an 'm' line that specifies 'TCP' MUST further qualify the application-layer protocol using an fmt identifier. media described with a 'TCP' 'm' line gets carried over TCP [1] 🦋
4. Setup Attribute 💜
the 'setup' attribute tells you which endpoint should start the TCP connection establishment (aka send the initial TCP SYN) 🔥 it's charset-independent, and it can be a session-level or a media-level attribute. here's the ABNF:
setup-attr = "a=setup:" role
role = "active" / "passive" / "actpass"
/ "holdconn"here's what each role means:
- 'active': the endpoint will start an outgoing connection.
- 'passive': the endpoint will take an incoming connection.
- 'actpass': the endpoint is down to accept an incoming connection or to start an outgoing one. it's flexible 🫶
- 'holdconn': the endpoint doesn't want the connection established for now. 🙈
4.1. The Setup Attribute in the Offer/Answer Model 🍓
the offer/answer model, defined in RFC 3264 [5], gives endpoints a shared view of a session 👑 some session params get negotiated, like which codecs to use, and others are just passed from one endpoint to the other, like IP addresses. the 'setup' value falls into the negotiated group. both endpoints negotiate it using offer/answer, so it's a team effort 🤝
here's how it goes down. the offerer says which role or roles it's willing to play. then the answerer, taking that willingness into account, picks which roles both endpoints actually perform during connection establishment. these are the values 'setup' can take in an offer/answer exchange:
Offer Answer
________________
active passive / holdconn
passive active / holdconn
actpass active / passive / holdconn
holdconn holdconnthe active endpoint SHOULD initiate a connection to the port number on the 'm' line of the other endpoint. the port number on its own 'm' line doesn't matter, and the opposite endpoint MUST NOT try to initiate a connection to the port number written there. 🙃 but since the 'm' line still needs a valid port number, the endpoint using 'active' SHOULD put port 9 (the discard port) on its 'm' line. the endpoint MUST NOT specify port zero, unless it's denoting an 'm' line that has been or is being refused 🚫
the passive endpoint SHOULD be ready to accept a connection on the port number in its 'm' line. 🎧
'actpass' means the offerer can either initiate a connection to the port number on the answer's 'm' line, or accept one on the port in its own offer 'm' line. basically the offerer has no preference about whether it accepts or initiates, so it's letting the answerer decide 💅
'holdconn' means the connection shouldn't be established for the time being 😌
the default 'setup' value in an offer/answer exchange is 'active' in the offer and 'passive' in the answer 🌈
5. The Connection Attribute 🦋
everything above about 'setup' assumes you're using SDP to start a session. but SDP can get exchanged at different stages of a session too, for stuff like ending a session, redirecting media to a new endpoint, or renegotiating media params ✨ and after the initial session is up, it can be unclear whether a later SDP exchange means "yep, keep using the current TCP connection unchanged," or "hey, make a brand new TCP connection." 😭 that's where the media-level 'connection' attribute comes in. it's charset-independent, and it clears up exactly that confusion. here's its ABNF:
connection-attr = "a=connection:" conn-value
conn-value = "new" / "existing"5.1. Offerer Behaviour 💖
Okay so offerers and answerers use the connection attribute to figure out whether a brand new transport connection needs to be set up or whether the existing TCP connection should still be used 🦋. When an offerer generates an m line that uses TCP, it SHOULD provide a connection attribute for that m line, unless the application using the m line has other ways to deal with reestablishing the connection ✨.
After the first offer/answer exchange, either endpoint can send a new offer to change some stuff about the session, like the direction attribute 💅. If that offerer wants to keep using the transport connection that's already up for the m line, it MUST use a connection value of existing for that m line 🫶. If the offerer wants a brand new transport connection for the m line instead, it MUST use a connection value of new 🔥.
Note that, according to the rules in this section, an offer that changes the transport address (IP address or port number) of anmline will have a connection value ofnew💀. Similarly, theconnectionattribute in an initial offer (i.e., no transport connection has been established yet) takes the value ofnew🌸.
The connection value that comes out of an offer/answer exchange is the connection value in the answer 👑. If the answer says new, the endpoints SHOULD establish a new connection 🧚. If the answer says existing, the endpoints SHOULD keep using the existing connection 💜.
Taking the rules in Section 5.2 into account, these are the values the connection attribute can take in an offer/answer exchange:
Offer Answer
________________
new new
existing existing / newIf the connection value that results from an offer/answer exchange is existing, the endpoints keep using the existing connection 🌈. That means the port numbers, IP addresses, and setup attributes negotiated in that exchange get ignored, because there's no need to set up a new connection 🙈.
Here's the tricky bit. An offerer that sends an offer with a connection value of existing and a setup value of passive needs to be ready (i.e., needs to allocate resources) to receive a connection request from the answerer, just in case the answerer picks a connection value of new for the answer 😭. But if the answerer uses existing in the answer, the offerer would have to deallocate the resources it set aside that never got used, because no connection request ever showed up 💀.
To avoid wasting resources, offerers using a connection value of existing in their offers may choose to use a setup value of holdconn 🍓. Still, offerers using this strategy should be aware that if the answerer chooses a connection value of new, a new offer/answer exchange (typically started by the previous offerer) with a setup value that is not holdconn will be needed to set up the new connection 🥺. This may, of course, cause delays in the application using the TCP connection 😬.
The default value of the connection attribute in both offers and answers is new ✨.
5.2. Answerer Behaviour 🎀
The connection value for an m line gets negotiated using the offer/answer model 🦋. The connection value that comes out of an offer/answer exchange is the connection value in the answer. If the connection value in the offer is new, the answerer MUST also use a value of new in the answer 💅. If the connection value in the offer is existing, the answerer uses a value of existing in the answer if it wants to keep using the existing connection, and a value of new if it wants a new connection to be set up 🫶.
In some scenarios where third party call control [12] is used, an endpoint may receive an initial offer with a connection value ofexisting. Following the previous rules, such an answerer would use a connection value ofnewin the answer 🙈.
If the connection value for an m line that comes out of an offer/answer exchange is new, the endpoints SHOULD establish a new TCP connection as indicated by the setup attribute 🌟. If a previous TCP connection is still up, the endpoints SHOULD close it as soon as the offer/answer exchange is completed 👋. It's up to the application to make sure the two TCP connections are properly data-synchronized 🧠.
If the connection value for an m line that comes out of an offer/answer exchange is existing, the endpoints SHOULD continue using the existing TCP connection 💖.
6. Connection Management 🌸
This section covers connection establishment, connection reestablishment, and connection termination 💅.
6.1. Connection Establishment 🦋
An endpoint that, according to an offer/answer exchange, is supposed to start a new TCP connection SHOULD start it as soon as it's able to, even if that endpoint doesn't plan to start sending media to the remote endpoint right away 🚀. That way, media can flow from the remote endpoint if it needs to ✨.
Note that some endpoints need to wait for some event to happen before they can set up the connection 🫠. For example, a wireless terminal may need to set up a radio bearer before it can start a TCP connection 📡.
6.2. Connection Reestablishment 🔁
If an endpoint figures out that the TCP connection for an m line has been closed and should be reestablished, it SHOULD run a new offer/answer exchange using a connection value of new for that m line 💫.
Note that the SDP direction attribute (e.g., a=sendonly) is about the media sent over the TCP connection, but it has no impact on the TCP connection itself 🙃.
6.3. Connection Termination 🌙
Typically, endpoints don't close the TCP connection until the session has expired, been explicitly terminated, or a new connection value has been given for the m line 🥱. On top of that, specific applications can describe more situations where an endpoint may close a given TCP connection (e.g., whenever a connection is in the half-close state) 🌓. As soon as an endpoint notices that it needs to terminate a TCP connection, it SHOULD do so 🏃♀️.
Individual applications may give extra thoughts on how to get a graceful connection termination 🕊️. For example, a file application using TCP that gets a FIN from the remote endpoint may need to finish sending the file it's in the middle of before it sends its own FIN 📁.
7. Examples ✨
The examples below show the most common ways to use the setup attribute with TCP-based media descriptions 💅. To keep things brief, the main part of the session description is left out, so the examples only show m lines and their attributes (including c lines) 🫶.
7.1. Passive/Active 🎀
An offerer at 192.0.2.2 says it's available for a T.38 fax session on port 54111 📠:
m=image 54111 TCP t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:newAn answerer at 192.0.2.1 that gets this offer replies with this answer 🦋:
m=image 9 TCP t38
c=IN IP4 192.0.2.1
a=setup:active
a=connection:newThen the endpoint at 192.0.2.1 starts the TCP connection to port 54111 at 192.0.2.2 🚀.
7.2. Actpass/Passive 🧚
In another example, an offerer at 192.0.2.2 says it's available for a T.38 fax session at TCP port 54111 💜. This offerer is also happy to set up the media stream by starting the TCP connection itself 🙌:
m=image 54111 TCP t38
c=IN IP4 192.0.2.2
a=setup:actpass
a=connection:newThe endpoint at 192.0.2.1 responds with this description 🌈:
m=image 54321 TCP t38
c=IN IP4 192.0.2.1
a=setup:passive
a=connection:newThis makes the offerer (at 192.0.2.2) start a connection to port 54321 at 192.0.2.1 🔥.
7.3. Existing Connection Reuse 🔄
After the exchange in Section 7.2, another offer/answer exchange starts in the opposite direction 🙃. The endpoint at 192.0.2.1 wants to keep using the existing connection 💖:
m=image 54321 TCP t38
c=IN IP4 192.0.2.1
a=setup:passive
a=connection:existingThe endpoint at 192.0.2.2 also wants to use the existing connection and replies with this description 🫶:
m=image 9 TCP t38
c=IN IP4 192.0.2.2
a=setup:active
a=connection:existingThe existing connection from 192.0.2.2 to 192.0.2.1 gets reused 🎉.
Note that the endpoint at 192.0.2.2 usessetup:activein response to the offer ofsetup:passive, and uses port 9 because it's active 🧐.
7.4. Existing Connection Refusal 🙅♀️
After the exchange in Section 7.3, the endpoint at 192.0.2.2 starts another offer/answer exchange, again wanting to reuse the existing connection 😤:
m=image 54111 TCP t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:existingBut this time the answerer doesn't know about the old connection, so it wants to set up a new one 🤯. (This could happen if the call was transferred via third-party call control 📞.) It can't act in passive mode, so it responds as active 💀:
m=image 9 TCP t38
c=IN IP4 192.0.2.3
a=setup:active
a=connection:newThe endpoint at 192.0.2.3 then starts the TCP connection to port 54111 at 192.0.2.2, and the endpoint at 192.0.2.2 closes the old connection 👋.
Note that the endpoint at 192.0.2.2, while using a connection value ofexisting, used a setup value ofpassive. If it had instead used a setup value ofholdconn(probably to avoid allocating resources as described in Section 5.1), a new offer/answer exchange would have been needed to set up the new connection 🫣.
8. Other Connection-Oriented Transport Protocols ✨
okay so this whole doc is about describing TCP-based media streams with SDP 💖 but lowkey, some of these attributes could also describe media over other connection-oriented transport protocols 🦋 this section is basically advice for anyone writing SDP extensions for transports that aren't TCP 🧚
bestie, if you're defining a new SDP protocol identifier that adds extra layers between TCP and the media (like TLS [7] over TCP), it is recommended that you start the name with the string TCP/, like TCP/TLS 🎀
the setup and connection attributes are specified in Section 4 and Section 5 respectively 🌸 they're written for m lines that use the TCP protocol identifier, but they're general enough to be reused for m lines with other connection-oriented transports 💅 so it is recommended that setup and connection get reused, as long as that's possible, for new proto values tied to connection-oriented transports ✨
Section 6 covers TCP connection management 🦋 it's worth noting that in TCP, both end-points need to close the connection, but other connection-oriented transports may not have half-close connections at all 💀 in that case, the connection gets terminated as soon as one end-point closes it, so the other end-point doesn't have to do anything else to terminate it 🫶 so specs for those transports may need slightly different connection termination procedures 🌈
9. Security Considerations 🔥
okay this section is SERIOUS, bestie 😭 see RFC 2327 [4] for security and other considerations specific to the Session Description Protocol in general 💜
an attacker could try to change the values of the connection and setup attributes 🙈 to make endpoints reestablish connections for no reason, or to stop them from ever setting up a connection at all 💀 so it is strongly RECOMMENDED that integrity protection gets applied to SDP session descriptions 🔐 for session descriptions carried in SIP [10], S/MIME is the natural choice for that end-to-end integrity protection, as described in RFC 3261 [10] ✨ other applications MAY use a different form of integrity protection 🌸
10. IANA Considerations 🎀
this document defines two session- and media-level SDP attributes, setup and connection 💖 their formats are defined in Section 4 and Section 5, respectively 🧚 these two attributes should be registered by the IANA under "Session Description Protocol (SDP) Parameters" under "att-field (both session and media level)" 🦋
this document also defines a proto value, TCP 💅 its format is defined in Section 3 ✨ this proto value should be registered by the IANA under "Session Description Protocol (SDP) Parameters" under "proto" 🌈
the SDP spec, RFC2327, says that specs defining new proto values (like the TCP one in this RFC) must define the rules for how their media format (fmt) namespace is managed 👑 for TCP, new formats SHOULD have an associated MIME registration 🫶 using an existing MIME subtype for the format is encouraged 🌸 if no MIME subtype exists, it is RECOMMENDED that a suitable one gets registered through the IETF process [2], by producing or referencing a standards-track RFC that defines the transport protocol for the format 🔥
11. Acknowledgements 🫶
huge thanks to Jonathan Rosenberg, Rohan Mahy, Anders Kristensen, Joerg Ott, Paul Kyzivat, Robert Fairlie-Cuninghame, Colin Perkins, and Christer Holmberg, who all provided valuable insights and contributions 🌟
12. References 📚
12.1. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[2] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.12.2. Informative References
[6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[9] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[10] 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.
[11] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004.Authors' Addresses 🏡
David Yon
Tactical Software, LLC
1750 Elm St., Suite 803
Manchester, NH 03104
USA
EMail: yon-comedia@rfdsoftware.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.comFull Copyright Statement ©
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧠
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc4145 2005-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms