draft-ietf-mmusic-rtsp-nat-13.txt   draft-ietf-mmusic-rtsp-nat-14.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: April 25, 2013 Ericsson Expires: May 19, 2013 Ericsson
T. Zeng T. Zeng
Nextwave Wireless, Inc. Nextwave Wireless, Inc.
October 22, 2012 November 15, 2012
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-13 draft-ietf-mmusic-rtsp-nat-14
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 setup and controlled (NAT) traversal for datagram based media streams setup and controlled
with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses
Interactive Connectivity Establishment (ICE) adapted to use RTSP as a Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
signalling channel, defining the necessary extra RTSP extensions and signalling channel, defining the necessary extra RTSP extensions and
procedures. 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 April 25, 2013. This Internet-Draft will expire on May 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
5.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 19 5.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 19
5.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.13. Server Side Changes After Steady State . . . . . . . . . . 20 5.13. Server Side Changes After Steady State . . . . . . . . . . 20
6. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 22 6. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 22 6.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 22
6.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22 6.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22
6.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 23 6.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 23
7. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 24 7. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 24
8. Fallback and Using Partial ICE functionality to improve 8. Fallback and Using Partial ICE functionality to improve
NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . . 24 NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 26 9.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 26
9.2. Transport Protocol Specifications . . . . . . . . . . . . 26 9.2. Transport Protocol Specifications . . . . . . . . . . . . 26
9.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 26 9.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 26
9.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 27 9.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 27
9.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 27 9.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 27
9.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 27 9.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0 Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0
[I-D.ietf-mmusic-rfc2326bis] are protocols used to setup and control [I-D.ietf-mmusic-rfc2326bis] are protocols used to setup and control
one or more media streams delivering media to receivers. It is one or more media streams delivering media to receivers. It is
RTSP's functionality of setting up media streams that cause serious RTSP's functionality of setting up media streams that cause serious
issues with Network Address Translators (NAT) [RFC3022] unless extra issues with Network Address Translators (NAT) [RFC3022] unless extra
provisions are taken by the protocol. There is thus a need for a NAT provisions are taken by the protocol. There is thus a need for a NAT
skipping to change at page 16, line 31 skipping to change at page 16, line 31
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Supported: setup.ice-d-m, setup.rtp.rtcp.mux Supported: setup.ice-d-m, setup.rtp.rtcp.mux
5.4. Gathering Candidates 5.4. Gathering Candidates
Upon receiving a SETUP request the server can determine what media Upon receiving a SETUP request the server can determine what media
resource should be delivered and which transport alternatives that resource should be delivered and which transport alternatives that
the client supports. If one based on D-ICE is on the list of the client supports. If one based on D-ICE is on the list of
supported transports and prefered among the supported, the below supported transports and preferred among the supported, the below
applies. applies.
The transport specification will provide which media protocol is to The transport specification will provide which media protocol is to
be used and based on this and the clients candidates, the server be used and based on this and the clients candidates, the server
determines the protocol and if it supports ICE with that protocol. determines the protocol and if it supports ICE with that protocol.
The server shall then gather its UDP candidates according to section The server shall then gather its UDP candidates according to section
4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5 4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5
of ICE TCP [RFC6544]. of ICE TCP [RFC6544].
Servers that have an address that is generally reachable by any Servers that have an address that is generally reachable by any
skipping to change at page 17, line 7 skipping to change at page 17, line 7
preferably a single one per (address family, media stream, media preferably a single one per (address family, media stream, media
component) tuple. Instead of gathering all possible addresses component) tuple. Instead of gathering all possible addresses
including relayed and server reflexive addresses, the server uses a including relayed and server reflexive addresses, the server uses a
single address per address family that it knows it should be single address per address family that it knows it should be
reachable by a client behind one or more NATs. The reason for this reachable by a client behind one or more NATs. The reason for this
special configuration is twofold: Firstly it reduces the load on the special configuration is twofold: Firstly it reduces the load on the
server in address gathering and in ICE processing during the server in address gathering and in ICE processing during the
connectivity checks. Secondly it will reduce the number of connectivity checks. Secondly it will reduce the number of
permutations for candidate pairs significantly thus potentially permutations for candidate pairs significantly thus potentially
speeding up the conclusion of the ICE processing. Note however that speeding up the conclusion of the ICE processing. Note however that
using this option on a server that doesn't fulfil the requirement of using this option on a server that doesn't fulfill the requirement of
being reachable is counter-productive and it is important that this being reachable is counter-productive and it is important that this
is correctly configured. is correctly configured.
The above general consideration for servers applies also for TCP The above general consideration for servers applies also for TCP
based candidates. A general implementation should support several based candidates. A general implementation should support several
candidate collection techniques and connection types. For TCP based candidate collection techniques and connection types. For TCP based
candidates a high-reachability configured server is recommended to candidates a high-reachability configured server is recommended to
only offer Host candidates. In addition to passive connection types only offer Host candidates. In addition to passive connection types
the server can select to provide active or SO connection types to the server can select to provide active or SO connection types to
match the client's candidates. match the client's candidates.
skipping to change at page 25, line 37 skipping to change at page 25, line 37
be determined using STUN as described in [RFC3489], the determined be determined using STUN as described in [RFC3489], the determined
behavior might not be representative of the behavior encountered in behavior might not be representative of the behavior encountered in
another mapping. Secondly, filter state towards the ports used by another mapping. Secondly, filter state towards the ports used by
the server needs to be established. This requires that the server the server needs to be established. This requires that the server
actually includes both address and ports in its response to the SETUP actually includes both address and ports in its response to the SETUP
request. Thirdly messages need to be sent to these ports for keep- request. Thirdly messages need to be sent to these ports for keep-
alive at a regular interval. How a server reacts to such unsolicited alive at a regular interval. How a server reacts to such unsolicited
traffic is unknown. This brittleness may be accepted in fallback due traffic is unknown. This brittleness may be accepted in fallback due
to lack of support on the server side. to lack of support on the server side.
To maximize the likelihood that an RTSP client is capable of
receiving media a relay based address should be chosen as the default
fallback address. However, for RTSP clients lacking a relay server,
like a TURN server, or where usage of such a server has significant
cost associated with it the usage of a STUN derived server reflexive
address as client default has a reasonable likelihood of functioning
and may be used as an alternative.
Fallback addresses need to be provided in their own transport Fallback addresses need to be provided in their own transport
specification using a specifier that does not include the "D-ICE" specification using a specifier that does not include the "D-ICE"
lower layer transport. Instead the selected protocol, e.g. UDP lower layer transport. Instead the selected protocol, e.g. UDP
needs to be explicitly or implictly indicated. Secondly the selected needs to be explicitly or implicitly indicated. Secondly the
default candidate needs to be included in the SETUP request. If this selected default candidate needs to be included in the SETUP request.
candidate is server reflexive or relayed the aspect of keep-alive If this candidate is server reflexive or relayed the aspect of keep-
needs to be ensured. alive needs to be ensured.
9. IANA Considerations 9. IANA Considerations
This document requests registration in a number of registries, both This document requests registration in a number of registries, both
for RTSP and SDP. For all the below registrations the contact person for RTSP and SDP. For all the below registrations the contact person
on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address: on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address:
Farogatan 6, 164 80 Stockholm, Sweden; Email: Farogatan 6, 164 80 Stockholm, Sweden; Email:
magnus.westerlund@ericsson.com. magnus.westerlund@ericsson.com.
RFC-Editor Note: Please replace any occurance of RFCXXXX in the below RFC-Editor Note: Please replace any occurrence of RFCXXXX in the
with the RFC number this specification is assigned. below with the RFC number this specification is assigned.
9.1. RTSP Feature Tags 9.1. RTSP Feature Tags
This document request that one RTSP 2.0 feature tag is registered in This document request that one RTSP 2.0 feature tag is registered in
the "RTSP 2.0 Feature-tags" registry: the "RTSP 2.0 Feature-tags" registry:
setup.ice-d-m A feature tag representing the support of the ICE setup.ice-d-m A feature tag representing the support of the ICE
based establishment of datagram media transport that is capable of based establishment of datagram media transport that is capable of
transport establishment through NAT and Firewalls. This feature transport establishment through NAT and Firewalls. This feature
tag applies to clients, servers and proxies and indicates that tag applies to clients, servers and proxies and indicates that
skipping to change at page 27, line 41 skipping to change at page 28, line 4
This document requests that one assignment is done in the RTSP 2.0 This document requests that one assignment is done in the RTSP 2.0
Notify-Reason header value registry. The defined value is: Notify-Reason header value registry. The defined value is:
ice-restart: Server notifying the client about the need for an ICE ice-restart: Server notifying the client about the need for an ICE
restart. See section Section 4.6. restart. See section Section 4.6.
9.6. SDP Attribute 9.6. SDP Attribute
The registration of one SDP attribute is requested: The registration of one SDP attribute is requested:
SDP Attribute ("att-field"):
Attribute name: rtsp-ice-d-m SDP Attribute ("att-field"):
Long form: ICE for RTSP datagram media NAT traversal
Type of attribute: Session level only Attribute name: rtsp-ice-d-m
Subject to charset: No Long form: ICE for RTSP datagram media NAT traversal
Purpose: RFC XXXX, Section <xref target="sec-sdp-attrib"/> Type of attribute: Session level only
Values: No values defined. Subject to charset: No
Contact: Magnus Westerlund Purpose: RFC XXXX, Section 4.7
E-mail: magnus.westerlund@ericsson.com Values: No values defined.
phone: +46 10 714 82 87 Contact: Magnus Westerlund
E-mail: magnus.westerlund@ericsson.com
phone: +46 10 714 82 87
10. Security Considerations 10. Security Considerations
ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion
on security considerations which apply here as well. on security considerations which apply here as well.
10.1. ICE and RTSP 10.1. ICE and RTSP
A long-standing risk with transmitting a packet stream over UDP is A long-standing risk with transmitting a packet stream over UDP is
that the host may not be interested in receiving the stream. On that the host may not be interested in receiving the stream. On
skipping to change at page 30, line 39 skipping to change at page 31, line 7
Feltham,, Middx TW14 8HA Feltham,, Middx TW14 8HA
United Kingdom United Kingdom
Phone: +44 20 8824 1000 Phone: +44 20 8824 1000
Fax: Fax:
Email: jgoldber@cisco.com Email: jgoldber@cisco.com
URI: URI:
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Torshamsgatan 23 Farogatan 6
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. Nextwave Wireless, Inc.
 End of changes. 16 change blocks. 
27 lines changed or deleted 35 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/