draft-ietf-mmusic-sctp-sdp-05.txt   draft-ietf-mmusic-sctp-sdp-06.txt 
MMUSIC S. Loreto MMUSIC S. Loreto
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: April 24, 2014 October 21, 2013 Expires: August 17, 2014 February 13, 2014
Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Stream Control Transmission Protocol (SCTP)-Based Media Transport in the
Session Description Protocol (SDP) Session Description Protocol (SDP)
draft-ietf-mmusic-sctp-sdp-05 draft-ietf-mmusic-sctp-sdp-06
Abstract Abstract
SCTP (Stream Control Transmission Protocol) is a transport protocol SCTP (Stream Control Transmission Protocol) is a transport protocol
used to establish associations between two endpoints. This document used to establish associations between two endpoints. This document
describes how to express media transport over SCTP in SDP (Session describes how to express media transport over SCTP in SDP (Session
Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS'
and 'DTLS/SCTP' protocol identifiers for SDP. and 'DTLS/SCTP' protocol identifiers for SDP.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 24, 2014. This Internet-Draft will expire on August 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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 2, line 19 skipping to change at page 2, line 19
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 4
4. Media Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Media Formats . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Media Descriptions . . . . . . . . . . . . . . . . . . . . 5 4.1. Media Descriptions . . . . . . . . . . . . . . . . . . . . 5
5. Media attributes . . . . . . . . . . . . . . . . . . . . . . . 6 5. Media attributes . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. sctpmap Attribute . . . . . . . . . . . . . . . . . . . . 6 5.1. sctpmap Attribute . . . . . . . . . . . . . . . . . . . . 6
6. The Setup and Connection Attributes and Association 6. The Setup and Connection Attributes and Association
Management . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Management . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Network Address Translation (NAT) Considerations . . . . . . . 8 8. Network Address Translation (NAT) Considerations . . . . . . . 8
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Actpass/Passive . . . . . . . . . . . . . . . . . . . . . 8 9.1. Actpass/Passive . . . . . . . . . . . . . . . . . . . . . 9
9.2. Existing Connection Reuse . . . . . . . . . . . . . . . . 9 9.2. Existing Connection Reuse . . . . . . . . . . . . . . . . 9
9.3. SDP description for SCTP over DTLS Connection . . . . . . 10 9.3. SDP description for SCTP over DTLS Connection . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. sctpmap attribute . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 13.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 (Transmission Control Protocol) streams. and establishing TCP (Transmission Control Protocol) streams.
Connection-Oriented Media Transport over the Transport Layer Security Connection-Oriented Media Transport over the Transport Layer Security
(TLS) Protocol in the Session Description Protocol (SDP) [RFC4572] (TLS) Protocol in the Session Description Protocol (SDP) [RFC4572]
extends RFC4145 [RFC4145] for describing TCP-based media streams that extends RFC4145 [RFC4145] for describing TCP-based media streams that
are protected using TLS (Transport Layer Security) [RFC5246]. are protected using TLS (Transport Layer Security) [RFC5246].
This document defines three new protocol identifiers: This document defines three new protocol identifiers:
SCTP : to describe SCTP-based [RFC4960] media streams. SCTP : to describe SCTP-based [RFC4960] media streams.
SCTP/DTLS : to allow the usage of the Datagram Transport Layer SCTP/DTLS : to describe media streams transported using the Datagram
Security (DTLS) [RFC4347] protocol over SCTP, as specified in Transport Layer Security (DTLS) [RFC4347] protocol over SCTP, as
[RFC6083], using SDP. DTLS over SCTP provides communications specified in [RFC6083]. DTLS over SCTP provides communications
privacy for applications that use SCTP as their transport privacy for applications that use SCTP as their transport
protocol. protocol.
DTLS/SCTP : to allow the usage of SCTP on top of the Datagram DTLS/SCTP : to describe media streams transported using SCTP on top
Transport Layer Security (DTLS) protocol, as defined in of the Datagram Transport Layer Security (DTLS) protocol, as
[I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP. SCTP over DTLS is defined in [I-D.tuexen-tsvwg-sctp-dtls-encaps].
used by the RTCWeb protocol suite for transporting non-media data
between browsers.
The authentication certificates are interpreted and validated as The authentication certificates are interpreted and validated as
defined in RFC4572 [RFC4572]. Self-signed certificates can be used defined in RFC4572 [RFC4572]. Self-signed certificates can be used
securely, provided that the integrity of the SDP description is securely, provided that the integrity of the SDP description is
assured as defined in RFC4572 [RFC4572]. assured as defined in RFC4572 [RFC4572].
TLS is designed to run on top of a byte-stream oriented transport TLS is designed to run on top of a byte-stream oriented transport
protocol providing a reliable, in-sequence delivery like TCP. Since protocol providing a reliable, in-sequence delivery like TCP. Since
no-one so far has implemented SCTP over TLS, due to some serious no-one so far has implemented SCTP over TLS, due to some serious
limitations described in [RFC6083], this document does not make use limitations described in [RFC6083], this document does not make use
skipping to change at page 4, line 43 skipping to change at page 4, line 41
Security (DTLS) protocol as specified in Security (DTLS) protocol as specified in
[I-D.tuexen-tsvwg-sctp-dtls-encaps]. The actual layer below DTLS can [I-D.tuexen-tsvwg-sctp-dtls-encaps]. The actual layer below DTLS can
be plain UDP or what ICE agrees on (in the case ICE is used to be plain UDP or what ICE agrees on (in the case ICE is used to
negotiate the actual transport flow). The lower layer used is negotiate the actual transport flow). The lower layer used is
identified from the elements present inside the m= line block. identified from the elements present inside the m= line block.
An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
further qualify the application-layer protocol using an fmt further qualify the application-layer protocol using an fmt
identifier. identifier.
An 'm' line that specifies 'SCTP/DTLS' or 'DTLS/SCTP' MUST further An 'm' line that specifies 'SCTP/DTLS' or 'DTLS/SCTP' MUST provide a
provide a certificate fingerprint. An SDP attribute (an 'a' line) is certificate fingerprint only if the endpoint supports, and is willing
used to transport and exchange end point certificate. The to use, a cipher suite with an associated certificate. An SDP
authentication certificates are interpreted and validated as defined attribute (an 'a' line) is used to transport and exchange end point
in [RFC4572]. certificate. The authentication certificates are interpreted and
validated as defined in [RFC4572].
4. Media Formats 4. Media Formats
The SDP specification, [RFC4566], states that specifications defining The SDP specification, [RFC4566], states that specifications defining
new proto values, like the SCTP, SCTP/DTLS and DTLS/SCTP proto values new proto values, like the SCTP, SCTP/DTLS and DTLS/SCTP proto values
defined in this RFC, must define the rules by which their media defined in this RFC, must define the rules by which their media
format (fmt) namespace is managed. Use of an existing MIME subtype format (fmt) namespace is managed. Use of an existing MIME subtype
for the format is encouraged. If no MIME subtype exists, it is for the format is encouraged. If no MIME subtype exists, it is
RECOMMENDED that a suitable one is registered through the IETF RECOMMENDED that a suitable one is registered through the IETF
process [RFC4288] [RFC4289] by production of, or reference to, a process [RFC4288] [RFC4289] by production of, or reference to, a
skipping to change at page 5, line 28 skipping to change at page 5, line 28
The media description change slightly depending on the actual The media description change slightly depending on the actual
<proto>. <proto>.
If the <proto> sub-field is 'SCTP' or 'SCTP/DTLS' If the <proto> sub-field is 'SCTP' or 'SCTP/DTLS'
the <port> is the SCTP transport port and follows the same active/ the <port> is the SCTP transport port and follows the same active/
passive offer/answer model described in Section 4.1 of [RFC4145]; passive offer/answer model described in Section 4.1 of [RFC4145];
the <fmt> sub-field carries the same port number value specified the <fmt> sub-field carries the same port number value specified
in the <port> and the mandatory "a=sctpmap:" attribute contains in the <port> and the mandatory SDP "sctpmap" attribute contains
the actual media format within the protocol parameter. the actual media format within the protocol parameter.
m=application 54111 SCTP/DTLS 54111 m=application 54111 SCTP/DTLS 54111
a=sctpmap:54111 webrtc-datachannel 1 a=sctpmap:54111 t38 1
Running SCTP over DTLS make possible to have multiple SCTP Running SCTP over DTLS make possible to have multiple SCTP
associations on top of the same DTLS connection; each SCTP associations on top of the same DTLS connection; each SCTP
association make use of a distinct port number that is mainly used to association make use of a distinct port number that is mainly used to
demultiplex the associations. demultiplex the associations.
If the <proto> sub-field is 'DTLS/SCTP' If the <proto> sub-field is 'DTLS/SCTP'
the <port> is the UDP transport port; the <port> is the UDP transport port;
the <fmt> sub-field carries the SCTP port number and the mandatory the <fmt> sub-field carries the SCTP port number and the mandatory
"a=sctpmap:" attribute contains the actual media format within the SDP "sctpmap" attribute contains the actual media format within
protocol parameter. The SCTP port number is the UA chosen port to the protocol parameter. The SCTP port number is the UA chosen
use on the DTLS channel. port to use on the DTLS channel.
When a list of SCTP port number identifiers is given, this implies When a list of SCTP port number identifiers is given, this implies
that all of these associations MUST run on top of the same DTLS that all of these associations MUST run on top of the same DTLS
connection. For the payload type assignments the "a=sctpmap:" connection. For the payload type assignments the "a=sctpmap:"
attribute (see Section 5.1) SHOULD be used to map from a port number attribute (see Section 5.1) SHOULD be used to map from a port number
to a media encoding name that identifies the payload format to a media encoding name that identifies the payload format
transported by the association or the actual application protocol transported by the association or the actual application protocol
running on top of it. running on top of it.
m=application 54111 DTLS/SCTP 5000 5001 5002 m=application 54111 DTLS/SCTP 5000
c=IN IP4 79.97.215.79 c=IN IP4 79.97.215.79
a=sctpmap:5000 webrtc-datachannel 16 a=sctpmap:5000 webrtc-datachannel max-message-size=100000 streams=16
a=sctpmap:5001 bfcp 2
a=sctpmap:5002 t38 1
5. Media attributes 5. Media attributes
5.1. sctpmap Attribute 5.1. sctpmap Attribute
The sctpmap attribute maps from a port number (as used in an "m=" The sctpmap attribute maps from a port number (as used in an "m="
line) to an encoding name denoting the payload format to be used on line) to an encoding name denoting the payload format to be used on
top of the SCTP association or the actual protocol running on top of top of the SCTP association or the actual protocol running on top of
it. It also can provide the number of incoming streams to be it.
supported by each side of the association. If this attribute is not
present, the implementation should provide a default, with a
suggested value of 16.
sctpmap-attr = "a=sctpmap:" sctpmap-number media-subtypes [streams] The sctpmap MUST include the app parameter indicating the application
sctpmap-number = 1*DIGIT running on top of the association.
protocol = labelstring
labelstring = text
text = byte-string
streams = 1*DIGIT
For each "a=sctpmap:" attribute line in the offer, there MUST be a The sctpmap line should also contain the max-message-size parameter
corresponding "a=sctpmap:" attribute line in the answer. The answer indicating the maximum message size, in bytes, the endpoint is
MUST contain exactly the same number of "a=sctpmap:" attribute lines willing to accept.
as the offer. This allows for SCTP associations to be matched up
based on their order. The peer should assume that larger message will be rejected by the
endpoint, though it is up to the endpoint decide the appropriate
behaviour.
A parameter with value of '0' will signal a best effort attempt,
subject to the current endpoint memory capacity, to handle
messages of any size.
If the parameter is not present, the implementation should provide
a default, with a suggested value of 64K.
It may also provide the stream parameter to specify the initial
number of incoming streams to be supported by each side of the
association.
If this parameter is not present, the implementation should
provide a default, with a suggested value of 16.
sctpmap-attr = "a=sctpmap:" sctpmap-number
app [max-message-size] [streams]
sctpmap-number = 1*DIGIT
app = token
max-message-size = "max-message-size" EQUALS 1*DIGIT
streams = "streams" EQUALS 1*DIGIT"
For the "a=sctpmap:" attribute line in the offer, there MUST be a
corresponding "a=sctpmap:" attribute line in the answer.
Any offered association MAY be rejected in the answer, for any Any offered association MAY be rejected in the answer, for any
reason. If an association offer is rejected, the offerer and reason. If an association offer is rejected, the offerer and
answerer MUST NOT establish an SCTP association for it. To reject an answerer MUST NOT establish an SCTP association for it. To reject an
SCTP association, the SCTP port number in the corresponding SCTP association, the SCTP port number in the "a=sctpmap:" attribute
"a=sctpmap:" attribute line in the answer MUST be set to zero. line in the answer MUST be set to zero.
Any offered association with an "a=sctpmap:" attribute line providing Any offered association with an "a=sctpmap:" attribute line providing
an incoming stream number of zero or larger than 65535 MUST be an incoming stream number of zero or larger than 65535 MUST be
rejected in the answer. An offered association answered with an rejected in the answer. An offered association answered with an
"a=sctpmap:" attribute line providing an incoming stream number of "a=sctpmap:" attribute line providing an incoming stream number of
zero or larger than 65535 MUST NOT be established. zero or larger than 65535 MUST NOT be established.
6. The Setup and Connection Attributes and Association Management 6. The Setup and Connection Attributes and Association Management
The use of the 'setup' and 'connection' attributes in the context of The use of the 'setup' and 'connection' attributes in the context of
skipping to change at page 10, line 20 skipping to change at page 10, line 39
An offerer at 192.0.2.2 signals the availability of a webrtc- An offerer at 192.0.2.2 signals the availability of a webrtc-
DataChannel session over SCTP/DTLS. The DTLS connection runs on top DataChannel session over SCTP/DTLS. The DTLS connection runs on top
of port 54111. of port 54111.
m=application 54111 DTLS/SCTP 5000 m=application 54111 DTLS/SCTP 5000
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=sctpmap:5000 webrtc-DataChannel 16 a=sctpmap:5000 webrtc-DataChannel max-message-size=100000 streams=16
Figure 5 Figure 5
The endpoint at 192.0.2.1 responds with the following description: The endpoint at 192.0.2.1 responds with the following description:
m=application 62442 DTLS/SCTP 5001 m=application 62442 DTLS/SCTP 5001
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=sctpmap:5001 webrtc-DataChannel 16 a=sctpmap:5001 webrtc-DataChannel max-message-size=100000 streams=16
Figure 6 Figure 6
10. Security Considerations 10. Security Considerations
See RFC 4566 [RFC4566] for security considerations on the use of SDP See RFC 4566 [RFC4566] for security considerations on the use of SDP
in general. See RFC 3264 [RFC3264], RFC 4145 [RFC4145] and RFC 4572 in general. See RFC 3264 [RFC3264], RFC 4145 [RFC4145] and RFC 4572
[RFC4572] for security considerations on establishing media streams [RFC4572] for security considerations on establishing media streams
using offer/answer exchanges. See RFC 4960 [RFC4960] for security using offer/answer exchanges. See RFC 4960 [RFC4960] for security
considerations on SCTP in general and [RFC6083] for security considerations on SCTP in general and [RFC6083] for security
skipping to change at page 11, line 12 skipping to change at page 11, line 33
introduce any new security consideration in addition to the ones introduce any new security consideration in addition to the ones
discussed in those specifications. discussed in those specifications.
11. IANA Considerations 11. IANA Considerations
This document defines three new proto values: 'SCTP', 'SCTP/DTLS' and This document defines three new proto values: 'SCTP', 'SCTP/DTLS' and
'DTLS/SCTP'. Their formats are defined in Section 3. These proto 'DTLS/SCTP'. Their formats are defined in Section 3. These proto
values should be registered by the IANA under "Session Description values should be registered by the IANA under "Session Description
Protocol (SDP) Parameters" under "proto". Protocol (SDP) Parameters" under "proto".
11.1. sctpmap attribute
This document defines a new SDP session and media-level attribute: This document defines a new SDP session and media-level attribute:
'sctpmap'. Its format is defined in Section 5.1. This attribute 'sctpmap'. Its format is defined in Section 5.1. This attribute
should be registered by IANA under "Session Description Protocol should be registered by IANA under "Session Description Protocol
(SDP) Parameters" under "att-field" (both session and media (SDP) Parameters" under "att-field" (both session and media
level)". level)".
The 'sctpmap' attribute also
'sctpmap'. Its format is defined in Section 5.1. This attribute
should be registered by IANA under "Session Description Protocol
(SDP) Parameters" under "att-field" (both session and media
level)".
The sctpmap also specifies tree parameters:
The mandatory 'app' parameter indicating the application running
on top of the association.
The optional max-message-size parameter indicating the maximum
message size, in bytes, the endpoint is willing to accept.
The optional streams parameter indicating the maximum message
size, in bytes, the endpoint is willing to accept.
The 'stream' attribute indicating the initial number of incoming
streams supported by each side of the association.
sctpmap-attr = "a=sctpmap:" sctpmap-number
app [max-message-size] [streams]
sctpmap-number = 1*DIGIT
app = token
max-message-size = "max-message-size" EQUALS 1*DIGIT
streams = "streams" EQUALS 1*DIGIT"
[Open Issue] This specification has to creats a new IANA registry
named "SCTP Application" to register all the possible values of the
'app' parameter and register as first value "webrtc-datachannel" for
draft-ietf-rtcweb-data-channel.
12. Acknowledgments 12. Acknowledgments
The authors wish to thank Harald Alvestrand, Randell Jesup, Paul The authors wish to thank Harald Alvestrand, Randell Jesup, Paul
Kyzivat, Michael Tuexen for their comments and useful feedback. Kyzivat, Michael Tuexen for their comments and useful feedback.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 22 change blocks. 
54 lines changed or deleted 106 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/