draft-ietf-mmusic-sctp-sdp-23.txt   draft-ietf-mmusic-sctp-sdp-24.txt 
MMUSIC C. Holmberg MMUSIC C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track R. Shpount Intended status: Standards Track R. Shpount
Expires: August 14, 2017 TurboBridge Expires: September 10, 2017 TurboBridge
S. Loreto S. Loreto
G. Camarillo G. Camarillo
Ericsson Ericsson
February 10, 2017 March 9, 2017
Session Description Protocol (SDP) Offer/Answer Procedures For Stream Session Description Protocol (SDP) Offer/Answer Procedures For Stream
Control Transmission Protocol (SCTP) over Datagram Transport Layer Control Transmission Protocol (SCTP) over Datagram Transport Layer
Security (DTLS) Transport. Security (DTLS) Transport.
draft-ietf-mmusic-sctp-sdp-23 draft-ietf-mmusic-sctp-sdp-24
Abstract Abstract
The Stream Control Transmission Protocol (SCTP) is a transport The Stream Control Transmission Protocol (SCTP) is a transport
protocol used to establish associations between two endpoints. protocol used to establish associations between two endpoints.
draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used
on top of the Datagram Transport Layer Security (DTLS) protocol, on top of the Datagram Transport Layer Security (DTLS) protocol,
referred to as SCTP-over-DTLS. referred to as SCTP-over-DTLS.
This specification defines the following new Session Description This specification defines the following new Session Description
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 August 14, 2017. This Internet-Draft will expire on September 10, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 3, line 13 skipping to change at page 3, line 13
10.3. Generating the SDP Answer . . . . . . . . . . . . . . . 13 10.3. Generating the SDP Answer . . . . . . . . . . . . . . . 13
10.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 10.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14
10.5. Modifying the Session . . . . . . . . . . . . . . . . . 15 10.5. Modifying the Session . . . . . . . . . . . . . . . . . 15
11. Multihoming Considerations . . . . . . . . . . . . . . . . . 16 11. Multihoming Considerations . . . . . . . . . . . . . . . . . 16
12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 16
12.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 16 12.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 16
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 17 13.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 17
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
15.1. New SDP proto values . . . . . . . . . . . . . . . . . . 18 15.1. New SDP proto values . . . . . . . . . . . . . . . . . . 19
15.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 18 15.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19
15.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 18 15.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 19
15.2.2. max-message-size . . . . . . . . . . . . . . . . . . 18 15.2.2. max-message-size . . . . . . . . . . . . . . . . . . 19
15.3. association-usage Name Registry . . . . . . . . . . . . 19 15.3. association-usage Name Registry . . . . . . . . . . . . 19
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
18.1. Normative References . . . . . . . . . . . . . . . . . . 22 18.1. Normative References . . . . . . . . . . . . . . . . . . 23
18.2. Informative References . . . . . . . . . . . . . . . . . 24 18.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
SDP (Session Description Protocol) [RFC4566] provides a general- SDP (Session Description Protocol) [RFC4566] provides a general-
purpose format for describing multimedia sessions in announcements or purpose format for describing multimedia sessions in announcements or
invitations. TCP-Based Media Transport in the Session Description invitations. TCP-Based Media Transport in the Session Description
Protocol (SDP) [RFC4145] specifies a general mechanism for describing Protocol (SDP) [RFC4145] specifies a general mechanism for describing
and establishing TCP [RFC0793] streams. Connection-Oriented Media and establishing TCP [RFC0793] streams. Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol in SDP Transport over the Transport Layer Security (TLS) Protocol in SDP
[I-D.ietf-mmusic-4572-update] extends RFC4145 [RFC4145] for [I-D.ietf-mmusic-4572-update] extends RFC4145 [RFC4145] for
skipping to change at page 10, line 13 skipping to change at page 10, line 13
association on top of any given DTLS association. association on top of any given DTLS association.
8. TCP/DTLS/SCTP Transport Realization 8. TCP/DTLS/SCTP Transport Realization
The TCP/DTLS/SCTP transport is realized as described below: The TCP/DTLS/SCTP transport is realized as described below:
o SCTP on top of DTLS is realized according to the procedures o SCTP on top of DTLS is realized according to the procedures
defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and
o DTLS on top of TCP is realized using the framing method defined in o DTLS on top of TCP is realized using the framing method defined in
[RFC4571], with DTLS packets being sent instead of RTP/RTCP [RFC4571], with DTLS packets being sent and received instead of
packets, and SDP signaling according to the procedures defined in RTP/RTCP packets using the shim defined in [RFC4571], so that
this specification. length field defined in [RFC4571] precedes each DTLS message, and
SDP signaling according to the procedures defined in this
specification.
NOTE: DTLS on top of TCP, without using the framing method defined in NOTE: TLS on top of TCP, without using the framing method defined in
[RFC4571] is outside the scope of this specification. A separate [RFC4571] is outside the scope of this specification. A separate
proto value would need to be registered for such transport proto value would need to be registered for such transport
realization. realization.
9. Association And Connection Management 9. Association And Connection Management
9.1. General 9.1. General
This section describes how to manage an SCTP association, DTLS This section describes how to manage an SCTP association, DTLS
association and TCP connection using SDP attributes. association and TCP connection using SDP attributes.
skipping to change at page 16, line 34 skipping to change at page 16, line 34
TCP). TCP).
12.2. ICE Considerations 12.2. ICE Considerations
When SCTP-over-DTLS is used with UDP based ICE candidates [RFC5245] When SCTP-over-DTLS is used with UDP based ICE candidates [RFC5245]
then the procedures for UDP/DTLS/SCTP [Section 7] are used. then the procedures for UDP/DTLS/SCTP [Section 7] are used.
When SCTP-over-DTLS is used with TCP based ICE candidates [RFC6544] When SCTP-over-DTLS is used with TCP based ICE candidates [RFC6544]
then the procedures for TCP/DTLS/SCTP [Section 8] are used. then the procedures for TCP/DTLS/SCTP [Section 8] are used.
In ICE environments, during the nomination process, endpoints go
through multiple ICE candidate pairs, until the most preferred
candidate pair is found. During the nomination process, data can be
sent as soon as the first working candidate pair is found, but the
nomination process still continues and selected candidate pairs can
still change while data is sent. Furthermore, if endpoints roam
between networks, for instance when mobile endpoint switches from
mobile connection to WiFi, endpoints will initiate an ICE restart,
which will trigger a new nomination process between the new set of
candidates and likely result in the new nominated candidate pair.
Implementations MUST treat all ICE candidate pairs associated with an Implementations MUST treat all ICE candidate pairs associated with an
SCTP association on top of a DTLS association as part of the same SCTP association on top of a DTLS association as part of the same
DTLS association. Thus, there will only be one SCTP handshake and DTLS association. Thus, there will only be one SCTP handshake and
one DTLS handshake even if there are multiple valid candidate pairs, one DTLS handshake even if there are multiple valid candidate pairs,
and shifting from one candidate pair to another will not impact the and shifting from one candidate pair to another, including switching
SCTP or DTLS associations. If new candidates are added, they will between UDP to TCP candidate pairs, will not impact the SCTP or DTLS
also be part of the same SCTP and DTLS associations. When associations. If new candidates are added, they will also be part of
transitioning between candidate pairs, different candidate pairs can the same SCTP and DTLS associations. When transitioning between
be currently active in different directions and implementations MUST candidate pairs, different candidate pairs can be currently active in
be ready to receive data on any of the candidates, even if this means different directions and implementations MUST be ready to receive
sending and receiving data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at data on any of the candidates, even if this means sending and
the same time in different directions. receiving data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time
in different directions.
When an SDP offer or answer is sent, the proto value MUST match the In order to maximize the likelihood of interoperability between the
transport protocol associated with the default candidate. Hence, if endpoints, all ICE enabled SCTP-over-DTLS endpoints SHOULD implement
UDP transport is used for the default candidate the 'UDP/DTLS/SCTP' support for UDP/DTLS/SCTP.
When an SDP offer or answer is sent with multiple ICE candidates
during initial connection negotiation or after ICE restart, UDP based
candidates SHOULD be included and default candidate SHOULD be chosen
from one of those UDP candidates. The proto value MUST match the
transport protocol associated with the default candidate. If UDP
transport is used for the default candidate, then 'UDP/DTLS/SCTP'
proto value MUST be used. If TCP transport is used for the default proto value MUST be used. If TCP transport is used for the default
candidate the 'TCP/DTLS/SCTP' proto value MUST be used. However, if candidate, then 'TCP/DTLS/SCTP' proto value MUST be used. Note that
under normal circumstances the proto value for offers and answers
sent during ICE nomination SHOULD be 'UDP/DTLS/SCTP'.
When a subsequent SDP offer or answer is sent after ICE nomination is
complete, and does not initiate ICE restart, it will contain only the
currently nominated ICE candidate pair. In this case, the proto
value MUST match the transport protocol associated with the currently
negotiated ICE candidate pair. If UDP transport is used for the
currently nominated pair, then 'UDP/DTLS/SCTP' proto value MUST be
used. If TCP transport is used for the currently negotiated pair,
then 'TCP/DTLS/SCTP' proto value MUST be used. Please note that if
an endpoint switches between TCP-based and UDP-based candidates an endpoint switches between TCP-based and UDP-based candidates
during a session the endpoint is not required to send an SDP offer in during the nomination process the endpoint is not required to send an
order to modify that proto value of the associated m- line. SDP offer for the sole purpose of keeping the proto value of the
associated m- line in sync.
NOTE: The text in the paragraph above only applies when the usage of NOTE: The text in the paragraph above only applies when the usage of
ICE has been negotiated. If ICE is not used, the proto value MUST ICE has been negotiated. If ICE is not used, the proto value MUST
always reflect the transport protocol used at any given time. always reflect the transport protocol used at any given time.
13. Examples 13. Examples
13.1. Establishment of UDP/DTLS/SCTP association 13.1. Establishment of UDP/DTLS/SCTP association
SDP Offer: SDP Offer:
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:DB8::A8FD c=IN IP6 2001:DB8::A8FD
a=dtls-id:abc3dl a=dtls-id:abc3dl
a=setup:actpass a=setup:actpass
a=sctp-port:5000 a=sctp-port:5000
a=max-message-size:100000 a=max-message-size:100000
- The offerer indicates that the usage of the - The offerer indicates that the usage of the
skipping to change at page 20, line 17 skipping to change at page 20, line 50
The authors wish to thank Harald Alvestrand, Randell Jesup, Paul The authors wish to thank Harald Alvestrand, Randell Jesup, Paul
Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen
and Ari Keranen for their comments and useful feedback. Ben Campbell and Ari Keranen for their comments and useful feedback. Ben Campbell
provided comments as part of his AD review. Brian Carpenter provided comments as part of his AD review. Brian Carpenter
performed the Gen-ART review. performed the Gen-ART review.
17. 17.
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sctp-sdp-23
o Changes based on IESG review.
o - Proto value clarifications.
Changes from draft-ietf-mmusic-sctp-sdp-22 Changes from draft-ietf-mmusic-sctp-sdp-22
o Changes based on Gen-ART review by Brian Carpenter. o Changes based on Gen-ART review by Brian Carpenter.
Changes from draft-ietf-mmusic-sctp-sdp-21 Changes from draft-ietf-mmusic-sctp-sdp-21
o Changes based on AD review by Ben Campbell. o Changes based on AD review by Ben Campbell.
Changes from draft-ietf-mmusic-sctp-sdp-20 Changes from draft-ietf-mmusic-sctp-sdp-20
 End of changes. 15 change blocks. 
32 lines changed or deleted 69 lines changed or added

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