draft-ietf-mmusic-rtsp-nat-05.txt   draft-ietf-mmusic-rtsp-nat-06.txt 
Network Working Group M. Westerlund Network Working Group J. Goldberg
Internet-Draft Ericsson Internet-Draft Cisco
Intended status: Standards Track T. Zeng Intended status: Standards Track M. Westerlund
Expires: January 8, 2008 July 7, 2007 Expires: August 28, 2008 Ericsson
T. Zeng
Nextwave Wireless, Inc.
February 25, 2008
An Network Address Translator (NAT) Traversal mechanism for media An Network Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP) controlled by Real-Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-05 draft-ietf-mmusic-rtsp-nat-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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.
This Internet-Draft will expire on January 8, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a solution for Network Address Trans(NAT) This document defines a solution for Network Address Translation
traversal for the media stream associated with an Real-time Streaming (NAT) traversal for datagram based media streams setup and controlled
Protocol version 2 (RTSP 2.0). The mechanism is based on Interactive with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses
Connectivity Establishment (ICE) adapted for using RTSP as signalling Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
channel. The necessary RTSP protocol extensions and procedure is signalling channel, defining the necessary extra RTSP extensions and
defined in this document. procedures.
Requirements Language Requirements Language
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 3. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 3.2. ICE Candidate Transport Header Parameter . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 3.3. ICE Password and Username Transport Header Parameters . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 3.5.1. 150 ICE connectivity checks in progress . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 3.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Server Side SDP Attribute for ICE Support . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 8 3.7. ICE Features Not Required in RTSP . . . . . . . . . . . . 12
3.7.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . . 12
3.7.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . . 12
3.7.3. ICE Remote Candidate Transport Header Parameter . . . 12
4. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Session description and RTSP DESCRIBE (optional) . . . . . 13
4.2. Setting up the Media Resources . . . . . . . . . . . . . . 14
4.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 14
4.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 15
4.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 16
4.6. Server to Client ICE Connectivity Checks . . . . . . . . . 16
4.7. Client to Server ICE Connectivity Check . . . . . . . . . 17
4.8. Client Connectivity Checks Complete . . . . . . . . . . . 17
4.9. Server Connectivity Checks Complete . . . . . . . . . . . 17
4.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 17
4.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 18
4.12. re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 18
5.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 19
5.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 19
6. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 20
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 21
8.2. Transport Protocol Specifications . . . . . . . . . . . . 21
8.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 21
8.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 22
8.5. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
Real-time Streaming Protocol (RTSP) Real-time Streaming Protocol (RTSP)
[RFC2326][I-D.ietf-mmusic-rfc2326bis] is protocol used to setup and [RFC2326][I-D.ietf-mmusic-rfc2326bis] is a protocol used to setup and
control one or more media streams delivering media to receivers. It control one or more media streams delivering media to receivers. It
is RTSP's functionality of seting up media streams that get into is RTSP's functionality of setting up media streams that get into
serious issues with Network Address Translators (NAT) [RFC3022]. serious issues with Network Address Translators (NAT) [RFC3022].
Commonly the media will be totally blocked by the NAT unless extra Commonly the media will be totally blocked by the NAT unless extra
provisions are taken by the protocol. There is a clear and present provisions are taken by the protocol. There is a clear and present
need for NAT traversal mechanism for the media setup using RTSP. need for NAT traversal mechanism for the media setup using RTSP.
RTSP 1.0 [RFC2326] has quite a long time suffered from the lack of a RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT
standardized NAT [RFC3022] traversal mechanism for the media. traversal mechanism for a long time, however due to quality of the
However due to quality of the RTSP 1.0 specification, the work on RTSP 1.0 specification, the work has had to wait on the recently
updating RTSP was forced to abandom RTSP 1.0 and instead defined RTSP defined RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is similar
2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is similar to RTSP 1.0 in to RTSP 1.0 in many respects but significantly for this work, it
many aspects but contain a number of significant differencies. It contains a well defined extension mechanism so allowing a NAT
also contain a well defined extension mechanism allowing for traversal extension to be defined that is backwards compatible with
extensions like NAT traversal to be defined in way that will be RTSP 2.0 peers not supporting the extension. This extension
backwards compatible with RTSP 2.0 peers not supporting the mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0
extension. This extension isn't defined for RTSP 1.0 due to that it syntax so causing compatibility issues.
can't be specified in any way such that it do not break RTSP 1.0
syntax, and thus create compatibility issues.
There has been a number of suggested ways of resolving the NAT- There have been a number of suggested ways of resolving the NAT-
traversal of media for RTSP. A large number are also used in traversal of media for RTSP of which a large number are already used
implementations. However as the evaluation of RTSP NAT traversal in implementations. The evaluation of these NAT traversal solutions
solutions [I-D.ietf-mmusic-rtsp-nat-evaluation] for the media has in[I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are many
shown there are issues to consider. In the end a mechanism based on issues to consider, so after extensive evaluation, we selected a
Interactive Connectivity Establishment (ICE) was selected as it mechanism based on Interactive Connectivity Establishment (ICE).
allows also servers to be located behind NATs and also provide a good This was mainly two reasons: Firstly the mechanism supports RTSP
mitigation against the security threat RTSP represent as Distributed servers behind NATs and secondly the mechanism solves the security
Denial of Service (DDoS) attack tool. threat that uses RTSP servers as Distributed Denial of Service (DDoS)
attack tools.
This document does not define a NAT traversal mechanism for the RTSP The NAT problem for RTSP signalling traffic itself is beyond the
signalling itself. That is for future work in the cases it is scope of this document and is left for future study should the need
needed. Which compared to the media is in fewer deployement cases. arise, because it is a less prevalent problem than the NAT problem
In all cases the server i reachable on a public IP address the for RTSP media streams.
traversal of NAT for the signalling will work. Issues only arise
when both server and client are behind NATs. Solution beyond static
configurations or proxy based solutions are for future studies.
2. Solution Overview 2. Solution Overview
This overview assumes that the reader has some familarity with how This overview assumes that the reader has some familiarity with how
ICE [I-D.ietf-mmusic-ice] works. As it primarily points out how the ICE [I-D.ietf-mmusic-ice] works, as it primarily points out how the
different ICE steps are accomplished in RTSP. different ICE steps are accomplished in RTSP.
1. The server includes in the session description an SDP attribute 1. RTSP server can indicate it has support for ICE via an SDP
to indicate that the server has ICE capabilites for this session. [RFC4566] attribute in, for example, the SDP returned in RTSP
This is an optimization that allows clients to not spend DESCRIBE message. This allows RTSP clients to only send the new
resources in cases when the SDP indication is missing. ICE interchanges with servers that support ICE so as to limit
the overhead on current non-ICE supporting RTSP servers. If
RTSP DESCRIBE is used the normal capability determination
mechanism can be used, i.e. "Supported" header and the defined
feature tag.
2. The client reviews the session description to determine what 2. RTSP client reviews the session description returned, for
media resources that are going to be setup. For each of these example by an RTSP DESCRIBE message, to determine what media
media resources where the transport protocol supports resources that need to be setup. For each of these media
connectivity checks the client gathers candidate addresses. See resources where the transport protocol supports Session
section 4.1.1 in [I-D.ietf-mmusic-ice]. The client also installs Traversal Utilities for (NAT) (STUN)
the STUN servers on each of the local candidates. [I-D.ietf-behave-rfc3489bis] based connectivity checks, the
client gathers candidate addresses. See section 4.1.1 in
[I-D.ietf-mmusic-ice]. The client also installs the STUN
servers on each of the local candidates.
3. A new RTSP Transport header parameter (name tbd) is used to 3. RTSP client sends a SETUP request with both a transport
include all the candidates for each media resource in the SETUP specification with a lower layer indicating ICE and a new RTSP
request the client sends. One of these candidates are promoted Transport header parameter listing the ICE candidates for each
to default candidate per transport stream required for the media media resource. RTSP proxies in non-ICE transport
resource by including it as if ICE would not be used in the specifications should be treated at lower priority than those
dest_addr parameter. transport specifications supporting ICE.
4. The RTSP server receives the list of candidates for the media 4. After receiving the list of candidates from a client, the RTSP
resource to setup. It then gathers its candidates. For servers server gathers its own candidates. If the server has a public
having a public IP address a single candidate can be included and IP address then a single candidate per address family (e.g.
promoted to default directly. IPv4 and IPv6) can be included to reduce the number of
combinations and speed up the completion.
5. The server sets up the media and responds to the SETUP request if 5. The server sets up the media and if successful responds to the
otherwise succesfully with 200 OK respons. In that respons the SETUP request with a 200 OK response. In that response the
server includes its candidates in the server candidate parameter server selects the transport specification using ICE and
and the default in the src_addr parameter. Servers not being includes its candidates in the server candidate parameter.
behind a NAT or other type of middlebox and with a single
candidate should not intitiate its connectivyt checks yet. If
behind a NAT or other middlebox should now initiate its
connectivity checks following the procedures described in Section
5.7 and 5.8 of [I-D.ietf-mmusic-ice].
6. The client receives the SETUP response and learns the candidate 6. If the server is behind a NAT then it starts the connectivity
address to use for the connectivity checks. Then it initiates checks following the procedures described in Section 5.7 and 5.8
its connectivy checks. In other words it follows the procedures of [I-D.ietf-mmusic-ice]. If the server has a public IP address
in Section 6 of [I-D.ietf-mmusic-ice]. with a single candidate then it can refrain from server
initiated connectivity checks and rely on triggered checks.
7. When a connectivity check from the client reahces the server it 7. The client receives the SETUP response and learns the candidate
should result in a triggered check from the server. This is why address to use for the connectivity checks, and then initiates
severs not behind a middlebox can wait until this triggered check its connectivity check, following the procedures in Section 6 of
to send out any checks for itself. This saves resources and [I-D.ietf-mmusic-ice].
somewhat mittigates the DDoS potential.
8. When the client has concluded its connectivity checks and also 8. When a connectivity check from the client reaches the server it
received connectiviy checks on the promoted candidates for all will result in a triggered check from the server. This is why
the media components it can issue a PLAY request. If the servers with a public IP address can wait until this triggered
connectivity checks have not concluded succesfully then the check to send out any checks for itself so saving resources and
client may send a new SETUP request assuming it has any new mitigating the DDoS potential from server connectivity checks.
information or thinks the server may be able to do more that can
result in succesful checks.
9. When the RTSP servers receives a PLAY request it checks if its 9. When the client has concluded its connectivity checks and has
connectivity checks has concluded succesfully. If not it issues corresponding received the server connectivity checks on the
a 1xx response to indicate that it is still working on the promoted candidates for all components of all media streams, it
connectivity checks. If the checks has failed it issues a 4xx to can issue a PLAY request. If the connectivity checks have not
indicate that unsuccessful completion of the checks to the concluded successfully then the client may send a new SETUP
client. Upon sucess the server sends a 200 OK and starts request assuming it has any new information or believes the
server may be able to do more that can result in successful
checks.
10. When the RTSP servers receives a PLAY request it checks to see
the connectivity checks has concluded successfully and only then
can play the stream. If there is a problem with the checks then
the server sends to the client either a 150 (ICE connectivity
checks in progress) response to show that it is still working on
the connectivity checks or a 480 (ICE Processing Failed)
response to indicate a failure of the checks. If the checks are
successful then the server sends a 200 OK response and starts
delivering media. delivering media.
The client may release unused candidates by sending a new SETUP The client may release unused candidates when the ICE processing has
request that only contains the used candidates. This SETUP request concluded and a single candidate per component has been promoted.
shall only change the candidate list, and the default candidate to
the used ones. No other parameters should be changed. After
succesful completion of this request may the client release the
resources.
The client will continue to use STUN to send keep-alive for the used The client shall continue to use STUN to send keep-alive for the used
bindings. This is important as normally RTSP play mode sessions will bindings. This is important as often RTSP media sessions only
only contain traffic from the server to the client. As many NATs contain media traffic from the server to the client so the bindings
requires traffic from the client towards the server to keep the in the NAT needs to be refreshed by the client to server traffic
bindings alive these keep-alives are vital. provided by the STUN keep-alive.
3. RTSP Extensions 3. RTSP Extensions
To be written This section defines the necessary RTSP extensions for performing ICE
with RTSP. Note that these extensions are based on the SDP
attributes in the ICE specification unless expressly indicated.
4. Open Issues 3.1. ICE Transport Lower Layer
This whole draft is currently an open issues. The actual A new lower layer "D-ICE" for transport specifications is defined.
implementation of ICE for RTSP is yet to be written down in all This lower layer is datagram clean except that the protocol used must
necessary details. be demultiplexiable with STUN messages (see STUN
[I-D.ietf-behave-rfc3489bis]). With datagram clean we mean that it
must be capable of describing the length of the datagram, transport
that datagram (as a binary chunk of data) and provide it at the
receiving side as one single item. This lower layer can be any
transport type defined for ICE which does provide datagram transport
capabilities. Though only UDP is defined at present, however TCP
with framing may be specified and used in the future.
5. IANA Considerations This lower layer uses ICE to determine which of the different
candidates shall be used and then when the ICE processing has
concluded, uses the selected candidate to transport the datagrams
over this transport.
This document makes no request of IANA. This lower layer transport can be combined with all upper layer media
transport protocols that are possible to demultiplex with STUN and
which use datagrams. This specification defines the following
combinations:
Note to RFC Editor: this section may be removed on publication as an o RTP/AVP/D-ICE
RFC.
6. Security Considerations o RTP/AVPF/D-ICE
To be written o RTP/SAVP/D-ICE
7. Acknowledgements o RTP/SAVPF/D-ICE
8. References This list can easily be extended with more transport specifications
after having performed the evaluation that they are compatible with
D-ICE as lower layer.
8.1. Normative References The lower-layer "D-ICE" has the following rules for the inclusion of
transport parameters:
unicast: As ICE only supports unicast operations, thus it is
REQUIRED that one include the unicast indicator parameter, see
section 16.46 in [I-D.ietf-mmusic-rfc2326bis].
candidates: The "candidates" parameter SHALL be included as this
specify at least one candidate to try to establish a working
transport path with.
dest_addr: This parameter SHALL NOT be included as "candidates" is
used instead to provide the necessary address information.
ICE-Password: This parameter SHALL be included.
ICE-Userfrag: This parameter SHALL be included.
3.2. ICE Candidate Transport Header Parameter
This section defines a new RTSP transport parameter for carrying ICE
candidates related to the transport specification they appear within,
which may then be validated with an end-to-end connectivity check
using STUN [I-D.ietf-behave-rfc3489bis]. Transport parameters may
only occur once in each transport specification. For transport
specification using "D-ICE" as lower layer, this parameter needs to
be present. The parameter can contain one or more ICE candidates.
In the SETUP response there is only a single transport specification,
and if that uses the "D-ICE" lower layer this parameter also needs to
present including the server side candidates.
tr-parameter =/ SEMI ice-trn-par
ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate
*(SEMI ice-candidate) SWS DQ
ice-candidate = foundation SP
component-id SP
transport SP
priority SP
connection-address SP
port SP
cand-type
[SP rel-addr]
[SP rel-port]
*(SP extension-att-name SP extension-att-value)
foundation = <See section 15.1 of [I-D.ietf-mmusic-ice]>
component-id = <See section 15.1 of [I-D.ietf-mmusic-ice]>
transport = <See section 15.1 of [I-D.ietf-mmusic-ice]>
transport-extension = <See section 15.1 of [I-D.ietf-mmusic-ice]>
priority = <See section 15.1 of [I-D.ietf-mmusic-ice]>
cand-type = <See section 15.1 of [I-D.ietf-mmusic-ice]>
candidate-types = <See section 15.1 of [I-D.ietf-mmusic-ice]>
rel-addr = <See section 15.1 of [I-D.ietf-mmusic-ice]>
rel-port = <See section 15.1 of [I-D.ietf-mmusic-ice]>
extension-att-name = <See section 15.1 of [I-D.ietf-mmusic-ice]>
extension-att-value = <See section 15.1 of [I-D.ietf-mmusic-ice]>
ice-char = <See section 15.1 of [I-D.ietf-mmusic-ice]>
connection-address = <See [RFC4566]>
port = <See [RFC4566]>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
DQ = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SWS = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
<connection-address>: is the IP address of the candidate, allowing
for IPv4 addresses, IPv6 addresses and Fully qualified domain names
(FQDN), taken from [RFC4566]. The connection address SHOULD be on
the same format (explicit IP or FQDN) as in the dest_addr parameter
used to express default for the matching candidate. An IP address
SHOULD be used, but an FQDN MAY be used in place of an IP address.
In that case, when receiving an offer or answer containing an FQDN in
an a=candidate attribute, the FQDN is looked up in the DNS first
using an AAAA record (assuming the agent supports IPv6), and if no
result is found or the agent only supports IPv4, using an A. If the
DNS query returns more than one IP address, one is chosen, and then
used for the remainder of ICE processing.
<port>: is the port of the candidate taken from RFC 4566 [RFC4566].
<transport>: indicates the transport protocol for the candidate. The
ICE specification only defines UDP. However, extensibility is
provided to allow for future transport protocols to be used with ICE,
such as TCP or the Datagram Congestion Control Protocol (DCCP)
[RFC4340].
<foundation>: is an identifier that is equivalent for two candidates
that are of the same type, share the same base, and come from the
same STUN server, and is composed of one to thirty two <ice-char>.
The foundation is used to optimize ICE performance in the Frozen
algorithm.
<component-id>: identifies the specific component of the media stream
for which this is a candidate and os a positive integer between 1 and
256. It MUST start at 1 and MUST increment by 1 for each component
of a particular candidate. For media streams based on RTP,
candidates for the actual RTP media MUST have a component ID of 1,
and candidates for RTCP MUST have a component ID of 2. Other types
of media streams which require multiple components MUST develop
specifications which define the mapping of components to component
IDs. See Section 14 for additional discussion on extending ICE to
new media streams.
<priority>: is a positive integer between 1 and (2**31 - 1).
<cand-type>: encodes the type of candidate. The ICE specification
defines the values "host", "srflx", "prflx" and "relay" for host,
server reflexive, peer reflexive and relayed candidates,
respectively. The set of candidate types is extensible for the
future.
<rel-addr> and <rel-port>: convey transport addresses related to the
candidate, useful for diagnostics and other purposes. <rel-addr> and
<rel-port> MUST be present for server reflexive, peer reflexive and
relayed candidates. If a candidate is server or peer reflexive,
<rel-addr> and <rel-port> is equal to the base for that server or
peer reflexive candidate. If the candidate is relayed, <rel-addr>
and <rel-port> is equal to the mapped address in the Allocate
Response that provided the client with that relayed candidate (see
Appendix B.3 for a discussion of its purpose). If the candidate is a
host candidate <rel-addr> and <rel-port> MUST be omitted.
3.3. ICE Password and Username Transport Header Parameters
The ICE password and username for each agent needs to be transported
using RTSP. For that purpose new transport header parameters are
defined.
There MUST be an "ICE-Password" and "ICE-Userfrag" parameter for each
media stream. If two SETUP requests in the same RTSP session have
identical ICE-Userfrag's, they MUST have identical ICE-Password's.
The ICE-Userfrag and ICE-Password attributes MUST be chosen randomly
at the beginning of a session. The ICE-Userfrag attribute MUST
contain at least 24 bits of randomness, and the ICE-Password
attribute MUST contain at least 128 bits of randomness. This means
that the ICE-Userfrag attribute will be at least 4 characters long,
and the ICE-Password at least 22 characters long, since the grammar
for these attributes allows for 6 bits of randomness per character.
The attributes MAY be longer than 4 and 22 characters respectively,
of course, up to 256 characters. The upper limit allows for buffer
sizing in implementations. Its large upper limit allows for
increased amounts of randomness to be added over time.
The ABNF [RFC5234] for these parameters are:
tr-parameter =/ SEMI ice-password-par
tr-parameter =/ SEMI ice-userfrag-par
ice-password-par = ICE-Password" HCOLON password
ice-userfrag-par = ICE-Userfrag" HCOLON ufrag
password = <Defined in [I-D.ietf-mmusic-ice]>
ufrag = <Defined in [I-D.ietf-mmusic-ice]>
HCOLON = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
3.4. ICE Feature Tag
A feature tag is defined for usage in the RTSP capabilities mechanism
for ICE support for media transport using datagrams: "setup.ice-d-m".
This feature tag indicates that one support all the mandatory to
support functions of this specification. It is applicable to all
types of RTSP agents; clients, servers and proxies.
The RTSP client should send the feature tag "setup.ice-d-m" in the
"Supported" header in all SETUP requests that contain the "D-ICE"
lower layer transport.
3.5. Status Codes
ICE needs two new RTSP response codes to indicate correctly progress
and errors.
+------+----------------------------------------------+-------------+
| Code | Reason | Method |
+------+----------------------------------------------+-------------+
| 150 | Server still working on ICE connectivity | PLAY |
| | checks | |
| 480 | ICE Connectivity check failure | PLAY, SETUP |
+------+----------------------------------------------+-------------+
Table 1: New Status codes and their usage with RTSP methods
3.5.1. 150 ICE connectivity checks in progress
The 150 response code indicates that ICE connectivity checks are
still in progress and haven't concluded. This response SHALL be sent
within 200 milliseconds of receiving a PLAY request that currently
can't be fulfilled because ICE connectivity checks are still running.
Subsequently, every 3 seconds after the previous sent one, a 150
reply shall be sent until the ICE connectivity checks conclude either
successfully or in failure, and a final response for the request can
be provided.
3.5.2. 480 ICE Processing Failed
The 480 client error response code is used in cases when the request
can't be fulfilled due to a failure in the ICE processing, such as
that all the connectivity checks have timed out. This error message
can appear either in response to a SETUP request to indicate that no
candidate pair can be constructed or to a PLAY request that the
server's connectivity checks resulted in failure.
3.6. Server Side SDP Attribute for ICE Support
If the server supports the media NAT traversal for RTSP controlled
sessions, as described in this RFC, then the Server SHALL include the
"a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing
content served by the server. This is an session level attribute.
rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"
3.7. ICE Features Not Required in RTSP
A number of ICE signalling features are not needed with RTSP and are
discussed below.
3.7.1. ICE-Lite
The ICE-Lite attribute shall not be used in the context of RTSP. The
ICE specification describes two implementations of ICE: Full and
Lite, where hosts that are not behind a NAT are allowed to implement
only Lite. For RTSP, the Lite implementation is insufficient because
it does not cause the media server to send a connectivity check,
which are used to protect against making the RTSP server a denial of
service tool. This document defines another variation implementation
of ICE, called ICE-RTSP. It has its own set of simplifications
suitable to RTSP. Conceptually, this implementation of ICE-RTSP is
between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL
for clients.
3.7.2. ICE-Mismatch
The ice-mismatch parameter indicates that the offer arrived with a
default destination for a media component that didn't have a
corresponding candidate attribute. This is not needed for RTSP as
the ICE based lower layer transport specification either is supported
or another alternative transport is used. This is always explicitly
indicated in the SETUP request and response.
3.7.3. ICE Remote Candidate Transport Header Parameter
The Remote candidate attribute is not needed for RTSP for the
following reasons. Each SETUP results in a independent ICE
processing chain which either fails or results in promoting a single
candidate pair to usage. If a new SETUP request for the same media
is sent this needs to use a new userfragment and password to avoid
any race conditions or uncertainty for which processing round the
STUN requests relate to.
4. Detailed Solution
This section describes in detail how the interaction and flow of ICE
works with RTSP messages.
4.1. Session description and RTSP DESCRIBE (optional)
The RTSP server should indicate it has support for ICE by sending the
"rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE
message if SDP is used. This allows RTSP clients to only send the
new ICE interchanges with servers that support ICE so limiting the
overhead on current non-ICE supporting RTSP servers. When not using
RTSP DESCRIBE it is still recommended to use the SDP attribute for
session description.
A Client can also use the DESCRIBE request to determine explicitly if
both server and any proxies support ICE. The client includes the
"Supported" header with its supported feature tags, including
"setup.ice-d-m". Any proxy upon seeing the "Supported" header will
include the "Proxy-Supported" header with the feature tags it
supports. The server will echo back the "Proxy-Supported" header and
its own version of the Supported header so enabling a client to
determine if all involved parties support ICE or not. Note that even
if a proxy is present in the chain that doesn't indicate support for
ICE, it may still work.
For example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example
Supported: setup.ice-d-m
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Content-Type: application/sdp
Content-Length: 367
Supported: setup.ice-d-m
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
t=2873397496 2873404696
a=recvonly
a=rtsp-ice-d-m
a=control: *
m=audio 3456 RTP/AVP 0
a=control: /audio
m=video 2232 RTP/AVP 31
a=control: /video
4.2. Setting up the Media Resources
The RTSP client reviews the session description returned, for example
by an RTSP DESCRIBE message, to determine what media resources that
need to be setup. For each of these media resources where the
transport protocol supports ICE connectivity checks, the client shall
gather candidate addresses as described in section 4.1.1 in
[I-D.ietf-mmusic-ice] according to standard ICE rather than the ICE-
Lite implementation.
4.3. RTSP SETUP Request
The RTSP client will then send one or more SETUP requests to
establish the media streams required for the desired session. For
each media stream where it desires to use ICE it will include a
transport specification with "D-ICE" as the lower layer. This
transport specification SHOULD be placed first in the list to give it
highest priority. It is RECOMMENDED that additional transport
specifications are provided as a fallback in case of non ICE
supporting proxies. For example (Note that some lines are broken in
contradiction with the defined syntax due to space restrictions in
the documenting format:
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 302
Transport: RTP/AVP/D-ICE; unicast; candidates = "
1 1 UDP 2130706431 10.0.1.1 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.1 rport 9002",
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2
Supported: setup.ice-d-m
The client will be initiating and thus the controlling party in the
ICE processing.
4.4. Gathering Candidates
Upon receiving a SETUP request the server can determine what media
resource should be delivered and which transport alternatives that
the client supports. If one based on D-ICE is first on the list of
supported transports, the below applies, otherwise another transport
method is preferred and supported.
The transport specification will provide which media protocol is to
be used and based on this and the clients candidates, the server
determines the protocol and if it supports ICE with that protocol.
The server shall then gather its candidates according to section
4.1.1 in [I-D.ietf-mmusic-ice]. Servers that have an address that is
generally reachable by any clients within the address scope the
server intends to serve MAY be specially configured (high-
reachability configuration). This special configuration has the goal
of reducing the server side candidate to preferably a single one per
address family. Instead of gathering all possible addresses
including relayed and server reflexive addresses, the server uses a
single address per address family that it knows it should be
reachable by a client behind one or more NATs. The reason for this
special configuration is two fold: Firstly it reduces the load on the
server in address gathering and in ICE processing during the
connectivity checks. Secondly it will reduce the number of
permutations for candidate pairs significantly thus potentially
speeding up the conclusion of the ICE processing. Note however that
using this option on a server that doesn't fulfill the requirement of
being reachable is counter-productive and it is important that this
is correctly configured.
4.5. RTSP Server Response
The server determines if the SETUP request is successful from the
other perspectives and will return a 200 OK response, otherwise
returning an error code from the list in Table 4 in
[I-D.ietf-mmusic-rfc2326bis]. At that point the server, having
selected a transport specification using the "D-ICE" lower layer,
will need to include that transport specification in the response
message. The transport specification shall include the candidates
gathered in SectionSection 4.4 in the "candidates" transport header
parameter as well as the server's username and password. In the case
that there are no valid candidate pairs with the combination of the
client and servers candidates, a 480 (ICE Processing Failed) error
response shall be returned which must include the servers'
candidates. The return of a 480 error may allow both the server and
client to release its candidates.
S->C: RTSP/2.0 200 OK
CSeq: 302
Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; candidates = "
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m
4.6. Server to Client ICE Connectivity Checks
The server shall start the connectivity checks following the
procedures described in Section 5.7 and 5.8 of [I-D.ietf-mmusic-ice]
unless it is configured to use the high-reachability option. If it
is then it can suppress its own checks until the servers checks are
triggered by the client's connectivity checks.
The server SHALL use a single pacer for all STUN transactions within
a single RTSP session, i.e across all media streams that are part of
the same RTSP session.
When a connectivity check from the client reaches the server it will
result in a triggered check from the server as specified in section
7.2.1.4 of [I-D.ietf-mmusic-ice]. This is why servers with a high
reachability address can wait until this triggered check to send out
any checks for itself so saving resources and mitigating the DDoS
potential.
4.7. Client to Server ICE Connectivity Check
The client receives the SETUP response and learns the candidate
address to use for the connectivity checks. The client shall
initiate its connectivity check, following the procedures in Section
6 of [I-D.ietf-mmusic-ice].
Aggressive nomination SHALL be used with RTSP. This doesn't have the
negative impact that it has in offer/answer as media playing only
starts after issuing a PLAY request.
4.8. Client Connectivity Checks Complete
When the client has concluded its connectivity checks and has
correspondingly received the server connectivity checks on the
promoted candidates for all the media components, it can issue a PLAY
request. If the client has locally determined that its checks have
failed it may try providing an extended set of candidates and update
the server candidate list by issuing a new SETUP request for the
media stream.
If the client concluded its connectivity checks succesfully and
therefore sent a PLAY request but the server have not concluded
successfully, the server will respond with a 480 (ICE Processing
Failed). Upon receiving the 480 (ICE Processing Failed) response,
then the client may send a new SETUP request assuming it has any new
information that can be included in the candidate list.
4.9. Server Connectivity Checks Complete
When the RTSP server receives a PLAY request, it checks to see that
the connectivity checks have concluded successfully and only then
will it play the stream. If there is a problem with the checks then
the server sends to the client either a new 150 (ICE connectivity
checks in progress) response to show that it is still working on the
connectivity checks or a new 480 response to indicate a failure of
the checks. If the checks are successful then the server sends a 200
OK response and starts delivering media. The new RTSP errors add to
the list in Table 4 in [I-D.ietf-mmusic-rfc2326bis] as below:
4.10. Releasing Candidates
Both server and client may release its non nominated candidates as
soon as a 200 PLAY response has been issued/received.
4.11. Steady State
The client will continue to use STUN to send keep-alive for the used
bindings. This is important as normally RTSP play mode sessions only
contain traffic from the server to the client so the bindings in the
NAT needs to be refreshed by the cleint to server traffic provided by
the STUN keep-alive.
4.12. re-SETUP
If the client decides to change any parameter related to the media
stream SETUP it will send a new SETUP request. In this new SETUP
request the client SHALL include a new different username and
password to use in the ICE processing. This request will also cause
the ICE processing to start from the beginning again.
If the RTSP session is in playing state at the time of sending the
SETUP request, the ICE connectivity checks SHALL use Regular
nomination. Any ongoing media delivery continues on the previously
nominated candidate pairs until the new pairs have been nominated for
the individual candidate. Once the nomination of the new candidate
pair has completed, all unused candidates may be released.
5. ICE and Proxies
RTSP allows for proxies which can be of two fundamental types
depending if they relay and potentially cache the media or not.
Their differing impact on the RTSP NAT traversal solution including
backwards compatibility is explained below.
5.1. Media Handling Proxies
An RTSP proxy that relays or caches the media stream for a particular
media session can be considered to split the media transport into two
parts: A media transport between the server and the proxy according
to the proxies need, and delivery from the proxy to the client. This
split means that the NAT traversal solution will need to be run on
each individual media leg according to need.
It is RECOMMENDED that any media handling proxy support the media NAT
traversal defined within this specification. This is for two
reasons: Firstly to enable clients to perform NAT traversal for the
media between the proxy and itself and secondly to allow the proxy to
be topology independent so able to support performing NAT traversal
for non-NAT traversal capable clients present in the same address
domain.
For a proxy to support the media NAT traversal defined in this
specification a proxy will need to implement the solution fully and
be ready as both a controlling and a controlled ICE peer. The proxy
also SHALL include the "setup.ice-d-m" feature tag in any applicable
capability negotiation headers, such as "Proxy-Supported".
5.2. Signalling Only Proxies
A signalling only proxy handles only the RTSP signalling and does not
have the media relayed through proxy functions. This type of proxy
is not likely to work unless the media NAT traversal solution is in
place between the client and the server, because the DoS protection
measures usually prevent media delivery to other addresses other than
from where the RTSP signalling arrives at the server.
The solution for the Signalling Only proxy is that it must forward
the RTSP SETUP requests including any transport specification with
the "D-ICE" lower layer and the related transport parameters. A
proxy supporting this functionality SHOULD indicate its capability by
always including the "setup.ice-d-m" feature tag in the "Proxy-
Supported" header.
5.3. Non-supporting Proxies
A media handling proxy that doesn't support the ICE media NAT
traversal specified here is assumed to remove the transport
specification and use any of the lower prioritized transport
specifications if provided by the requester. The specification of
such a non ICE transport enables the negotiation to complete,
although with a less prefered method as a NAT between the proxy and
the client will result in failure of the media path.
A non-media handling transport proxy is expected to ignore and simply
forward all unknown transport specifications, however, this can only
be guaranteed for proxies following the published RTSP 2.0
specification.
Unfortunately the usage of the "setup.ice-d-m" feature tag in the
proxy-require will have contradicting results. For a non ICE
supporting media handling proxy, the inclusion of the feature tag
will result in aborting the setup and indicating that it isn't
supported, which is desirable if you want to provide other fallbacks
or other transport configurations to handle the situation. For non-
supporting non-media handling proxies the result will also result in
aborting the setup, however, setup might have worked if the proxy-
require tag wasn't present. This variance in results makes usage of
proxy-require not recommended. We recommend instead the usage of the
Supported header to force proxies to include the feature tags they
support in the proxy-supported which will provide a positive
indication when all proxies in the chain between the client and
server support the functionality. Even if not explicitly indicating
support, any SETUP response including a transport specification with
"D-ICE" will be implicit indication that the proxy chain supports at
least passthrough of this media.
6. RTP and RTCP Multiplexing
[I-D.ietf-avt-rtp-and-rtcp-mux] specifies how and when RTP and RTCP
can be multiplexed on the same port. This multiplexing is highly
recommended to combine with ICE as it makes RTP and RTCP only need a
single component per media stream instead of two, so reducing the
load on the connectivity checks.
To enable signalling for the usage of RTP and RTCP multiplexing a new
RTSP transport header parameter is defined. The formal syntax (ABNF
[RFC5234]) of this parameter is the following:
tr-parameter =/ SEMI rtcp-mux-par
rtcp-mux-par = "rtp-rtcp-mux"
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
The "rtp-rtcp-mux" parameter MAY be included in any transport
specification that use RTP where RTP and RTCP multiplexing is desired
and indicates in a SETUP request that multiplexing is requested. If
the SETUP response also includes the parameter then RTP and RTCP
multiplexing SHALL be used for that transport specification. A SETUP
request may indicate address information for both RTP and RTCP for
backwards compatibility reasons. If RTP and RTCP multiplexing is
used then only the information specified for RTP SHALL be used.
For capability exchange, an RTSP feature tag for RTP and RTCP
multiplexing is defined: "setup.rtp-mux".
RTSP servers and clients that supports "D-ICE" lower layer transport
in combination with RTP SHALL also implement RTP and RTCP
multiplexing as specified in this section and
[I-D.ietf-avt-rtp-and-rtcp-mux].
7. Open Issues
Below is listed the known open issues and questions that needs to be
resolved:
1. Need a descriptive section on how ICE works for RTSP folks.
2. No solution has been specified for how RTSP server's can initiate
a ICE restart. Either to add candidates or to reinitate the
connectivity checks in response to lost bindings. Basically
required to find a solution for this.
3. Does we need to support multiple components?
4. Is the role and processing the most optimal one that can be used?
8. IANA Considerations
This document request registration in a number of registries, both
for RTSP and SDP.
8.1. RTSP Feature Tags
This document request that two RTSP feature tags are registered in
the "RTSP feature tag" registry:
setup.rtp-mux See Section Section 6.
setup.ice-d-m See Section Section 3.4.
8.2. Transport Protocol Specifications
This document needs to register a number of transport protocol
combinations are registered in RTSP's "Transport Protocol
Specifications" registry.
"RTP/AVP/D-ICE":
"RTP/AVPF/D-ICE":
"RTP/SAVP/D-ICE":
"RTP/SAVPF/D-ICE":
8.3. RTSP Transport Parameters
This document requests that 4 transport parameters are registered in
RTSP's "Transport Parameters":
"candidates": See Section Section 3.2.
"ICE-Password": See Section Section 3.3.
"ICE-Userfrag": See Section Section 3.3.
"rtp-rtcp-mux": See Section Section 6.
8.4. RTSP Status Codes
This document requests that 2 assignments are done in the "RTSP
Status Codes" registry. The suggested values are:
150: See Section Section 3.5.1.
480: See Section Section 3.5.2.
8.5. SDP Attribute
The registration of one SDP attribute is requested:
SDP Attribute ("att-field"):
Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal
Type of name: att-field
Type of attribute: Session level only
Subject to charset: No
Purpose: RFC XXXX
Reference: RFC XXXX
Values: No values defined.
Contact: Magnus Westerlund
E-mail: magnus.westerlund@ericsson.com
phone: +46 8 404 82 87
9. Security Considerations
ICE [I-D.ietf-mmusic-ice] provides an extensive discussion on
security considerations which applies here as well.
9.1. ICE and RTSP
A long-standing risk with transmitting a packet stream over UDP is
that the host may not be interested in receiving the stream. On
today's Internet many hosts are behind NATs or operate host firewalls
which do not respond to unsolicited packets with an ICMP port
unreachable error. Thus, an attacker can construct SDP with a
victim's IP address and cause a flood of media packets to be sent to
a victim. The addition of ICE, as described in this document,
provides protection from the attack described above. By performing
the ICE connectivity check, the media server receives confirmation
that the RTSP client wants the media. While this protection could
also be implemented by requiring the IP addresses in the SDP match
the IP address of the RTSP signaling packet, such a mechanism does
not protect other hosts with the same IP address (such as behind the
same NAT), and such a mechanism would prohibit separating the RTSP
controller from the media playout device (e.g., an IP-enabled remote
control and an IP-enabled television).
10. Acknowledgements
The authors would like to thank Remi Denis-Courmont for suggesting
the method of integrating ICE in RTSP signalling, Dan Wing for help
with the security section and numerous other issues.
11. References
11.1. Normative References
[I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress),
February 2008.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., "Real Time Streaming Protocol 2.0 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
(RTSP)", draft-ietf-mmusic-rfc2326bis-15 (work in and M. Stiemerling, "Real Time Streaming Protocol 2.0
progress), June 2007. (RTSP)", draft-ietf-mmusic-rfc2326bis-17 (work in
progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Streaming Protocol (RTSP)", RFC 2326, April 1998. Description Protocol", RFC 4566, July 2006.
8.2. Informative References [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informative References
[I-D.ietf-mmusic-rtsp-nat-evaluation] [I-D.ietf-mmusic-rtsp-nat-evaluation]
Westerlund, M., "The evaluation of different NAT traversal Westerlund, M., "The evaluation of different NAT traversal
Techniques for media controlled by Real-time Streaming Techniques for media controlled by Real-time Streaming
Protocol (RTSP)", draft-ietf-mmusic-rtsp-nat-evaluation-00 Protocol (RTSP)", draft-ietf-mmusic-rtsp-nat-evaluation-00
(work in progress), July 2007. (work in progress), July 2007.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
January 2001. January 2001.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
Authors' Addresses Authors' Addresses
Jeff Goldberg
Cisco
11 New Square, Bedfont Lakes
Feltham,, Middx TW14 8HA
United Kingdom
Phone: +44 20 8824 1000
Fax:
Email: jgoldber@cisco.com
URI:
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Torshamsgatan 23 Torshamsgatan 23
Stockholm, SE-164 80 Stockholm, SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Fax: Fax:
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
URI: URI:
Thomas Zeng Thomas Zeng
Nextwave Wireless, Inc.
12670 High Bluff Drive
San Diego, CA 92130
USA
Phone: Phone: +1 858 480 3100
Fax: Fax:
Email: thomas.zeng@gmail.com Email: thomas.zeng@gmail.com
URI: URI:
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 44 change blocks. 
142 lines changed or deleted 950 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/