draft-ietf-mmusic-sdp4nat-01.txt   draft-ietf-mmusic-sdp4nat-02.txt 
INTERNET DRAFT C. Huitema INTERNET DRAFT C. Huitema
<draft-ietf-mmusic-sdp4nat-01.txt> Microsoft <draft-ietf-mmusic-sdp4nat-02.txt> Microsoft
Expires August 19, 2002 February 19, 2002 Expires August 25, 2002 February 25, 2002
RTCP attribute in SDP RTCP attribute in SDP
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.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
skipping to change at page 1, line 43 skipping to change at page 1, line 43
session requires multiple ports, SDP assumes that these port have session requires multiple ports, SDP assumes that these port have
consecutive numbers. However, when the session crosses a network consecutive numbers. However, when the session crosses a network
address translation device that also uses port mapping, the ordering address translation device that also uses port mapping, the ordering
of ports can be destroyed by the translation. To handle this, we of ports can be destroyed by the translation. To handle this, we
propose an extension attribute to SDP. propose an extension attribute to SDP.
1 Introduction 1 Introduction
The session invitation protocol (SIP, [RFC2543]) is often used to The session invitation protocol (SIP, [RFC2543]) is often used to
establish multi-media sessions on the Internet. There are often establish multi-media sessions on the Internet. There are often
cases today in which one or both end of the connection is hidden cases today in which one or both end of the connection are hidden
behind a network address translation device [RFC2766]. In this behind a network address translation device [RFC2766]. In this case,
cases, the SDP text must document the IP addresses and UDP ports as the SDP text must document the IP addresses and UDP ports as they
they appear on the "public Internet" side of the NAT; in this memo, appear on the "public Internet" side of the NAT; in this memo, we
we will suppose that the host located behind a NAT has a way to will suppose that the host located behind a NAT has a way to obtain
obtain these numbers; a possible way to learn these numbers is these numbers; a possible way to learn these numbers is briefly
briefly outlined in section 3. However, just learning the numbers is outlined in section 3. However, just learning the numbers is not
not enough. enough.
The SIP messages use the encoding defined in SDP [RFC2327] to The SIP messages use the encoding defined in SDP [RFC2327] to
describe the IP addresses and TCP or UDP ports used my the various describe the IP addresses and TCP or UDP ports used my the various
media. Audio and video are typically sent using RTP [RFC1889], which media. Audio and video are typically sent using RTP [RFC1889], which
requires two UDP port, one for the media and one for the control requires two UDP ports, one for the media and one for the control
protocol (RTCP). SDP carries only one port number per media, and protocol (RTCP). SDP carries only one port number per media, and
states that "other ports used by the media application (such as the states that "other ports used by the media application (such as the
RTCP port) should be derived algorithmically from the base media RTCP port) should be derived algorithmically from the base media
port." When the media is transmitted using RTP [RFC1889], the choice port." When the media is transmitted using RTP [RFC1889], the choice
of the port number is very specific: "for UDP and similar protocols, of the port number is very specific: "for UDP and similar protocols,
RTP uses an even port number and the corresponding RTCP stream uses RTP uses an even port number and the corresponding RTCP stream uses
the next higher (odd) port number; if an application is supplied the next higher (odd) port number; if an application is supplied
with an odd number for use as the RTP port, it should replace this with an odd number for use as the RTP port, it should replace this
number with the next lower (even) number." number with the next lower (even) number."
When the NAT device performs port mapping, there is no guarantee When the NAT device performs port mapping, there is no guarantee
that the mappings of two separate ports reflects the sequencing and that the mappings of two separate ports reflects the sequencing and
the parity of the original port numbers; in fact, when the NAT the parity of the original port numbers; in fact, when the NAT
manages a pool of IP addresses, it is even possible that the RTP and manages a pool of IP addresses, it is even possible that the RTP and
the RTCP ports may be mapped to different addresses. In order to the RTCP ports may be mapped to different addresses. In order to
successfully establish connections despites the misordering of the successfully establish connections despite the misordering of the
port numbers and the possible parity switches caused by the NAT, we port numbers and the possible parity switches caused by the NAT, we
propose to use a specific SDP attribute to document the RTCP port propose to use a specific SDP attribute to document the RTCP port
and optionally the RTCP address, and we also propose to make the and optionally the RTCP address, and we also propose to make the
behavior of RTP implementations more conforming to the robustness behavior of RTP implementations more conforming to the robustness
principle. principle.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 53 skipping to change at page 3, line 53
three questions that have been most often asked regarding this three questions that have been most often asked regarding this
solution are whether this is useful, i.e. whether a host can solution are whether this is useful, i.e. whether a host can
actually discover port numbers in an unmodified NAT, whether it is actually discover port numbers in an unmodified NAT, whether it is
sufficient, i.e. whether or not there is a need to document more sufficient, i.e. whether or not there is a need to document more
than one ancillary port per media type, and whether relaxing the RTP than one ancillary port per media type, and whether relaxing the RTP
requirements is legitimate. requirements is legitimate.
3.1 How do we discover port numbers ? 3.1 How do we discover port numbers ?
The proposed solution assumes that we can discover the "translated The proposed solution assumes that we can discover the "translated
port numbers", i.e. the value of the port as they appear on the port numbers", i.e. the value of the ports as they appear on the
"external side" of the NAT. There are multiple ways to achieve this "external side" of the NAT. There are multiple ways to achieve this
result. One possibility is to ask the cooperation of a well result. One possibility is to ask the cooperation of a well
connected third party, using a three step process: connected third party, using a four step process:
1) The host allocate two UDP port numbers for an RTP/RTCP pair, 1) The host allocate two UDP ports numbers for an RTP/RTCP pair,
2) The host send a UDP message from each port to the third party, 2) The host sends a UDP message from each port to the third party,
3) The third party reads the source address and port of the packet, 3) The third party reads the source address and port of the packet,
and copy them in the text of a reply, and copies them in the text of a reply, obscuring them if
necessary to avoid modification by the NAT,
4) The host parses the reply and learns the external address and 4) The host parses the reply and learns the external address and
port corresponding to each of the two UDP port. port corresponding to each of the two UDP port.
This algorithm supposes that the NAT will use the same translation This algorithm supposes that the NAT will use the same translation
for packets sent to the third party and to the "SDP peer" with which for packets sent to the third party and to the "SDP peer" with which
the host wants to establish a connection. The experience shows that the host wants to establish a connection. The experience shows that
this is the case for a large fraction of NATs. this is the case for a large fraction of NATs.
3.2 Do we need to support multiple ports ? 3.2 Do we need to support multiple ports ?
Most media streams are transmitted using a single pair of RTP and Most media streams are transmitted using a single pair of RTP and
RTCP ports. It is possible however to transmit a single media over RTCP ports. It is possible, however, to transmit a single media over
several RTP flows, for example using hierarchical encoding. In this several RTP flows, for example using hierarchical encoding. In this
case, SDP will encode the port number used by RTP on the first flow, case, SDP will encode the port number used by RTP on the first flow,
and the number of flows, as in: and the number of flows, as in:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
In this example, the media is sent over 2 consecutive pairs of In this example, the media is sent over 2 consecutive pairs of
ports, corresponding respectively to RTP for the first flow (even ports, corresponding respectively to RTP for the first flow (even
number, 49170), RTCP for the first flow (odd number, 49171), RTP for number, 49170), RTCP for the first flow (odd number, 49171), RTP for
the second flow (even number, 49172), and RTCP for the second flow the second flow (even number, 49172), and RTCP for the second flow
skipping to change at page 4, line 55 skipping to change at page 5, line 4
3.3 Why not expand the media definition? 3.3 Why not expand the media definition?
The RTP ports are documented in the media description line, and it The RTP ports are documented in the media description line, and it
would seem convenient to document the RTCP port at the same place, would seem convenient to document the RTCP port at the same place,
rather than create an RTCP attribute. We considered this design rather than create an RTCP attribute. We considered this design
alternative and rejected it for two reasons: adding an extra port alternative and rejected it for two reasons: adding an extra port
number and an option address in the media description would be number and an option address in the media description would be
awkward, and more importantly it would create problems with existing awkward, and more importantly it would create problems with existing
applications, which would have to reject the entire media applications, which would have to reject the entire media
description if they did not understand the extension. On the
description if they did not understand the extension. On the
contrary, adding an attribute has a well defined failure mode: contrary, adding an attribute has a well defined failure mode:
implementations that don't understand the "a=rtcp" attribute will implementations that don't understand the "a=rtcp" attribute will
simply ignore it; they will fail to send RTCP packets to the simply ignore it; they will fail to send RTCP packets to the
specified address, but they will at least be able to receive the specified address, but they will at least be able to receive the
media in the RTP packets. media in the RTP packets.
3.4 Is a tolerant RTP legitimate? 3.4 Is a tolerant RTP legitimate?
Our solution explicitly asks implementers to disregard a part of the Our solution explicitly asks implementers to disregard a part of the
RTP specification that mandates use of even port numbers for RTP and RTP specification that mandates use of even port numbers for RTP and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/