TCP-Based Media Transport in the Session Description Protocol (SDP)
updated by
- rfc-4572 — Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
Extracted elements (24)
Documents defining new SDP protocol identifiers that layer additional protocols over TCP (e.g., TLS over TCP) are recommended to use the string 'TCP/' as a prefix (e.g., 'TCP/TLS'), and to reuse the 'setup' and 'connection' attributes where applicable.
Offerers using 'connection:existing' may choose 'setup:holdconn' to avoid allocating resources for a potential incoming connection that may never arrive, though this requires an additional offer/answer round if the answerer demands a new connection.
The 'connection' attribute was introduced because after the initial session is established, subsequent SDP exchanges could ambiguously represent either a request to continue the existing TCP connection or to create a new one; the attribute explicitly resolves this ambiguity.
In third-party call control scenarios, an endpoint may receive an initial offer with a connection value of 'existing' even though no prior connection exists; following the rules, such an answerer must use a value of 'new' in the answer.
When the connection value resulting from an offer/answer exchange is 'existing', the port numbers, IP addresses, and 'setup' attributes negotiated are ignored because no new connection needs to be established.
An endpoint that is supposed to initiate a new TCP connection SHOULD do so as soon as it is able, even before it intends to send media, to allow media to flow from the remote endpoint if needed.
As soon as an endpoint notices that it needs to terminate a TCP connection, it SHOULD do so. Endpoints typically do not close until session expiry, explicit termination, or a new connection value is provided.
If an endpoint determines that a TCP connection for an 'm' line has been closed and should be reestablished, it SHOULD perform a new offer/answer exchange with a connection value of 'new' for that 'm' line.
If an offerer wants to continue using the previously-established TCP connection, it MUST use a connection value of 'existing'. If it wants a new connection, it MUST use a connection value of 'new'.
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 resulting from an offer/answer exchange is 'new', endpoints SHOULD establish a new TCP connection and SHOULD close any previous TCP connection as soon as the exchange is completed.
The active endpoint SHOULD initiate a connection to the port on the other endpoint's 'm' line. The active endpoint SHOULD specify port 9 (discard port) on its own 'm' line and MUST NOT specify port zero except to refuse a stream.
The opposite endpoint MUST NOT attempt to initiate a connection to the port number on the active endpoint's 'm' line, since that port is irrelevant for the active role.
When an offerer generates an 'm' line using TCP, it SHOULD provide a 'connection' attribute for that 'm' line unless the application has other means to handle connection reestablishment.
The 'connection' attribute is a media-level, charset-independent attribute that disambiguates whether a subsequent SDP exchange requests a new TCP connection or continuation of the existing one. Its ABNF is: connection-attr = 'a=connection:' conn-value, where conn-value = 'new' / 'existing'.
The 'setup' attribute indicates which endpoint should initiate the TCP connection (send the initial SYN). It takes one of four values: 'active' (initiates), 'passive' (accepts), 'actpass' (willing to do either), or 'holdconn' (connection not to be established).
The 'TCP' protocol identifier is defined for use in the SDP 'm' line proto field to indicate TCP-based media transport. An 'm' line specifying 'TCP' must further qualify the application-layer protocol using a fmt identifier.
This document registers a new proto value 'TCP' under the IANA 'Session Description Protocol (SDP) Parameters' registry under 'proto'. New TCP format (fmt) values SHOULD have an associated MIME registration.
This document registers two session- and media-level SDP attributes ('setup' and 'connection') under the IANA 'Session Description Protocol (SDP) Parameters' registry, att-field (both session and media level).
An attacker may attempt to modify the values of the 'connection' and 'setup' attributes to cause endpoints to reestablish connections unnecessarily or prevent connection establishment. Integrity protection (e.g., S/MIME for SDP carried in SIP) is strongly RECOMMENDED for SDP session descriptions.
The offer/answer negotiation for 'connection' follows: offer 'new' → answer must be 'new'; offer 'existing' → answer may be 'existing' or 'new'. The resulting connection value is the value in the answer.
The offer/answer negotiation for 'setup' follows a defined compatibility table: offer 'active' → answer must be 'passive' or 'holdconn'; offer 'passive' → answer must be 'active' or 'holdconn'; offer 'actpass' → answer may be 'active', 'passive', or 'holdconn'; offer 'holdconn' → answer must be 'holdconn'. Default is 'active' in offer and 'passive' in answer.
The 'connection' attribute ABNF is: connection-attr = 'a=connection:' conn-value, where conn-value = 'new' / 'existing'. The default value in both offers and answers is 'new'.
The 'setup' attribute ABNF is: setup-attr = 'a=setup:' role, where role = 'active' / 'passive' / 'actpass' / 'holdconn'. It is charset-independent and may appear at session or media level.