draft-ietf-mmusic-data-channel-sdpneg-24.txt   draft-ietf-mmusic-data-channel-sdpneg-25.txt 
MMUSIC K. Drage MMUSIC K. Drage
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track M. Makaraju Intended status: Standards Track M. Makaraju
Expires: September 5, 2019 Nokia Expires: September 20, 2019 Nokia
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
R. Even, Ed. R. Even, Ed.
Huawei Huawei
March 4, 2019 March 19, 2019
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-24 draft-ietf-mmusic-data-channel-sdpneg-25
Abstract Abstract
Data channel setup can be done using either the in- band Data Channel Data channel setup can be done using either the in-band Data Channel
Establishment Protocol (DCEP) or using some out-of- band non-DCEP Establishment Protocol (DCEP) or using some out-of-band non-DCEP
protocol. This document specifies how the SDP (Session Description protocol. This document specifies how the SDP (Session Description
Protocol) offer/answer exchange can be used to achieve an out-of-band Protocol) offer/answer exchange can be used to achieve an out-of-band
non-DCEP negotiation for establishing a data channel. non-DCEP negotiation for establishing a data channel.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 5, 2019. This Internet-Draft will expire on September 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 4, line 7 skipping to change at page 4, line 7
Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 Using DCEP . . . . . . . . . . . . . . . . . . . . . 36
A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37
A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37
A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37
A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The concept of establishing a bi-directional data channels running on The concept of establishing a bi-directional data channel running on
top of the Stream Control Transmission Protocol (SCTP) is in top of the Stream Control Transmission Protocol (SCTP) is in
[I-D.ietf-rtcweb-data-channel] allowing applications to use data [I-D.ietf-rtcweb-data-channel] allowing applications to use data
channels. An in-band Data Channel Establishment Protocol (DCEP) is channels. An in-band Data Channel Establishment Protocol (DCEP) is
in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of- in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-
band protocols may be used for establishing data channels. Each data band protocols may be used for establishing data channels. Each data
channel consists of paired SCTP streams sharing the same SCTP Stream channel consists of paired SCTP streams sharing the same SCTP Stream
Identifier. Data channels are created by endpoint applications using Identifier. Data channels are created by endpoint applications using
the WebRTC API (Application Programming Interface), or other prtocols the WebRTC API (Application Programming Interface), or other
like CLUE [I-D.ietf-clue-datachannel]. The protocols can be signaled protocols like CLUE [I-D.ietf-clue-datachannel]. The protocols can
by the data channel "subprotocol" parameter, conceptually similar to be signaled by the data channel "subprotocol" parameter, conceptually
the WebSocket [RFC5234] "subprotocol". However, apart from the similar to the WebSocket [RFC5234] "subprotocol". However, apart
"subprotocol" value transmitted to the peer, an endpoint applications from the "subprotocol" value transmitted to the peer, an endpoint
can agree on how to instantiate a given subprotocol on a data application can agree on how to instantiate a given subprotocol on a
channel, and whether it is signaled in-band using DCEP or out-of-band data channel, and whether it is signaled in-band using DCEP or out-
using a non-DCEP protocol (or both). of-band using a non-DCEP protocol (or both).
This document defines SDP offer/answer [RFC3264] procedures that This document defines SDP offer/answer [RFC3264] procedures that
enable out-of-band negotiation for establishing data channels for enable out-of-band negotiation for establishing data channels for
transport of well-defined subprotocols. These procedures are based transport of well-defined subprotocols. These procedures are based
on generic SDP offer/answer negotiation rules for SCTP based media on generic SDP offer/answer negotiation rules for SCTP based media
transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m"
line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.
This document uses MSRP (Message Session Relay Protocol) [RFC4975] This document uses MSRP (Message Session Relay Protocol) [RFC4975]
and BFCP (Binary Floor Control Protocol) [RFC4582] in many of the and BFCP (Binary Floor Control Protocol) [RFC4582] in many of the
skipping to change at page 6, line 9 skipping to change at page 6, line 9
4. Applicability Statement 4. Applicability Statement
The mechanism in this document only applies to the Session The mechanism in this document only applies to the Session
Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used
together with the SDP offer/answer mechanism [RFC3264]. Declarative together with the SDP offer/answer mechanism [RFC3264]. Declarative
usage of SDP is out of scope of this document, and is thus undefined. usage of SDP is out of scope of this document, and is thus undefined.
5. SDP Data Channel Attributes 5. SDP Data Channel Attributes
This sections defines two new SDP media-level attributes that can be This section defines two new SDP media-level attributes that can be
used together with the SDP Offer/Answer mechanism to negotiate data used together with the SDP Offer/Answer mechanism to negotiate data
channel-specific and subprotocol-specific parameters without the channel-specific and subprotocol-specific parameters without the
usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute
provides for negotiation of channel-specific parameters. The second provides for negotiation of channel-specific parameters. The second
attribute provides for negotiation of subprotocol-specific attribute provides for negotiation of subprotocol-specific
parameters. parameters.
Note: Appendix A provides information how data channels work in Note: Appendix A provides information how data channels work in
general and especially summarizes some key aspects, which should be general and especially summarizes some key aspects, which should be
considered for the negotiation of data channels if DCEP is not used. considered for the negotiation of data channels if DCEP is not used.
skipping to change at page 6, line 37 skipping to change at page 6, line 37
The attribute is used to create bi-directional SCTP data channels The attribute is used to create bi-directional SCTP data channels
having the same set of attributes. The data channel properties having the same set of attributes. The data channel properties
(reliable/partially reliable, ordered/unordered) need to be suitable (reliable/partially reliable, ordered/unordered) need to be suitable
per the subprotocol transport requirements. per the subprotocol transport requirements.
5.1.1. DCMAP Attribute Syntax 5.1.1. DCMAP Attribute Syntax
"a=dcmap:" is a media level attribute having the following ABNF "a=dcmap:" is a media level attribute having the following ABNF
(Augmented Backus-Naur Form, [RFC5234]) syntax. (Augmented Backus-Naur Form, [RFC5234]) syntax.
Formal Syntax: Formal Syntax:
Name: dcmap Name: dcmap
Value: dcmap-value Value: dcmap-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
dcmap-value = dcmap-stream-id dcmap-value = dcmap-stream-id
[ SP dcmap-opt *(";" dcmap-opt) ] [ SP dcmap-opt *(";" dcmap-opt) ]
dcmap-opt = ordering-opt / subprotocol-opt / label-opt dcmap-opt = ordering-opt / subprotocol-opt / label-opt
/ maxretr-opt / maxtime-opt / priority-opt / maxretr-opt / maxtime-opt / priority-opt
; Only maxretr-opt or maxtime-opt ; maxretr-opt and maxtime-opt are mutually exclusive
; is present. ;
dcmap-stream-id = 1*5DIGIT dcmap-stream-id = 1*5DIGIT
ordering-opt = "ordered=" ordering-value ordering-opt = "ordered=" ordering-value
ordering-value = "true" / "false" ordering-value = "true" / "false"
subprotocol-opt = "subprotocol=" quoted-string subprotocol-opt = "subprotocol=" quoted-string
label-opt = "label=" quoted-string label-opt = "label=" quoted-string
maxretr-opt = "max-retr=" maxretr-value maxretr-opt = "max-retr=" maxretr-value
maxretr-value = "0" / integer maxretr-value = "0" / integer
; number of retransmissions, ; number of retransmissions,
; less than 2^32, ; less than 2^32,
; derived from 'Reliability Parameter' of ; derived from 'Reliability Parameter' of
; [I-D.ietf-rtcweb-data-protocol] ; [I-D.ietf-rtcweb-data-protocol]
maxtime-opt = "max-time=" maxtime-value maxtime-opt = "max-time=" maxtime-value
maxtime-value = "0" / integer maxtime-value = "0" / integer
; milliseconds, ; milliseconds,
; less than 2^32, ; less than 2^32,
; derived from 'Reliability Parameter' of ; derived from 'Reliability Parameter' of
; [I-D.ietf-rtcweb-data-protocol] ; [I-D.ietf-rtcweb-data-protocol]
priority-opt = "priority=" priority-value priority-opt = "priority=" priority-value
priority-value = "0" / integer priority-value = "0" / integer
; unsigned integer value indicating the priority of ; unsigned integer value indicating the priority of
; the data channel, ; the data channel,
; less than 2^16, ; less than 2^16,
; derived from 'Priority' of ; derived from 'Priority' of
; [I-D.ietf-rtcweb-data-protocol] ; [I-D.ietf-rtcweb-data-protocol]
quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE
quoted-char = SP / quoted-visible quoted-char = SP / quoted-visible
quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
escaped-char = "%" HEXDIG HEXDIG escaped-char = "%" HEXDIG HEXDIG
DQUOTE = <from-RFC5234> DQUOTE = <from-RFC5234>
integer = <from-RFC4566> integer = <from-RFC4566>
Examples: Examples:
a=dcmap:0 a=dcmap:0
a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512
a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128
a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000
Note: The last example (a=dcmap:4) shows a 'label' parameter value Note: The last example (a=dcmap:4) shows a 'label' parameter value
which contains one non-printable 'escaped-char' character (the which contains one non-printable 'escaped-char' character (the
tabulator character). tabulator character).
Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one
'maxretr-opt' parameter or one 'maxtime-opt' parameter may be 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be
present. Both MUST NOT be present. present. Both MUST NOT be present.
5.1.2. Dcmap-stream-id Parameter 5.1.2. Dcmap-stream-id Parameter
The 'dcmap-stream-id' parameter indicates the SCTP stream identifier The 'dcmap-stream-id' parameter indicates the SCTP stream identifier
within the SCTP association used to form the data channel. within the SCTP association used to form the data channel.
5.1.3. Label Parameter 5.1.3. Label Parameter
The 'label' parameter indicates the name of the channel. It The 'label' parameter indicates the name of the channel. It
skipping to change at page 8, line 35 skipping to change at page 8, line 35
value, such that 'label=""' is equivalent to the 'label' parameter value, such that 'label=""' is equivalent to the 'label' parameter
not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the
DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. DATA_CHANNEL_OPEN message's 'Label' value to be an empty string.
5.1.4. Subprotocol Parameter 5.1.4. Subprotocol Parameter
The 'subprotocol' parameter indicates which protocol the client The 'subprotocol' parameter indicates which protocol the client
expects to exchange via the channel. This parameter maps to the expects to exchange via the channel. This parameter maps to the
'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol].
Section 9.1 specifies how new subprotocol parameter values are Section 9.1 specifies how new subprotocol parameter values are
registered. 'Subprotocol' is an optional parameter. If the registered. 'subprotocol' is an optional parameter. If the
'subprotocol' parameter is not present, then its value defaults to an 'subprotocol' parameter is not present, then its value defaults to an
empty string. empty string.
Note: The empty string MAY also be explicitly used as 'subprotocol' Note: The empty string MAY also be explicitly used as 'subprotocol'
value, such that 'subprotocol=""' is equivalent to the 'subprotocol' value, such that 'subprotocol=""' is equivalent to the 'subprotocol'
parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] parameter not being present at all. [I-D.ietf-rtcweb-data-protocol]
allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an
empty string. empty string.
5.1.5. Max-retr Parameter 5.1.5. Max-retr Parameter
This parameter indicates that the data channel is partially reliable. This parameter indicates that the data channel is partially reliable.
The 'max-retr' parameter indicates the maximal number of times a user The 'max-retr' parameter indicates the maximal number of times a user
message will be retransmitted. The max-retr parameter is optional. message will be retransmitted. The max-retr parameter is optional.
If the max-retr parameter is not present, then the maximal number of If the max-retr parameter and the max-time parameter are not present,
retransmissions is determined as per the generic SCTP retransmission then reliable transmission is performed as specified in [RFC4960].
rules as specified in [RFC4960]. This parameter maps to the 'Number
of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. This parameter maps to the 'Number of RTX' parameter defined in
[I-D.ietf-rtcweb-data-protocol].
5.1.6. Max-time Parameter 5.1.6. Max-time Parameter
This parameter indicates that the data channel is partially reliable. This parameter indicates that the data channel is partially reliable.
A user message will no longer be transmitted or retransmitted after a A user message will no longer be transmitted or retransmitted after a
specified life-time given in milliseconds in the 'max-time' specified life-time given in milliseconds in the 'max-time'
parameter. The max-time parameter is optional. If the max-time parameter. The max-time parameter is optional. If the max-retr
parameter is not present, then the generic SCTP retransmission timing parameter and the max-time parameter are not present, then reliable
rules apply as specified in [RFC4960]. This parameter maps to the transmission is performed as specified in [RFC4960]. This parameter
'Lifetime in ms' parameter defined in maps to the 'Lifetime in ms' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
5.1.7. Ordered Parameter 5.1.7. Ordered Parameter
The 'ordered' parameter with value "true" indicates that the receiver The 'ordered' parameter with value "true" indicates that the receiver
will dispatch DATA chunks in the data channel to the upper layer will dispatch DATA chunks in the data channel to the upper layer
while preserving the order. The ordered parameter is optional and while preserving the order. The ordered parameter is optional and
takes two values: "true" for ordered and "false" for unordered takes two values: "true" for ordered and "false" for unordered
delivery with "true" as the default value. Any other value is delivery with "true" as the default value. Any other value is
ignored and default "ordered=true" is assumed. In the absence of ignored and default "ordered=true" is assumed. In the absence of
skipping to change at page 13, line 42 skipping to change at page 13, line 42
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
ordered=false;max-retr=<number of retransmissions> ordered=false;max-retr=<number of retransmissions>
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
ordered=true;max-time=<lifetime in milliseconds> ordered=true;max-time=<lifetime in milliseconds>
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
ordered=false;max-time=<lifetime in milliseconds> ordered=false;max-time=<lifetime in milliseconds>
By definition max-retr and max-time are mutually exclusive, so Both By definition max-retr and max-time are mutually exclusive, so both
MUST NOT be present in the "a=dcmap:" attribute line. If a SDP offer MUST NOT be present in the "a=dcmap:" attribute line. If an SDP
contains both of these parameters then the receiver of such an SDP offer contains both of these parameters then the receiver of such an
offer MUST reject the SDP offer. If a SDP answer contains both of SDP offer MUST reject the SDP offer. If an SDP answer contains both
these parameters then the offerer MUST treat the associated SDP of these parameters then the offerer MUST treat the associated SDP
offer/answer failed. offer/answer failed.
6.3. Generating the Initial Offer for A Data Channel 6.3. Generating the Initial Offer for A Data Channel
When an offerer sends an initial offer, in order to negotiate an SCTP When an offerer sends an initial offer, in order to negotiate an SCTP
stream for a data channel, the offerer: stream for a data channel, the offerer:
o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2)
associated with the data channel in the "m=" section representing associated with the data channel in the "m=" section representing
the SCTP association used to realize the data channel; and the SCTP association used to realize the data channel; and
skipping to change at page 14, line 37 skipping to change at page 14, line 37
the SCTP association used to realize the data channel. The value the SCTP association used to realize the data channel. The value
of the dcmap-stream-id, max-retr and max-time values of the dcmap of the dcmap-stream-id, max-retr and max-time values of the dcmap
attribute SHALL be identical to the value used for the data attribute SHALL be identical to the value used for the data
channel in the offer; and channel in the offer; and
o MAY include one or more SDP dcsa attributes (Section 5.2) o MAY include one or more SDP dcsa attributes (Section 5.2)
associated with the data channel. associated with the data channel.
6.5. Offerer Processing of the SDP Answer 6.5. Offerer Processing of the SDP Answer
An offerer receiving a SDP answer performs the following: An offerer receiving an SDP answer performs the following:
o SHALL close any created data channels as described in o SHALL close any created data channels as described in
Section 6.6.1 for which the expected "a=dcmap:" attributes are not Section 6.6.1 for which the expected "a=dcmap:" attributes are not
present in the SDP answer. If the SDP answer has no "a=dcmap" present in the SDP answer. If the SDP answer has no "a=dcmap"
attribute either the peer does not support "a=dcmap:" attributes attribute either the peer does not support "a=dcmap:" attributes
or it rejected all the data channels. In either case the offerer or it rejected all the data channels. In either case the offerer
closes all the SDP offered data channels that were open at the closes all the SDP offered data channels that were open at the
time of offer. The DTLS association and SCTP association will time of offer. The DTLS association and SCTP association will
still be setup. still be setup.
skipping to change at page 15, line 45 skipping to change at page 15, line 45
addition, if the closed data channel was negotiated using the offer/ addition, if the closed data channel was negotiated using the offer/
answer mechanism Section 6.3, the endpoint that closed the data answer mechanism Section 6.3, the endpoint that closed the data
channel SHALL send a subsequent offer in which it either: channel SHALL send a subsequent offer in which it either:
o removes the SDP dcmap attribute and SDP dcsa attributes associated o removes the SDP dcmap attribute and SDP dcsa attributes associated
with the closed data channel. Once the endpoint receives a with the closed data channel. Once the endpoint receives a
successful answer, the SCTP stream identifier value can later be successful answer, the SCTP stream identifier value can later be
used for a new data channel (negotiated using DCTP or using the used for a new data channel (negotiated using DCTP or using the
offer/answer mechanism); or offer/answer mechanism); or
o immediately re-uses the SCTP stream used for the closed data o after a reset has been performed re-uses the SCTP stream used for
channel for a new data channel, using the procedures in the closed data channel for a new data channel, using the
Section 6.3. The offerer SHALL use a different SDP dcmap procedures in Section 6.3. The offerer SHALL use a different SDP
attribute value for the data channel using the same SCTP stream. dcmap attribute value for the data channel using the same SCTP
stream.
6.7. Various SDP Offer/Answer Considerations 6.7. Various SDP Offer/Answer Considerations
An SDP offer or answer has no "a=dcmap:" attributes but has An SDP offer or answer has no "a=dcmap:" attributes but has
"a=dcsa:" attributes. "a=dcsa:" attributes.
* This is considered an error case. In this case the receiver of * This is considered an error case. In this case the receiver of
such an SDP offer or answer MUST discard this "a=dcsa:" such an SDP offer or answer MUST discard this "a=dcsa:"
attributes. attributes.
skipping to change at page 18, line 51 skipping to change at page 18, line 51
8. Security Considerations 8. Security Considerations
This document specifies new SDP attributes used in the negotiation of This document specifies new SDP attributes used in the negotiation of
the DATA channel parameters. the DATA channel parameters.
These parameter are negotiated as part of opening a SCTP channel over These parameter are negotiated as part of opening a SCTP channel over
DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol
may come with it's own security considerations that need to be may come with it's own security considerations that need to be
documented as part of the subprotocol definition. Otherwise this documented as part of the subprotocol definition. Otherwise this
document do not add any security considerations to the ones specified document does not add any security considerations to the ones
in [I-D.ietf-mmusic-sctp-sdp] specified in [I-D.ietf-mmusic-sctp-sdp]
Error cases like the use of unknown parameter values or violation the Error cases like the use of unknown parameter values or violation the
odd/even rule must be handled by closing the corresponding Data odd/even rule MUST be handled by closing the corresponding Data
Channel. Channel.
9. IANA Considerations 9. IANA Considerations
9.1. Subprotocol Identifiers 9.1. Subprotocol Identifiers
Registration of new subprotocol identifiers is performed using the Registration of new subprotocol identifiers is performed using the
existing IANA "WebSocket Subprotocol Name Registry" table. existing IANA "WebSocket Subprotocol Name Registry" table.
The following text should be added following the title of the table. The following text should be added following the title of the table.
skipping to change at page 24, line 36 skipping to change at page 24, line 36
o Modifications of the text in Section 5.1.9 and Section 5.2.2 in o Modifications of the text in Section 5.1.9 and Section 5.2.2 in
order not to explicitly restrict usage of the "a=dcmap:" and order not to explicitly restrict usage of the "a=dcmap:" and
"a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/
SCTP" or "TCP/DTLS/SCTP". SCTP" or "TCP/DTLS/SCTP".
12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' 12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04'
o In Section 5.1.4 the first (and only) paragraph was "The o In Section 5.1.4 the first (and only) paragraph was "The
'subprotocol' parameter indicates which protocol the client 'subprotocol' parameter indicates which protocol the client
expects to exchange via the channel. 'Subprotocol' is an optional expects to exchange via the channel. 'subprotocol' is an optional
parameter. If the 'subprotocol' parameter is not present, then parameter. If the 'subprotocol' parameter is not present, then
its value defaults to the empty string." Replacement of this its value defaults to the empty string." Replacement of this
paragraph with following two paragraphs: paragraph with following two paragraphs:
* The 'subprotocol' parameter indicates which protocol the client * The 'subprotocol' parameter indicates which protocol the client
expects to exchange via the channel. This parameter maps to expects to exchange via the channel. This parameter maps to
the 'Protocol' parameter defined in the 'Protocol' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new
subprotocol parameter values are registered. 'Subprotocol' is subprotocol parameter values are registered. 'subprotocol' is
an optional parameter. If the 'subprotocol' parameter is not an optional parameter. If the 'subprotocol' parameter is not
present, then its value defaults to the empty string. present, then its value defaults to the empty string.
* Note: The empty string MAY also be explicitly used as * Note: The empty string MAY also be explicitly used as
'subprotocol' value, such that 'subprotocol=""' is equivalent 'subprotocol' value, such that 'subprotocol=""' is equivalent
to the 'subprotocol' parameter not being present at all. to the 'subprotocol' parameter not being present at all.
[I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN
message's 'Subprotocol' value to be an empty string. message's 'subprotocol' value to be an empty string.
o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of
normative references. normative references.
o Addition of dcmap attribute specific IANA registration o Addition of dcmap attribute specific IANA registration
Section 9.2.1. Section 9.2.1.
o Addition of dcsa attribute specific IANA registration o Addition of dcsa attribute specific IANA registration
Section 9.2.2. Section 9.2.2.
skipping to change at page 33, line 14 skipping to change at page 33, line 14
o In section "label parameter" the sentence "Label is a mandatory o In section "label parameter" the sentence "Label is a mandatory
parameter." was removed and following new sentences (including the parameter." was removed and following new sentences (including the
note) were added: "The 'label' parameter is optional. If it is note) were added: "The 'label' parameter is optional. If it is
not present, then its value defaults to the empty string. Note: not present, then its value defaults to the empty string. Note:
The empty string may also be explicitly used as 'label' value, The empty string may also be explicitly used as 'label' value,
such that 'label=""' is equivalent to the 'label' parameter not such that 'label=""' is equivalent to the 'label' parameter not
being present at all. [I-D.ietf-rtcweb-data-protocol] allows the being present at all. [I-D.ietf-rtcweb-data-protocol] allows the
DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." DATA_CHANNEL_OPEN message's 'Label' value to be an empty string."
o In section "subprotocol parameter" the sentence "Subprotocol is a o In section "subprotocol parameter" the sentence "subprotocol is a
mandatory parameter." was replaced with "'Subprotocol' is an mandatory parameter." was replaced with "'subprotocol' is an
optional parameter. If the 'subprotocol' parameter is not optional parameter. If the 'subprotocol' parameter is not
present, then its value defaults to the empty string." present, then its value defaults to the empty string."
o In the "Examples" section, in the first two SDP offer examples in o In the "Examples" section, in the first two SDP offer examples in
the "a=dcmap" attribute lines 'label="BGCP"' was replaced with the "a=dcmap" attribute lines 'label="BGCP"' was replaced with
'label="bfcp"'. 'label="bfcp"'.
o In all examples, the "m" line proto value "DTLS/SCTP" was replaced o In all examples, the "m" line proto value "DTLS/SCTP" was replaced
with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were
replaced with "a=max-message-size" attribute lines, as per draft- replaced with "a=max-message-size" attribute lines, as per draft-
 End of changes. 32 change blocks. 
92 lines changed or deleted 94 lines changed or added

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