draft-ietf-mmusic-sdp-comedia-01.txt | draft-ietf-mmusic-sdp-comedia-02.txt | |||
---|---|---|---|---|
INTERNET-DRAFT D. Yon | INTERNET-DRAFT D. Yon | |||
Document: draft-ietf-mmusic-sdp-comedia-01.txt Dialout.Net | Document: draft-ietf-mmusic-sdp-comedia-02.txt Dialout.Net | |||
Expires April 2002 October 2001 | Expires October 2002 April 2002 | |||
Connection-Oriented Media Transport in SDP | Connection-Oriented Media Transport in SDP | |||
<draft-ietf-mmusic-sdp-comedia-01.txt> | <draft-ietf-mmusic-sdp-comedia-02.txt> | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at line 30 | skipping to change at line 30 | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet-Drafts as reference | at any time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at: | The list of current Internet-Drafts can be accessed at: | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at: | The list of Internet-Draft Shadow Directories can be accessed at: | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2002). All Rights Reserved. | |||
Abstract | Abstract | |||
This document describes how to express media transport over | This document describes how to express media transport over | |||
connection-oriented protocols using the Session Description Protocol | connection-oriented protocols using the Session Description Protocol | |||
(SDP). It defines two new protocol identifiers: TCP and TLS. It | (SDP). It defines two new protocol identifiers: TCP and TLS. It | |||
also defines the syntax and semantics for an SDP "direction" | also defines the syntax and semantics for an SDP "direction" | |||
attribute that describes the connection setup procedure. | attribute that describes the connection setup procedure. | |||
Yon 1 | Yon 1 | |||
Introduction | 1 Introduction | |||
The Session Description Protocol [SDP] provides a general-purpose | The Session Description Protocol [SDP] provides a general-purpose | |||
format for describing multimedia sessions in announcements or | format for describing multimedia sessions in announcements or | |||
invitations. SDP uses an entirely textual data format (the US-ASCII | invitations. SDP uses an entirely textual data format (the US-ASCII | |||
subset of [UTF-8]) to maximize portability among transports. SDP | subset of [UTF-8]) to maximize portability among transports. SDP | |||
does not define a protocol, but only the syntax to describe a | does not define a protocol, but only the syntax to describe a | |||
multimedia session with sufficient information to discover and | multimedia session with sufficient information to discover and | |||
participate in that session. Session descriptions may be sent using | participate in that session. Session descriptions may be sent using | |||
any number of existing application protocols for transport (e.g., | any number of existing application protocols for transport (e.g., | |||
SAP, SIP, RTSP, email, HTTP, etc.). | SAP, SIP, RTSP, email, HTTP, etc.). | |||
Terminology | ||||
In this document, the key words "MUST", "MUST NOT", "REQUIRED", | ||||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | ||||
and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] | ||||
and indicate requirement levels for compliant implementations. | ||||
Motivation | ||||
[SDP] describes two protocol identifiers: RTP/AVP and UDP, both of | [SDP] describes two protocol identifiers: RTP/AVP and UDP, both of | |||
which are unreliable, connectionless protocols, an appropriate | which are unreliable, connectionless protocols, an appropriate | |||
choice for multimedia streams. There are, however, applications for | choice for multimedia streams. There are, however, applications for | |||
which the connection-oriented transports such as TCP are more | which the connection-oriented transports such as TCP are more | |||
appropriate, but [SDP] provides no way to describe a session that | appropriate, but [SDP] provides no way to describe a session that | |||
uses protocols other than RTP or UDP. | uses protocols other than RTP or UDP. | |||
Connection-oriented protocols introduce a new factor when describing | Connection-oriented protocols introduce a new factor when describing | |||
a session: not only must it be possible to express that a protocol | a session: not only must it be possible to express that a protocol | |||
will be based on this protocol, but it must also describe the | will be based on this protocol, but it must also describe the | |||
connection setup procedure. | connection setup procedure. This memo defines two new protocol | |||
identifiers, TCP and TLS, along with the syntax and semantics of the | ||||
a=direction attribute. | ||||
1 Protocol Identifiers | Terminology | |||
1.1 TCP | In this document, the key words "MUST", "MUST NOT", "REQUIRED", | |||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | ||||
and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] | ||||
and indicate requirement levels for compliant implementations. | ||||
2 Protocol Identifiers | ||||
The m= line in [SDP] is where an endpoint specifies the protocol | ||||
used for the media in the session. See the "Media Announcements" | ||||
section of [SDP] for a discussion on protocol identifiers. | ||||
2.1 TCP | ||||
The TCP protocol identifier is similar to the UDP protocol | The TCP protocol identifier is similar to the UDP protocol | |||
identifier in that it only describes the transport protocol without | identifier in that it only describes the transport protocol without | |||
any connotation as to the upper-layer protocol. An m= line that | any connotation as to the upper-layer protocol. An m= line that | |||
specifies "TCP" MUST further qualify the protocol using a fmt | specifies "TCP" MUST further qualify the protocol using a fmt | |||
identifier (see [SDP] Appendix B). | identifier (see [SDP] Appendix B). | |||
1.2 TLS | 2.2 TLS | |||
The TLS protocol identifier specifies that the session will use the | The TLS protocol identifier specifies that the session will use the | |||
Transport Layer Security protocol [TLS] with an implied transport | Transport Layer Security protocol [TLS] with an implied transport | |||
protocol of TCP. To describe a media session that uses TLS over | protocol of TCP. To describe a media session that uses TLS over | |||
TCP, the protocol identifier "TLS" must be specified in the m= line. | TCP, the protocol identifier "TLS" must be specified in the m= line. | |||
Yon INTERNET-DRAFT - Expires October 2002 2 | ||||
An m= line that specifies TLS MUST further qualify the protocol | An m= line that specifies TLS MUST further qualify the protocol | |||
using a fmt identifier. | using a fmt identifier. | |||
Yon INTERNET-DRAFT û Expires January 2002 2 | 3 Direction Attribute | |||
2 Direction Attribute | ||||
An important attribute of connection-oriented protocols is the setup | An important attribute of connection-oriented protocols is the setup | |||
procedure. One endpoint needs to initiate the connection and the | procedure. One endpoint needs to initiate the connection and the | |||
other endpoint needs to accept the connection. The direction | other endpoint needs to accept the connection. The direction | |||
attribute is used to describe these roles, and the syntax is as | attribute is used to describe these roles, and the syntax is as | |||
follows: | follows: | |||
a=direction:<role> [<source-address>] | a=direction:<role> [<source-address>] | |||
The <role> is one of the following: | The <role> is one of the following: | |||
passive: The endpoint will accept an incoming connection. | passive: The endpoint will accept an incoming connection. | |||
active: The endpoint will initiate an outgoing connection. | active: The endpoint will initiate an outgoing connection. | |||
both: The endpoint will both accept an incoming connection | both: The endpoint will both accept an incoming connection | |||
and will initiate an outgoing connection. | and will initiate an outgoing connection. | |||
reuse: The endpoint will use the connection that has already | ||||
been established with the opposite endpoint. | ||||
The <source-address> is a sequence of values that describe the | The <source-address> is a sequence of values that describe the | |||
address and port number from where the connection will originate, | address and port number from where the connection will originate, | |||
and consists of the following values: | and consists of the following values: | |||
nettype addrtype unicast-address [port] | nettype addrtype unicast-address [port] | |||
The <source-address> is an optional value that may be specified with | The <source-address> is an optional value that may be specified with | |||
direction:active, direction:both, or direction:reuse. Within the | direction:active or direction:both. Within the <source-address>, | |||
<source-address>, the source port number is RECOMMENDED but may be | the source port number is RECOMMENDED but may be omitted. | |||
omitted. | ||||
2.1 Semantics of direction:passive | 3.1 Semantics of direction:passive | |||
By specifying direction:passive, the endpoint indicates that the | By specifying direction:passive, the endpoint indicates that the | |||
port number specified in the m= line is available to accept a | port number specified in the m= line is available to accept a | |||
connection from the other endpoint. The endpoint MUST NOT specify a | connection from the other endpoint. The endpoint MUST NOT specify a | |||
<source-address> after direction:passive. | <source-address> after direction:passive. | |||
2.2 Semantics of direction:active | 3.2 Semantics of direction:active | |||
By specifying direction:active, the endpoint indicates that it will | By specifying direction:active, the endpoint indicates that it will | |||
initiate a connection to the port number on the m= line of the other | initiate a connection to the port number on the m= line of the other | |||
endpoint. The port number on its own m= line is irrelevant, and the | endpoint. The port number on its own m= line is irrelevant, and the | |||
opposite endpoint MUST NOT attempt to initiate a connection to the | opposite endpoint MUST NOT attempt to initiate a connection to the | |||
port number specified there. Nevertheless, since the m= line must | port number specified there. Nevertheless, since the m= line must | |||
contain a valid port number, the endpoint specifying | contain a valid port number, the endpoint specifying | |||
direction:active SHOULD specify a port number of 9 (the discard | direction:active SHOULD specify a port number of 9 (the discard | |||
port) on its m= line. The endpoint MUST NOT specify a port number | port) on its m= line. The endpoint MUST NOT specify a port number | |||
of zero, as that carries other semantics in [SDP]. | of zero, as that carries other semantics in [SDP]. | |||
Yon INTERNET-DRAFT û Expires January 2002 3 | ||||
The endpoint SHOULD specify the address and port number from which | The endpoint SHOULD specify the address and port number from which | |||
it will initiate the connection in the <source-address> position on | it will initiate the connection in the <source-address> position on | |||
the a= line. | ||||
2.3 Semantics of direction:both | Yon INTERNET-DRAFT - Expires October 2002 3 | |||
the a=direction line. The following SDP fragment shows an example | ||||
of direction:active: | ||||
c=IN IP4 10.1.1.1 | ||||
m=image 9 TCP t38 | ||||
a=direction:active IN IP4 10.1.1.1 1892 | ||||
3.3 Semantics of direction:both | ||||
By specifying direction:both, the endpoint indicates that it will | By specifying direction:both, the endpoint indicates that it will | |||
both accept a TCP connection on the port number of its own m= line, | both accept a TCP connection on the port number of its own m= line, | |||
and that it will also initiate a connection to the port number on | and that it will also initiate a connection to the port number on | |||
the m= line of the other endpoint. | the m= line of the other endpoint. | |||
As with direction:active, the endpoint SHOULD specify the address | As with direction:active, the endpoint SHOULD specify the address | |||
and port number from which it will initiate the connection in the | and port number from which it will initiate the connection in the | |||
<source-address> position on the a= line. | <source-address> position on the a=direction line. | |||
Since this attribute describes behavior that is similar to | Since this attribute describes behavior that is similar to | |||
connectionless media descriptions in [SDP], it is the default value | connectionless media descriptions in [SDP], it is the default value | |||
for the direction attribute and is therefore optional. | for the direction attribute and is therefore optional. | |||
Endpoints may choose to specify direction:both for one or more of | Endpoints may choose to specify direction:both for one or more of | |||
the following reasons: | the following reasons: | |||
1) The endpoint has no preference as to whether it accepts or | 1) The endpoint has no preference as to whether it accepts or | |||
initiates the connection, and therefore is offering the remote | initiates the connection, and therefore is offering the remote | |||
endpoint a choice of connection setup procedures. | endpoint a choice of connection setup procedures. | |||
2) The endpoints intend to use a single connection to transport | 2) The endpoints intend to use a single connection to transport | |||
the media, but it is not known whether firewall issues will | the media, but it is not known whether firewall issues will | |||
prevent either endpoint from initiating or accepting the | prevent either endpoint from initiating or accepting the | |||
connection. Therefore both endpoints will attempt to initiate | connection. Therefore both endpoints will attempt to initiate | |||
a connection in hopes that at least one will succeed. | a connection in hopes that at least one will succeed. | |||
3) The endpoints intend to use two connections to transport the | ||||
media, and one must be initiated by the remote endpoint and | ||||
the other must be initiated by the local endpoint. | ||||
If one endpoint specifies either direction:active or | If one endpoint specifies either direction:active or | |||
direction:passive and the other specifies direction:both, both | direction:passive and the other specifies direction:both, both | |||
endpoints MUST behave as if the latter had specified the inverse | endpoints MUST behave as if the latter had specified the inverse | |||
direction of the former. For example, specifying direction:both | direction of the former. For example, specifying direction:both | |||
when the other endpoint specifies direction:active SHALL cause both | when the other endpoint specifies direction:active SHALL cause both | |||
endpoints to behave as if the former had specified | endpoints to behave as if the former had specified | |||
direction:passive. Conversely, specifying direction:both when the | direction:passive. Conversely, specifying direction:both when the | |||
other endpoint specifies direction:passive SHALL cause both | other endpoint specifies direction:passive SHALL cause both | |||
endpoints to behave as if the former had specified direction:active. | endpoints to behave as if the former had specified direction:active. | |||
If both endpoints specify direction:both then each endpoint MUST | If both endpoints specify direction:both then each endpoint MUST | |||
initiate a connection to the port number specified on the m= line of | initiate a connection to the port number specified on the m= line of | |||
the opposite endpoint. If a single connection is needed (case #1 or | the opposite endpoint. There is one exception to this requirement: | |||
#2 above), there is one exception to this requirement: if an | if an endpoint receives the incoming connection from the opposite | |||
endpoint receives the incoming connection from the opposite endpoint | endpoint prior to initiating its own outbound connection, then that | |||
prior to initiating its own outbound connection, then that endpoint | endpoint MAY use that connection rather than attempt to make an | |||
MAY use that connection rather than attempt to make an outbound | outbound connection to the opposite endpoint. | |||
connection to the opposite endpoint. | ||||
Yon INTERNET-DRAFT û Expires January 2002 4 | Yon INTERNET-DRAFT - Expires October 2002 4 | |||
If only one connection succeeds, then that connection will be used | If only one connection succeeds, then that connection will be used | |||
to carry the media. Once it has transmitted data on this | to carry the media. Once it has transmitted data on this | |||
connection, the initiating endpoint MUST NOT perform another | connection, the initiating endpoint MUST NOT perform another | |||
connection attempt to the accepting endpoint. This allows the | connection attempt to the accepting endpoint. This allows the | |||
accepting endpoint to release or recycle the listening port for | accepting endpoint to release or recycle the listening port for | |||
another session once it has received data from the initiating | another session once it has received data from the initiating | |||
endpoint. | endpoint. | |||
If both connections succeed but only one was needed (case #2 above), | If both connections succeed, the following rules SHALL apply: | |||
the following rules SHALL apply: | ||||
a) Each endpoint MUST accept data from either connection. | a) Each endpoint MUST accept data from either connection. | |||
b) Once an endpoint has transmitted data to one of the | b) Once an endpoint has transmitted data to one of the connections, | |||
connections, it MUST use that connection exclusively for | it MUST use that connection exclusively for transmission. | |||
transmission. | ||||
c) Once an endpoint has transmitted AND received data, if one of | c) Once an endpoint has transmitted AND received data, if one of the | |||
the connections is determined to be idle, the endpoint MAY | connections is determined to be idle, the endpoint SHOULD close | |||
close the idle connection. | the idle connection. | |||
2.4 Semantics of direction:reuse | 3.4 Optimizing direction:both | |||
By specifying direction:reuse, the endpoint indicates that it is | As discussed in the previous section, there is the possibility that | |||
changing the parameter(s) of an existing session on a previously | two connections will be created when only one is needed. While | |||
established connection with the opposite endpoint. Therefore no new | rules in the previous section accommodate the closing of an idle | |||
connections are to be created. This is intended for cases where | connection, they do not prevent a race condition where the endpoints | |||
media types are added, removed, or changed during a session. For | simultaneously start sending data on opposite connections thereby | |||
example, an endpoint adding a video stream to an existing audio | causing two connections to be used where one would have sufficed. | |||
session may elect to multiplex the new stream over the same | While it is not possible to entirely eliminate this race condition, | |||
connection that is currently transporting the audio stream. | it is in the endpointsÆ interest to minimize its occurrence. | |||
Therefore, when a session is negotiated through interactive exchange | ||||
of SDP between endpoints (as in the case of SIP) AND the result of | ||||
the negotiation is that each endpoint specifies direction:both, it | ||||
is RECOMMENDED that the endpoints use the following guidelines: | ||||
2.5 Bidirectional versus Unidirectional Media | a) There comes a point during the exchange of SDP where one endpoint | |||
is prepared to send the final message that will complete the | ||||
negotiation and allow the session to begin. For the purposes of | ||||
this discussion, the endpoint that will send this final message | ||||
will be called the Initiator, and the endpoint that will receive | ||||
this message will be called the Acceptor. | ||||
b) The Initiator, upon receiving sufficient information to initiate a | ||||
connection, MUST attempt to connect to the Acceptor as soon as | ||||
possible. | ||||
c) In order to lower the likelihood that the Acceptor will also | ||||
attempt to initiate a connection, the Initiator SHOULD incorporate | ||||
a short delay between initiating the connection and sending the | ||||
final SDP to the Acceptor. | ||||
d) The delay time chosen by the Initiator MUST NOT introduce an | ||||
unacceptable session setup delay should the connection to the | ||||
Acceptor not succeed. | ||||
Yon INTERNET-DRAFT - Expires October 2002 5 | ||||
3.5 Bidirectional versus Unidirectional Media | ||||
In traditional SDP transport types the flow is unidirectional. If | In traditional SDP transport types the flow is unidirectional. If | |||
the intent is for media to flow in both directions, both endpoints | the intent is for media to flow in both directions, both endpoints | |||
must specify SDP that describes where to deliver the media and what | must specify SDP that describes where to deliver the media and what | |||
media type(s) to use. For example, if only Endpoint A presents SDP | media type(s) to use. For example, if only Endpoint A presents SDP | |||
then media can only flow towards Endpoint A, as Endpoint B has not | then media can only flow towards Endpoint A, as Endpoint B has not | |||
specified where and how to send media to it. | specified where and how to send media to it. | |||
Because most connection-oriented media is inherently bi-directional, | Because most connection-oriented media is inherently bi-directional, | |||
endpoints may encounter a situation where only one side presented | endpoints may encounter a situation where only one side presented | |||
SDP yet there is now a network path that can carry media in either | SDP yet there is now a network path that can carry media in either | |||
direction. In keeping with traditional SDP semantics, an endpoint | direction. In keeping with traditional SDP semantics, an endpoint | |||
MUST NOT send data to the other endpoint unless it has specified SDP | MUST NOT send data to the other endpoint unless it has specified SDP | |||
information describing the type of media it can accept. | information describing the type of media it can accept. | |||
It is, however, perfectly acceptable for an endpoint to transmit | It is, however, perfectly acceptable for an endpoint to transmit | |||
data on the same connection it is using to receive data, so long as | data on the same connection it is using to receive data, so long as | |||
the other endpoint has advertised its willingness to accept data. | the other endpoint has advertised its willingness to accept data. | |||
Likewise, it is perfectly acceptable for an endpoint to receive data | Likewise, it is perfectly acceptable for an endpoint to receive data | |||
Yon INTERNET-DRAFT û Expires January 2002 5 | ||||
on the same connection it is using to transmit data to the | on the same connection it is using to transmit data to the | |||
corresponding remote endpoint. In other words, for a bi-directional | corresponding remote endpoint. In other words, for a bi-directional | |||
application-level session, a connection may be used to send data in | application-level session, a connection may be used to send data in | |||
both directions (contingent to rules outlined in Section 2.3) as | both directions (contingent to rules outlined in Section 2.3) as | |||
long as one side of the connection is attached to either of the | long as one side of the connection is attached to either of the | |||
advertised SDP transport addresses. | advertised SDP transport addresses. | |||
3 Source-Address Considerations | 3.6 Treating UDP and RTP/AVP like Connection Oriented Media | |||
Endpoints MAY specify a direction attribute for UDP or RTP/AVP | ||||
media. This indicates that the endpoint would like to treat this | ||||
media as a type of connection oriented media. (The endpoint may do | ||||
this to facilitate NAT traversal for example.) Note that for | ||||
backwards compatibility, an endpoint which can specify | ||||
direction:active MUST include valid addresses and ports in the SDP | ||||
as always. If the peer's SDP does not include a direction | ||||
attribute, it knows that the peer does not support connection- | ||||
oriented media, and media exchange will proceed normally, as if | ||||
connection-oriented media were not offered. | ||||
Endpoints that specify direction:passive MUST NOT send any media, | ||||
any packets whatsoever (including control packets such as RTCP), | ||||
from their passive ports until they receive a packet on these ports | ||||
and record the source address and port of the sender. The passive | ||||
endpoint then assumes that the first packet received corresponds to | ||||
its active peer. From this point onward, passive endpoints MUST | ||||
send UDP or RTP media from the same port as the port indicated in | ||||
the m= line. Passive endpoints MUST send RTCP media (if any) from | ||||
the port on which they expect to receive it (typically the RTP port | ||||
number plus 1). | ||||
Endpoints that specify direction:active MUST be prepared to receive | ||||
on the ports from which they send. Once they learn the IP address | ||||
Yon INTERNET-DRAFT - Expires October 2002 6 | ||||
and port of their peer from the peer's SDP, they SHOULD immediately | ||||
send some kind of media (even if just comfort noise) to each of | ||||
these ports. This is so the peer can learn their IP address and | ||||
port, in order to send media back without additional delay. | ||||
Effectively, the exchange of the first media packet completes a bi- | ||||
directional handshake between the active and passive peer. | ||||
4 Source-Address Considerations | ||||
In the cases where the endpoint is initiating the connection, it is | In the cases where the endpoint is initiating the connection, it is | |||
RECOMMENDED that a source address be specified on the a= line by | RECOMMENDED that a source address be specified on the a=direction | |||
that endpoint. It is also RECOMMENDED that the source port be | line by that endpoint. It is also RECOMMENDED that the source port | |||
included in the source address. In most environments, the source | be included in the source address. In most environments, the source | |||
port number can be determined by binding the socket before | port number can be determined by binding the socket before | |||
initiating the connect, as shown in the sample C code below: | initiating the connect, as shown in the sample C code below: | |||
{ | { | |||
SOCKET s_id | SOCKET s_id | |||
SOCKADDR_IN cli_sin; | SOCKADDR_IN cli_sin; | |||
int namelen; | int namelen; | |||
// Create the socket | // Create the socket | |||
s_id = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP); | s_id = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP); | |||
skipping to change at line 306 | skipping to change at line 364 | |||
} | } | |||
If the source address is omitted, the receiver of the SDP packet | If the source address is omitted, the receiver of the SDP packet | |||
MUST NOT make any assumptions in regards to the address or port from | MUST NOT make any assumptions in regards to the address or port from | |||
where the connection will originate. In particular, the receiver | where the connection will originate. In particular, the receiver | |||
MUST NOT assume that the address information listed on the c= line | MUST NOT assume that the address information listed on the c= line | |||
has any implication as to where the media connection originates. | has any implication as to where the media connection originates. | |||
NOTE: | NOTE: | |||
The motivation for specifying the source address is | The motivation for specifying the source address is | |||
twofold. First, it aids Application-Level Proxies by | twofold. First, it aids Application-Level Proxies | |||
explicitly announcing the source of the outbound | (ALP) by explicitly announcing the source of the | |||
connection. This allows, for example, a dynamic | outbound connection. This allows, for example, a | |||
firewall pinhole to be created that will allow the | dynamic firewall pinhole to be created that will allow | |||
connection to pass. | the connection to pass. Or as another example, an ALP | |||
integrated with a Network Address Translation (NAT) | ||||
Yon INTERNET-DRAFT - Expires October 2002 7 | ||||
gateway could create a dynamic address/port binding | ||||
and rewrite the SDP accordingly. | ||||
Yon INTERNET-DRAFT û Expires January 2002 6 | ||||
Second, it allows the passive endpoint to correlate | Second, it allows the passive endpoint to correlate | |||
the incoming connection with the session being | the incoming connection with the session being | |||
negotiated. Note that great care must be taken when | negotiated. Note that great care must be taken when | |||
using the source address as a means to identify | using the source address as a means to identify | |||
incoming connections, as Network Address Translation | incoming connections, as NAT can render the source | |||
(NAT) can render the source address unreliable. In | address unreliable. In addition if the originating | |||
addition if the originating endpoint omits the source | endpoint omits the source port, the source address can | |||
port, the source address can be ambiguous if multiple, | be ambiguous if multiple, logical endpoints share the | |||
logical endpoints share the same network address. | same network address. Therefore it is NOT RECOMMENDED | |||
Therefore it is NOT RECOMMENDED that the source | that the source address be used for this purpose | |||
address be used for this purpose unless the SDP occurs | unless the SDP occurs in the context of a controlled | |||
in the context of a controlled network topology that | network topology that guarantees that the source | |||
guarantees that the source address is both correct | address is both correct (i.e., no NAT, or a NAT with | |||
(i.e., no NAT, or a NAT with an Application-Level | an Application-Level Proxy that rewrites the SDP) and | |||
Proxy that rewrites the SDP) and unambiguous (i.e., | unambiguous (i.e., the source port is specified). | |||
the source port is specified). | ||||
3.1 Source Address Timing Considerations | 4.1 Source Address Timing Considerations | |||
When used in conjunction with a session signaling protocol such as | When used in conjunction with a session signaling protocol such as | |||
SIP, there may be cases where an endpoint initiates a connection | SIP, there may be cases where an endpoint initiates a connection | |||
prior to the opposite endpoint receiving the SDP that describe the | prior to the opposite endpoint receiving the SDP that describe the | |||
source address of the initiating endpoint. Therefore, an endpoint | source address of the initiating endpoint. Therefore, an endpoint | |||
that has advertised an address and port number with direction:both | that has advertised an address and port number with direction:both | |||
or direction:passive MUST be ready to accept a connection on that | or direction:passive MUST be ready to accept a connection on that | |||
address and port immediately. If the accepting endpoint requires | address and port immediately. If the accepting endpoint requires | |||
the source address to identify the initiating endpoint, it MUST keep | the source address to identify the initiating endpoint, it MUST keep | |||
the connection active and allow sufficient time for the source | the connection active and allow sufficient time for the source | |||
address to arrive before discarding the connection. | address to arrive before discarding the connection. | |||
4 Examples | 5 Connection and Listener Lifetime Considerations | |||
5.1 Listener Lifetime | ||||
An endpoint that has specified direction:both or direction:passive | ||||
MUST be ready to accept a connection on the appropriate address and | ||||
port during the time slot(s) advertised for that session. The | ||||
endpoint MUST keep the address and port available for incoming | ||||
connections until either: | ||||
a) The time window for the session has expired, or | ||||
b) The endpoint has received the expected number of incoming | ||||
connections on that address and port, or | ||||
c) Subsequent exchanges have superceded the SDP that originally | ||||
advertised the availability of the address and port. | ||||
Once the endpoint has determined that a listener is no longer needed | ||||
on a specific address and port, it SHOULD terminate the listener. | ||||
The endpoint is then free to re-use the address and port for | ||||
subsequent session advertisements. | ||||
Yon INTERNET-DRAFT - Expires October 2002 8 | ||||
5.2 Connection Lifetime | ||||
An endpoint that intends to initiate the connection MUST initiate | ||||
the connection immediately after it has sufficient information to do | ||||
so, even if it does not intend to immediately begin sending media to | ||||
the remote endpoint. This allows media to flow from the remote | ||||
endpoint. | ||||
An endpoint MUST NOT close the connection until the session has | ||||
expired, been explicitly terminated, or the media stream is | ||||
redirected to a different address or port. | ||||
If the endpoint determines that the connection has been closed, it | ||||
MAY attempt to re-establish the connection. The decision to do so | ||||
is application and/or context dependant. If the endpoint opts to | ||||
re-establish the connection, it MUST NOT assume that the original | ||||
address and port advertised by the remote endpoint is still valid. | ||||
Instead, the endpoint MUST renegotiate the session parameters by | ||||
exchanging new SDP. | ||||
5.3 Session Renegotiation and Connection Lifetime | ||||
There are scenarios where SDP is sent by an endpoint in order to | ||||
renegotiate an existing session. These include muting/unmuting a | ||||
session, renegotiating the attributes of the media used by the | ||||
session, or extending the length of a session about to expire. | ||||
Connection-oriented media introduces some ambiguities into session | ||||
renegotiation as to when the direction attribute must be obeyed and | ||||
when it is ignored. | ||||
The scenario of extending the duration of an existing session is a | ||||
good example: in order to extend an existing session, endpoints will | ||||
typically resend the original SDP with updated time information. In | ||||
connectionless media the result is no change to the existing media | ||||
streams. The problem with connection oriented media is that the | ||||
original SDP will contain a direction attribute which can be | ||||
construed as a request to create a new connection, as opposed to a | ||||
request to maintain steady state. To avoid this ambiguity, the | ||||
following rule SHALL apply to subsequent exchanges of SDP: | ||||
If the transport section combined with the direction | ||||
attribute of an SDP message describes an existing | ||||
connection between two endpoints, then the endpoints | ||||
MUST use that connection to carry the media described | ||||
in the remainder of the message. The endpoints MUST | ||||
NOT attempt to set up a new connection, regardless of | ||||
what is specified in the direction attribute. | ||||
This disambiguates most session renegotiation scenarios, with the | ||||
exception of muting. Muting a media stream is accomplished by | ||||
sending the original session SDP but with the port number set to | ||||
zero. This is still valid for connection oriented media, with the | ||||
Yon INTERNET-DRAFT - Expires October 2002 9 | ||||
additional caveat that the endpoints MUST NOT close the connection | ||||
described by that SDP. | ||||
6 Examples | ||||
What follows are a number of examples that show the most common | What follows are a number of examples that show the most common | |||
usage of the direction attribute combined with TCP-based media | usage of the direction attribute combined with TCP-based media | |||
descriptions. For the purpose of brevity, the main portion of the | descriptions. For the purpose of brevity, the main portion of the | |||
session description is omitted in the examples and is assumed to be | session description is omitted in the examples and is assumed to be | |||
the following: | the following: | |||
v=0 | v=0 | |||
o=me 2890844526 2890842807 IN IP4 10.1.1.2 | o=me 2890844526 2890842807 IN IP4 10.1.1.2 | |||
e=Me <me@ietf.org> | ||||
s=Call me using TCP | s=Call me using TCP | |||
t=0 0 | t=3034423619 3042462419 | |||
4.1 Example: simple passive/active | 6.1 Example: simple passive/active | |||
An endpoint at 10.1.1.2 signals the availability of a T.38 fax | An endpoint at 10.1.1.2 signals the availability of a T.38 fax | |||
session at port 54111: | session at port 54111: | |||
c=IN IP4 10.1.1.2 | c=IN IP4 10.1.1.2 | |||
m=image 54111 TCP t38 | m=image 54111 TCP t38 | |||
a=direction:passive | a=direction:passive | |||
Yon INTERNET-DRAFT û Expires January 2002 7 | ||||
An endpoint at 10.1.1.1 receiving this description responds with the | An endpoint at 10.1.1.1 receiving this description responds with the | |||
following: | following: | |||
c=IN IP4 10.1.1.1 | c=IN IP4 10.1.1.1 | |||
m=image 9 TCP t38 | m=image 9 TCP t38 | |||
a=direction:active | a=direction:active | |||
The endpoint at 10.1.1.1 then initiates the TCP connection to port | The endpoint at 10.1.1.1 then initiates the TCP connection to port | |||
54111 at 10.1.1.2. Note that the TCP connection may originate from | 54111 at 10.1.1.2. Note that the TCP connection may originate from | |||
any address or port. The endpoint at 10.1.1.1 could have optionally | any address or port. The endpoint at 10.1.1.1 could have optionally | |||
committed to a source address with a simple modification: | committed to a source address with a simple modification: | |||
c=IN IP4 10.1.1.1 | c=IN IP4 10.1.1.1 | |||
m=image 9 TCP t38 | m=image 9 TCP t38 | |||
a=direction:active IN IP4 10.1.1.1 1892 | a=direction:active IN IP4 10.1.1.1 1892 | |||
By adding the source address to the a= line, the endpoint at | By adding the source address to the a=direction line, the endpoint | |||
10.1.1.1 must now use a source port of 1892 when initiating the TCP | at 10.1.1.1 must now use a source port of 1892 when initiating the | |||
connection to port 54111 at 10.1.1.2. | TCP connection to port 54111 at 10.1.1.2. | |||
4.2 Example: agnostic both | 6.2 Example: agnostic both | |||
An endpoint at 10.1.1.2 signals the availability of a T.38 fax | An endpoint at 10.1.1.2 signals the availability of a T.38 fax | |||
session at TCP port 54111, but is also willing to set up the media | session at TCP port 54111, but is also willing to set up the media | |||
stream by initiating the TCP connection: | stream by initiating the TCP connection: | |||
c=IN IP4 10.1.1.2 | c=IN IP4 10.1.1.2 | |||
m=image 54111 TCP t38 | m=image 54111 TCP t38 | |||
a=direction:both | a=direction:both | |||
Yon INTERNET-DRAFT - Expires October 2002 10 | ||||
The endpoint at 10.1.1.1 has three choices: | The endpoint at 10.1.1.1 has three choices: | |||
1) It can respond with either of the two direction:active | 1) It can respond with either of the two direction:active | |||
descriptions listed in the previous example. In this case the | descriptions listed in the previous example. In this case the | |||
endpoint at 10.1.1.1 must initiate a connection to port 54111 | endpoint at 10.1.1.1 must initiate a connection to port 54111 | |||
at 10.1.1.2. | at 10.1.1.2. | |||
2) It can respond with a description similar to the following: | 2) It can respond with a description similar to the following: | |||
c=IN IP4 10.1.1.1 | c=IN IP4 10.1.1.1 | |||
m=image 54321 TCP t38 | m=image 54321 TCP t38 | |||
a=direction:passive | a=direction:passive | |||
In this case the endpoint at 10.1.1.2 must initiate a | In this case the endpoint at 10.1.1.2 must initiate a | |||
connection to port 54321 at 10.1.1.1. | connection to port 54321 at 10.1.1.1. | |||
3) It can respond with a description that specifies | 3) It can respond with a description that specifies | |||
direction:both, which is covered in the next example. | direction:both, which is covered in the next example. | |||
4.3 Example: redundant both | 6.3 Example: redundant both | |||
An endpoint at 10.1.1.2 uses the same description as the previous | An endpoint at 10.1.1.2 uses the same description as the previous | |||
example: | example: | |||
Yon INTERNET-DRAFT û Expires January 2002 8 | ||||
c=IN IP4 10.1.1.2 | c=IN IP4 10.1.1.2 | |||
m=image 54111 TCP t38 | m=image 54111 TCP t38 | |||
a=direction:both | a=direction:both | |||
Unlike the previous example, the endpoint at 10.1.1.1 responds with | Unlike the previous example, the endpoint at 10.1.1.1 responds with | |||
the following description: | the following description: | |||
c=IN IP4 10.1.1.1 | c=IN IP4 10.1.1.1 | |||
m=image 54321 TCP t38 | m=image 54321 TCP t38 | |||
a=direction:both | a=direction:both | |||
This will cause the endpoint at 10.1.1.2 to initiate a connection to | This will cause the endpoint at 10.1.1.2 to initiate a connection to | |||
port 54321 at 10.1.1.1, and the endpoint at 10.1.1.1 to initiate a | port 54321 at 10.1.1.1, and the endpoint at 10.1.1.1 to initiate a | |||
connection to port 54111 at 10.1.1.2. Whichever TCP connection | connection to port 54111 at 10.1.1.2. Whichever TCP connection | |||
succeeds will be used. If both succeed, one of the connections may | succeeds will be used. If both succeed, one of the connections may | |||
be closed as an optimization, using the rules in section 2.3. | be closed as an optimization, using the rules in section 2.3. | |||
5 Security Considerations | 6.4 Example: "Bidirectional" RTP and RTCP | |||
An endpoint at 10.1.1.2 is behind a NAT and does not know its own | ||||
public address. | ||||
c=IN IP4 10.1.1.2 | ||||
m=audio 9 RTP/AVP 0 | ||||
a=direction:active | ||||
A peer with a public IP address responds as follows and waits to | ||||
receive RTP and RTCP packets from its active peer. | ||||
Yon INTERNET-DRAFT - Expires October 2002 11 | ||||
c=IN IP4 1.2.3.4 | ||||
m=audio 18240 RTP/AVP 0 | ||||
a=direction:passive | ||||
The endpoint at 10.1.1.2 immediately sends RTP from port 9012 to | ||||
1.2.3.4 port 18240. A NAT translates the source address to 5.6.7.8 | ||||
port 1542. The passive endpoint receives this RTP packet and stores | ||||
this source address. When the passive endpoint wants to send RTP | ||||
media it sends it back to 5.6.7.8 port 1542. The NAT translates this | ||||
destination address back to 10.1.1.2 port 9012 and delivers it to | ||||
the active endpoint. | ||||
Likewise the endpoint at 10.1.1.2 immediately sends RTCP from port | ||||
9013 to 1.2.3.4:18241. The NAT translates this to 5.6.7.8:1984. The | ||||
passive endpoint receives the RTCP packet and stores the source | ||||
address. The passive endpoint sends its RTCP to 5.6.7.8:1984 which | ||||
is translated back to 10.1.1.2:9013 and delivered to the active | ||||
endpoint. | ||||
7 Security Considerations | ||||
See [SDP] for security and other considerations specific to the | See [SDP] for security and other considerations specific to the | |||
Session Description Protocol in general. There are no new security | Session Description Protocol in general. | |||
considerations introduced by these protocol identifiers and | ||||
attributes. | ||||
6 IANA Considerations | A possible security concern arises if a firewall were to monitor and | |||
act on the source address as described in the note in Section 4. | ||||
Firewall implementers must take care to ensure that the SDP came | ||||
from a trusted source before deciding whether to change the network | ||||
traffic restrictions currently imposed by the firewall. | ||||
8 IANA Considerations | ||||
As recommended by [SDP] Appendix B, the direction attribute | As recommended by [SDP] Appendix B, the direction attribute | |||
described in this document should be registered with IANA, as should | described in this document should be registered with IANA, as should | |||
the "TCP" and "TLS" protocol identifiers. | the "TCP" and "TLS" protocol identifiers. | |||
Acknowledgements | Acknowledgements | |||
The author would like to thank Jonathan Rosenberg, Anders | The author would like to thank Jonathan Rosenberg, Rohan Mahy, | |||
Kristensen, Paul Kyzivat, and Robert Fairlie-Cuninghame for their | Anders Kristensen, Paul Kyzivat, and Robert Fairlie-Cuninghame for | |||
valuable insights. | their valuable insights and contributions. | |||
Yon INTERNET-DRAFT û Expires January 2002 9 | Yon INTERNET-DRAFT - Expires October 2002 12 | |||
Appendix A: Direction Attribute Syntax | Appendix A: Direction Attribute Syntax | |||
This appendix provides an Augmented BNF [ABNF] grammar for | This appendix provides an Augmented BNF [ABNF] grammar for | |||
expressing the direction attribute for connection setup. It is | expressing the direction attribute for connection setup. It is | |||
intended as an extension to the grammar for the Session Description | intended as an extension to the grammar for the Session Description | |||
Protocol, as defined in [SDP]. Specifically, it describes the | Protocol, as defined in [SDP]. Specifically, it describes the | |||
syntax for the new "connection-setup" attribute field, which MAY be | syntax for the new "connection-setup" attribute field, which MAY be | |||
either a session-level or media-level attribute. | either a session-level or media-level attribute. | |||
connection-setup = "direction" ":" direction-spec | connection-setup = "direction" ":" direction-spec | |||
direction-spec = "passive" | qualified-direction | direction-spec = "passive" | qualified-direction | |||
qualified-direction = direction-ident | direction-ident source | qualified-direction = direction-ident | direction-ident source | |||
direction-ident = "both" | "active" | "reuse" | direction-ident = "both" | "active" | "passive" | |||
source = nettype addrtype unicast-address | | source = nettype addrtype unicast-address | | |||
nettype addrtype unicast-address port | nettype addrtype unicast-address port | |||
References | References | |||
[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax | [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF," RFC 2234, November 1997 | Specifications: ABNF," RFC 2234, November 1997 | |||
[SDP] M. Handley, V. Jacobson, "SDP: Session Description | [SDP] M. Handley, V. Jacobson, "SDP: Session Description | |||
skipping to change at line 512 | skipping to change at line 689 | |||
One Indian Head Plaza | One Indian Head Plaza | |||
Nashua, NH 03060 | Nashua, NH 03060 | |||
Phone: (603) 324-4100 | Phone: (603) 324-4100 | |||
EMail: yon@dialout.net | EMail: yon@dialout.net | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2001). All Rights Reserved. | |||
Yon INTERNET-DRAFT û Expires January 2002 10 | Yon INTERNET-DRAFT - Expires October 2002 13 | |||
This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
kind, provided that the above copyright notice and this paragraph | kind, provided that the above copyright notice and this paragraph | |||
are included on all such copies and derivative works. However, this | are included on all such copies and derivative works. However, this | |||
document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||
developing Internet standards in which case the procedures for | developing Internet standards in which case the procedures for | |||
skipping to change at line 537 | skipping to change at line 714 | |||
The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
This document and the information contained herein is provided on an | This document and the information contained herein is provided on an | |||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." | |||
Yon INTERNET-DRAFT û Expires January 2002 11 | Yon INTERNET-DRAFT - Expires October 2002 14 | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |