draft-ietf-mmusic-rtsp-nat-18.txt   draft-ietf-mmusic-rtsp-nat-19.txt 
Network Working Group J. Goldberg Network Working Group J. Goldberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: July 26, 2014 Ericsson Expires: August 3, 2014 Ericsson
T. Zeng T. Zeng
Nextwave Wireless, Inc. Nextwave Wireless, Inc.
January 22, 2014 January 30, 2014
A Network Address Translator (NAT) Traversal Mechanism for Media A 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-18 draft-ietf-mmusic-rtsp-nat-19
Abstract Abstract
This document defines a solution for Network Address Translation This document defines a solution for Network Address Translation
(NAT) traversal for datagram based media streams set up and (NAT) traversal for datagram based media streams set up and
controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). controlled with Real-time Streaming Protocol version 2 (RTSP 2.0).
It uses Interactive Connectivity Establishment (ICE) adapted to use It uses Interactive Connectivity Establishment (ICE) adapted to use
RTSP as a signalling channel, defining the necessary RTSP extensions RTSP as a signalling channel, defining the necessary RTSP extensions
and procedures. and procedures.
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 July 26, 2014. This Internet-Draft will expire on August 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 10, line 29 skipping to change at page 10, line 29
for candidates that have <transport> set to TCP and MUST NOT be for candidates that have <transport> set to TCP and MUST NOT be
included for other transport types, including UDP, unless included for other transport types, including UDP, unless
explicitly specified for that transport protocol. explicitly specified for that transport protocol.
<extension-att-name> and <extension-att-value>: These are prototypes <extension-att-name> and <extension-att-value>: These are prototypes
for future extensions of the candidate line. These templates are for future extensions of the candidate line. These templates are
widely defined, as they allow any 8-bit value except NUL, CR, or widely defined, as they allow any 8-bit value except NUL, CR, or
LF. However as this will occur within this structured line that LF. However as this will occur within this structured line that
uses the DQ, SEMI, SWS and SP ABNF constructs as delimiters, thus uses the DQ, SEMI, SWS and SP ABNF constructs as delimiters, thus
these delimeter characters needs to be escaped if they would occur these delimeter characters needs to be escaped if they would occur
within an extension. The escpae mechanism that MUST be used are within an extension. The escape mechanism that MUST be used is
the Percent-Encoding defined in Section 2.1 of [RFC3986]. This the Percent-Encoding defined in Section 2.1 of [RFC3986]. This
mechanism is selected as it anyway needs to be supported in an mechanism is selected as it anyway needs to be supported in an
RTSP implementation to deal with URIs. The byte values (in hex) RTSP implementation to deal with URIs. The byte values (in hex)
that MUST be escaped are the following ones: 0x09, 0x20, 0x22, that MUST be escaped are the following ones: 0x09, 0x20, 0x22,
0x25, 0x3B. 0x25, 0x3B.
4.3. ICE Password and Username Transport Header Parameters 4.3. ICE Password and Username Transport Header Parameters
The ICE password and username for each agent needs to be transported The ICE password and username for each agent needs to be transported
using RTSP. For that purpose new Transport header parameters are using RTSP. For that purpose new Transport header parameters are
skipping to change at page 14, line 16 skipping to change at page 14, line 16
request will trigger large amount of STUN connectivity checks towards request will trigger large amount of STUN connectivity checks towards
provided candidate addresses. provided candidate addresses.
6. Detailed Solution 6. Detailed Solution
This section describes in detail how the interaction and flow of ICE This section describes in detail how the interaction and flow of ICE
works with RTSP messages. works with RTSP messages.
6.1. Session description and RTSP DESCRIBE (optional) 6.1. Session description and RTSP DESCRIBE (optional)
The RTSP server are RECOMMENDED indicate it has support for ICE by The RTSP server is RECOMMENDED indicate it has support for ICE by
sending the "a=rtsp-ice-d-m" SDP attribute in the response to the sending the "a=rtsp-ice-d-m" SDP attribute in the response to the
RTSP DESCRIBE message if SDP is used. This allows RTSP clients to RTSP DESCRIBE message if SDP is used. This allows RTSP clients to
only send the new ICE exchanges with servers that support ICE thereby only send the new ICE exchanges with servers that support ICE thereby
limiting the overhead on current non-ICE supporting RTSP servers. limiting the overhead on current non-ICE supporting RTSP servers.
When not using RTSP DESCRIBE it is still RECOMMENDED to use the SDP When not using RTSP DESCRIBE it is still RECOMMENDED to use the SDP
attribute for the session description. attribute for the session description.
A client can also use the DESCRIBE request to determine explicitly if A client can also use the DESCRIBE request to determine explicitly if
both server and any proxies support ICE. The client includes the both server and any proxies support ICE. The client includes the
"Supported" header with its supported feature tags, including "Supported" header with its supported feature tags, including
skipping to change at page 21, line 22 skipping to change at page 21, line 22
Even if otherwise not supporting SETUP during PLAY state for other Even if otherwise not supporting SETUP during PLAY state for other
purposes, the server SHALL support SETUP requests in PLAY state, as purposes, the server SHALL support SETUP requests in PLAY state, as
long as the SETUP changes only the ICE parameters, which are: ICE- long as the SETUP changes only the ICE parameters, which are: ICE-
Password, ICE-ufrag and the content of ICE candidates. Password, ICE-ufrag and the content of ICE candidates.
If the RTSP session is in playing state at the time of sending the If the RTSP session is in playing state at the time of sending the
SETUP request requiring ICE restart, then the ICE connectivity checks SETUP request requiring ICE restart, then the ICE connectivity checks
SHALL use Regular nomination. Any ongoing media delivery continues SHALL use Regular nomination. Any ongoing media delivery continues
on the previously nominated candidate pairs until the new pairs have on the previously nominated candidate pairs until the new pairs have
been nominated for the individual candidate. Once the nomination of been nominated for the individual media stream. Once the nomination
the new candidate pair has completed, all unused candidates may be of the new candidate pair has completed, all unused candidates may be
released. If the ICE processing fails and no new candidate pairs are released. If the ICE processing fails and no new candidate pairs are
promoted for use, then one MAY continue to use the previously nominated for use, then one MAY continue to use the previously
nominated candidate pairs while they still function. If they have nominated candidate pairs while they still function. If they appear
appear to fail to transport media packets anymore then the client can to fail to transport media packets anymore then the client can select
select between two actions. First, if it has any actions available between two actions. First, if it can attempt any actions available
that might make ICE work, like trying another STUN/TURN server or that might make ICE work, like trying another STUN/TURN server, or
change the transport parameters it modifies the session, and if ICE change the transport parameters. Thus, it modifies the RTSP session,
is still to be used restart ICE. If the client is unable to modify and if ICE is still to be used, restart ICE once more. If the client
the ICE parameters, it MUST NOT restart the ICE processing, and is unable to modify the transport or ICE parameters, it MUST NOT
SHOULD terminate the RTSP session. restart the ICE processing, and SHOULD terminate the RTSP session.
6.13. Server Side Changes After Steady State 6.13. Server Side Changes After Steady State
A Server may require an ICE restart because of server side load A Server may require an ICE restart because of server side load
balancing or a failure resulting in an IP address and a port number balancing or a failure resulting in an IP address and a port number
change. In that case the server SHALL use the PLAY_NOTIFY method to change. In that case the server SHALL use the PLAY_NOTIFY method to
inform the client (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a inform the client (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a
new Notify-Reason header: ice-restart. The server will identify if new Notify-Reason header: ice-restart. The server will identify if
the change is for a single media or for the complete session by the change is for a single media or for the complete session by
including the corresponding URI in the PLAY_NOTIFY request. including the corresponding URI in the PLAY_NOTIFY request.
skipping to change at page 31, line 30 skipping to change at page 31, line 30
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
13.2. Informative References 13.2. Informative References
[I-D.ietf-mmusic-rtsp-nat-evaluation] [I-D.ietf-mmusic-rtsp-nat-evaluation]
Westerlund, M. and T. Zeng, "The Evaluation of Different Westerlund, M. and T. Zeng, "The Evaluation of Different
Network Address Translator (NAT) Traversal Techniques for Network Address Translator (NAT) Traversal Techniques for
Media Controlled by Real-time Streaming Protocol (RTSP)", Media Controlled by Real-time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-evaluation-11 (work in draft-ietf-mmusic-rtsp-nat-evaluation-12 (work in
progress), January 2014. progress), January 2014.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. 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, January Address Translator (Traditional NAT)", RFC 3022, January
2001. 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
 End of changes. 9 change blocks. 
18 lines changed or deleted 18 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/