draft-ietf-mmusic-rtsp-nat-evaluation-04.txt   draft-ietf-mmusic-rtsp-nat-evaluation-05.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Zeng Intended status: Informational T. Zeng
Expires: April 29, 2012 October 27, 2011 Expires: November 8, 2012 May 7, 2012
The Evaluation of Different Network Addres Translator (NAT) Traversal The Evaluation of Different Network Addres Translator (NAT) Traversal
Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-evaluation-04 draft-ietf-mmusic-rtsp-nat-evaluation-05
Abstract Abstract
This document describes several Network Address Translator (NAT) This document describes several Network Address Translator (NAT)
traversal techniques that was considered to be used by Real-time traversal techniques that was considered to be used by Real-time
Streaming Protocol (RTSP). Each technique includes a description on Streaming Protocol (RTSP). Each technique includes a description on
how it would be used, the security implications of using it and any how it would be used, the security implications of using it and any
other deployment considerations it has. There are also disussions on other deployment considerations it has. There are also disussions on
how NAT traversal techniques relates to firewalls and how each how NAT traversal techniques relates to firewalls and how each
technique can be applied in different use cases. These findings technique can be applied in different use cases. These findings
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 29, 2012. This Internet-Draft will expire on November 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 30 skipping to change at page 3, line 30
4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 14 4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 14
4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 15 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 15
4.1.6. Deployment Considerations . . . . . . . . . . . . . . 15 4.1.6. Deployment Considerations . . . . . . . . . . . . . . 15
4.1.7. Security Considerations . . . . . . . . . . . . . . . 17 4.1.7. Security Considerations . . . . . . . . . . . . . . . 17
4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19 4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19
4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 20 4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 20
4.2.4. Deployment Considerations . . . . . . . . . . . . . . 21 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 21
4.2.5. Security Consideration . . . . . . . . . . . . . . . . 21 4.2.5. Security Consideration . . . . . . . . . . . . . . . . 21
4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 21 4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 22
4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 22
4.3.3. Deployment Considerations . . . . . . . . . . . . . . 22 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 23
4.3.4. Security Consideration . . . . . . . . . . . . . . . . 23 4.3.4. Security Consideration . . . . . . . . . . . . . . . . 23
4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 24 4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 24
4.4. Application Level Gateways . . . . . . . . . . . . . . . . 26 4.4. Application Level Gateways . . . . . . . . . . . . . . . . 26
4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 26 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 26
4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 27 4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 27
4.4.3. Deployment Considerations . . . . . . . . . . . . . . 28 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 28
4.4.4. Security Considerations . . . . . . . . . . . . . . . 28 4.4.4. Security Considerations . . . . . . . . . . . . . . . 28
4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 28 4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 28
4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28
4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 29 4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 29
skipping to change at page 6, line 8 skipping to change at page 6, line 8
This document is capturing the evaluation done in the process to This document is capturing the evaluation done in the process to
recommend FW/NAT traversal methods for RTSP streaming servers based recommend FW/NAT traversal methods for RTSP streaming servers based
on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec on RFC 2326 [RFC2326] as well as the RTSP 2.0 core spec
[I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT [I-D.ietf-mmusic-rfc2326bis]. The evaluation is focused on NAT
traversal for the media streams carried over User Datagram Protocol traversal for the media streams carried over User Datagram Protocol
(UDP) [RFC0768]. Where Real-time Transport Protocol (RTP) [RFC3550] (UDP) [RFC0768]. Where Real-time Transport Protocol (RTP) [RFC3550]
over UDP being the main case for such usage. The findings should be over UDP being the main case for such usage. The findings should be
applicable to other protocols as long as they have similar applicable to other protocols as long as they have similar
properties. properties.
The resulting ICE-based RTSP NAT traversal mechanism is specified in
"A Network Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)"
[I-D.ietf-mmusic-rtsp-nat].
1.1. Network Address Translators 1.1. Network Address Translators
Readers are urged to refer to "IP Network Address Translator (NAT) Readers are urged to refer to "IP Network Address Translator (NAT)
Terminology and Considerations" [RFC2663] for information on NAT Terminology and Considerations" [RFC2663] for information on NAT
taxonomy and terminology. Traditional NAT is the most common type of taxonomy and terminology. Traditional NAT is the most common type of
NAT device deployed. Readers may refer to "Traditional IP Network NAT device deployed. Readers may refer to "Traditional IP Network
Address Translator (Traditional NAT)" [RFC3022] for detailed Address Translator (Traditional NAT)" [RFC3022] for detailed
information on traditional NAT. Traditional NAT has two main information on traditional NAT. Traditional NAT has two main
varieties -- Basic NAT and Network Address/Port Translator (NAPT). varieties -- Basic NAT and Network Address/Port Translator (NAPT).
skipping to change at page 11, line 4 skipping to change at page 11, line 4
different. They also vary in security levels. In the following different. They also vary in security levels. In the following
sections, each technique is outlined in details with discussions on sections, each technique is outlined in details with discussions on
the corresponding advantages and disadvantages. the corresponding advantages and disadvantages.
This section includes NAT traversal techniques that have not been This section includes NAT traversal techniques that have not been
formally specified anywhere else. The overview section of this formally specified anywhere else. The overview section of this
document may be the only publicly available specification of some of document may be the only publicly available specification of some of
the NAT traversal techniques. However that is no real barrier the NAT traversal techniques. However that is no real barrier
against doing an evaluation of the NAT traversal technique. Some against doing an evaluation of the NAT traversal technique. Some
other techniques are currently (at the time of writing) in a state of other techniques are currently (at the time of writing) in a state of
flux due to ongoing standardization work on these techniques, e.g. flux due to ongoing standardization work on these techniques or has
RTP No-Op [I-D.ietf-avt-rtp-no-op]. been not been progressed within IETF after the intiial evaluation in
this document, e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op].
4.1. STUN 4.1. STUN
4.1.1. Introduction 4.1.1. Introduction
STUN - "Simple Traversal of UDP Through Network Address Translators" STUN - "Simple Traversal of UDP Through Network Address Translators"
[RFC3489][RFC5389] is a standardized protocol that allows a client to [RFC3489][RFC5389] is a standardized protocol that allows a client to
use secure means to discover the presence of a NAT between himself use secure means to discover the presence of a NAT between himself
and the STUN server. The client uses the STUN server to discover the and the STUN server. The client uses the STUN server to discover the
address mappings assigned by the NAT. STUN is a client-server address mappings assigned by the NAT. STUN is a client-server
skipping to change at page 19, line 39 skipping to change at page 19, line 43
1. The ICE usage begins in the SDP. The SDP for the service 1. The ICE usage begins in the SDP. The SDP for the service
indicates that ICE is supported at the server. No candidates can indicates that ICE is supported at the server. No candidates can
be given here as that would not work with the on demand, DNS load be given here as that would not work with the on demand, DNS load
balancing, etc., that make a SDP indicate a resource on a server balancing, etc., that make a SDP indicate a resource on a server
park rather than a specific machine. park rather than a specific machine.
2. The client gathers addresses and puts together its candidate for 2. The client gathers addresses and puts together its candidate for
each media stream indicated in the session description. each media stream indicated in the session description.
3. In each SETUP request the client includes its candidates, 3. In each SETUP request the client includes its candidates in a ICE
promoting one for primary usage. This indicates for the server specific transport specification. This indicates for the server
the ICE support by the client. One candidate is the primary the ICE support by the client. One candidate is the most
candidate and here the prioritization for this address should be prioritized candidate and here the prioritization for this
somewhat different compared to SIP. High performance rather than address should be somewhat different compared to SIP. High
always successful is to recommended as it is most likely to be a performance rather than always successful is to recommended as it
server in the public. is most likely to be a server in the public.
4. The server responds to the SETUP (200 OK) for each media stream 4. The server responds to the SETUP (200 OK) for each media stream
with its candidates. A server with a public address usually only with its candidates. A server with a public address usually only
provides a single ICE candidate. Also here one candidate is the provides a single ICE candidate. Also here one candidate is the
server primary address. server primary address.
5. The connectivity checks are performed. For the server the 5. The connectivity checks are performed. For the server the
connectivity checks from the server to the clients have an connectivity checks from the server to the clients have an
additional usage. They verify that there is someone willingly to additional usage. They verify that there is someone willingly to
receive the media, thus protecting itself from performing receive the media, thus protecting itself from performing
unknowingly an DoS attack. unknowingly an DoS attack.
6. Connectivity checks from the client's primary to the server's 6. Connectivity checks from the client promoting a candiadate pair
primary was successful. Thus no further SETUP requests are was successful. Thus no further SETUP requests are necessary and
necessary and processing can proceed with step 7. If another processing can proceed with step 7. If another address than the
address than the primary has been verified by the client to work, primary has been verified by the client to work, that address may
that address may then be promoted for usage in a SETUP request then be promoted for usage in a SETUP request (Goto 7). If the
(Goto 7). If the checks for the availble candidates failed and checks for the availble candidates failed and If further
If further candidates have been derived during the connectivity candidates have been derived during the connectivity checks, then
checks, then those can be signalled in new candidate lines in those can be signalled in new candidate lines in SETUP request
SETUP request updating the list (Goto 5). updating the list (Goto 5).
7. Client issues PLAY request. If the server also has completed its 7. Client issues PLAY request. If the server also has completed its
connectivity checks for this primary addresses (based on username connectivity checks for the promoted candidate pair (based on
as it may be derived addresses if the client was behind NAT) then username as it may be derived addresses if the client was behind
it can directly answer 200 OK (Goto 8). If the connectivity NAT) then it can directly answer 200 OK (Goto 8). If the
check has not yet completed it responds with a 1xx code to connectivity check has not yet completed it responds with a 1xx
indicate that it is verifying the connectivity. If that fails code to indicate that it is verifying the connectivity. If that
within the set timeout an error is reported back. Client needs fails within the set timeout an error is reported back. Client
to go back to 6. needs to go back to 6.
8. Process completed media can be delivered. ICE testing ports may 8. Process completed media can be delivered. ICE candidates not
be released. used may be released.
To keep media paths alive the client needs to periodically send data To keep media paths alive the client needs to periodically send data
to the server. This could be realized with either STUN or RTP No-op to the server. This will be realized with STUN. RTCP sent by client
[I-D.ietf-avt-rtp-no-op] packets. RTCP sent by client should be able should be able to keep RTCP open but STUN will also be used based on
to keep RTCP open. the same motivations as for ICE for SIP.
4.2.3. Implementation burden of ICE 4.2.3. Implementation burden of ICE
The usage of ICE will require that a number of new protocols and new The usage of ICE will require that a number of new protocols and new
RTSP/SDP features be implemented. This makes ICE the solution that RTSP/SDP features be implemented. This makes ICE the solution that
has the largest impact on client and server implementations amongst has the largest impact on client and server implementations amongst
all the NAT/FW traversal methods in this document. all the NAT/FW traversal methods in this document.
RTSP server implementation requirements are: RTSP server implementation requirements are:
skipping to change at page 21, line 32 skipping to change at page 21, line 35
domains may be required to get TCP through). domains may be required to get TCP through).
o Improves defenses against DDOS attacks, as media receiving client o Improves defenses against DDOS attacks, as media receiving client
requires authentications, via STUN on its media reception ports. requires authentications, via STUN on its media reception ports.
Disadvantages: Disadvantages:
o Increases the setup delay with at least the amount of time it o Increases the setup delay with at least the amount of time it
takes for the server to perform its STUN requests. takes for the server to perform its STUN requests.
o Assumes that it is possible to de-multiplex between media packets o Assumes that it is possible to de-multiplex between the packets of
and STUN packets. the media protocol and STUN packets.
o Has fairly high implementation burden put on both RTSP server and o Has fairly high implementation burden put on both RTSP server and
client. client.
4.2.5. Security Consideration 4.2.5. Security Consideration
One should review the security consideration section of ICE and STUN One should review the security consideration section of ICE and STUN
to understand that ICE is contains some potential issues. However to understand that ICE contains some potential issues. However these
these can be avoided by a correctly utilizing ICE in RTSP. In fact can be avoided by a correctly utilizing ICE in RTSP. In fact ICE do
ICE do help avoid the DDoS issue with RTSP substantially as it help avoid the DDoS issue with RTSP substantially as it reduces the
reduces the possibility for a DDoS using RTSP servers to attackers possibility for a DDoS using RTSP servers to attackers that are on-
that are on-path between the RTSP server and the target and capable path between the RTSP server and the target and capable of
of intercepting the STUN connectivity check packets and correctly intercepting the STUN connectivity check packets and correctly send a
send a response to the server. response to the server.
4.3. Symmetric RTP 4.3. Symmetric RTP
4.3.1. Introduction 4.3.1. Introduction
Symmetric RTP is a NAT traversal solution that is based on requiring Symmetric RTP is a NAT traversal solution that is based on requiring
RTSP clients to send UDP packets to the server's media output ports. RTSP clients to send UDP packets to the server's media output ports.
Conventionally, RTSP servers send RTP packets in one direction: from Conventionally, RTSP servers send RTP packets in one direction: from
server to client. Symmetric RTP is similar to connection-oriented server to client. Symmetric RTP is similar to connection-oriented
traffic, where one side (e.g., the RTSP client) first "connects" by traffic, where one side (e.g., the RTSP client) first "connects" by
sending a RTP packet to the other side's RTP port, the recipient then sending a RTP packet to the other side's RTP port, the recipient then
replies to the originating IP and port. replies to the originating IP and port. This method is also referred
to as "Late binding".
Specifically, when the RTSP server receives the "connect" RTP packet Specifically, when the RTSP server receives the "connect" RTP packet
(a.k.a. FW packet, since it is used to punch a hole in the FW/NAT (a.k.a. FW packet, since it is used to punch a hole in the FW/NAT
and to aid the server for port binding and address mapping) from its and to aid the server for port binding and address mapping) from its
client, it copies the source IP and Port number and uses them as client, it copies the source IP and Port number and uses them as
delivery address for media packets. By having the server send media delivery address for media packets. By having the server send media
traffic back the same way as the client's packet are sent to the traffic back the same way as the client's packet are sent to the
server, address mappings will be honored. Therefore this technique server, address mappings will be honored. Therefore this technique
works for all types of NATs. However, it does require server works for all types of NATs. However, it does require server
modifications. Unless there is built-in protection mechanism, modifications. Unless there is built-in protection mechanism,
skipping to change at page 24, line 41 skipping to change at page 24, line 45
To improve the security against attackers the random tag's length To improve the security against attackers the random tag's length
could be increased. To achieve a longer random tag while still using could be increased. To achieve a longer random tag while still using
RTP and RTCP, it will be necessary to develop RTP and RTCP payload RTP and RTCP, it will be necessary to develop RTP and RTCP payload
formats for carrying the random tag. formats for carrying the random tag.
4.3.5. A Variation to Symmetric RTP 4.3.5. A Variation to Symmetric RTP
Symmetric RTP requires a valid RTP format in the FW packet, which is Symmetric RTP requires a valid RTP format in the FW packet, which is
the first packet that the client sends to the server to set up the first packet that the client sends to the server to set up
virtual RTP connection. There is currently no appropriate RTP packet virtual RTP connection. There is currently no appropriate RTP packet
format for this purpose, although the No-Op format is a proposal to format for this purpose, although the No-Op format was a proposal to
fix the problem [I-D.ietf-avt-rtp-no-op]. There exists a RFC that fix the problem [I-D.ietf-avt-rtp-no-op]. However, that work has
discusses the implication of different type of packets as keep-alives been abandoned. There exists a RFC that discusses the implication of
for RTP [RFC6263] and its findings are very relevant to the FW different type of packets as keep-alives for RTP [RFC6263] and its
packet. findings are very relevant to the FW packet.
Meanwhile, there has been FW traversal techniques deployed in the Meanwhile, there has been FW traversal techniques deployed in the
wireless streaming market place that use non-RTP messages as FW wireless streaming market place that use non-RTP messages as FW
packets. This section attempts to summarize a subset of those packets. This section attempts to summarize a subset of those
solutions that happens to use a variation to the standard symmetric solutions that happens to use a variation to the standard symmetric
RTP solution. RTP solution.
In this variation of symmetric RTP, the FW packet is a small UDP In this variation of symmetric RTP, the FW packet is a small UDP
packet that does not contain RTP header. Hence the solution can no packet that does not contain RTP header. Hence the solution can no
longer be called symmetric RTP, yet it employs the same technique for longer be called symmetric RTP, yet it employs the same technique for
skipping to change at page 25, line 22 skipping to change at page 25, line 26
packets as keep-alive messages for the NAT mappings. packets as keep-alive messages for the NAT mappings.
The server listens on its RTP-media output port, and tries to decode The server listens on its RTP-media output port, and tries to decode
any received UDP packet as FW packet. This is valid since an RTSP any received UDP packet as FW packet. This is valid since an RTSP
server is not expecting RTP traffic from the RTSP client. Then, it server is not expecting RTP traffic from the RTSP client. Then, it
can correlate the FW packet with the RTSP client's session ID or the can correlate the FW packet with the RTSP client's session ID or the
client's SSRC, and record the NAT bindings accordingly. The server client's SSRC, and record the NAT bindings accordingly. The server
then sends a FW packet as the response to the client. then sends a FW packet as the response to the client.
The FW packet can contain the SSRC to identify the RTP stream, and The FW packet can contain the SSRC to identify the RTP stream, and
can be made no bigger than 12 bytes, making it distinctively care must be taken if the packet is bigger than 12 bytes, ensuring
different from RTP packets, whose header size is 12 bytes. that it is distinctively different from RTP packets, whose header
size is 12 bytes.
RTSP signaling can be added to do the following: RTSP signaling can be added to do the following:
1. Enables or disables such FW message exchanges. When the FW/NAT 1. Enables or disables such FW message exchanges. When the FW/NAT
has an RTSP-aware ALG, it is possible to disable FW message has an RTSP-aware ALG, it is possible to disable FW message
exchange and let ALG works out the address and port mappings. exchange and let ALG works out the address and port mappings.
2. Configures the number of re-tries and the re-try interval of the 2. Configures the number of re-tries and the re-try interval of the
FW message exchanges. FW message exchanges.
skipping to change at page 34, line 35 skipping to change at page 34, line 35
TURN | Yes | Yes | No | No | Yes | TURN | Yes | Yes | No | No | Yes |
------------------------------------------------ ------------------------------------------------
The different techniques was discussed in the MMUSIC WG. It was The different techniques was discussed in the MMUSIC WG. It was
established that the WG would pursue an ICE based solution due to its established that the WG would pursue an ICE based solution due to its
generality and capability of handle also servers delivering media generality and capability of handle also servers delivering media
from behind NATs. There has been some discussion if the increased from behind NATs. There has been some discussion if the increased
implementation burden of ICE is motivated compared to a 3-W SymRTP implementation burden of ICE is motivated compared to a 3-W SymRTP
solution for this generality. solution for this generality.
The ICE based RTSP NAT traversal solution is specified in "A Network
Address Translator (NAT) Traversal mechanism for media controlled by
Real-Time Streaming Protocol (RTSP)" [I-D.ietf-mmusic-rtsp-nat].
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 8. Security Considerations
In preceding sessions we have discussed security merits of each and In preceding sessions we have discussed security merits of each and
skipping to change at page 35, line 48 skipping to change at page 36, line 6
10. Informative References 10. Informative References
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-29 (work in
progress), March 2011. progress), March 2012.
[I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-12 (work in progress),
May 2012.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[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.
 End of changes. 21 change blocks. 
55 lines changed or deleted 75 lines changed or added

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