draft-ietf-mmusic-data-channel-sdpneg-19.txt   draft-ietf-mmusic-data-channel-sdpneg-20.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: December 2, 2018 Nokia Expires: December 25, 2018 Nokia
J. Stoetzer-Bradler J. Stoetzer-Bradler
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
R. Even, Ed. R. Even, Ed.
Huawei Huawei
May 31, 2018 June 23, 2018
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-19 draft-ietf-mmusic-data-channel-sdpneg-20
Abstract Abstract
The Real-Time Communication in WEB-browsers (RTCWeb) working group is The Real-Time Communication in WEB-browsers (RTCWeb) working group is
charged to provide protocols to support direct interactive rich charged to provide protocols to support direct interactive rich
communications using audio, video, and data between two peers' web- communications using audio, video, and data between two peers' web-
browsers. For the support of data communication, the RTCWeb working browsers. For the support of data communication, the RTCWeb working
group has in particular defined the concept of bi-directional data group has in particular defined the concept of bi-directional data
channels over SCTP (Stream Control Transmission Protocol), where each channels over SCTP (Stream Control Transmission Protocol), where each
data channel might be used to transport other protocols, called data channel might be used to transport other protocols, called
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 December 2, 2018. This Internet-Draft will expire on December 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 45 skipping to change at page 2, line 45
5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8
5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9
5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9
5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9
5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 9 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 9
5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10
5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10
5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12
6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 12 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13
6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13
6.3. Generating the Initial Offer for A Data Channel . . . . . 13 6.3. Generating the Initial Offer for A Data Channel . . . . . 14
6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14
6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14
6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15
6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15
6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 15 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19
9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19
9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20
9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 12, line 31 skipping to change at page 12, line 31
of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
multiple SCTP associations on top of a single DTLS association, or multiple SCTP associations on top of a single DTLS association, or
how to add multiple SCTP associations to one BUNDLE group, then how to add multiple SCTP associations to one BUNDLE group, then
multiplexing rules for the "a=dcsa:" attribute need to be defined as multiplexing rules for the "a=dcsa:" attribute need to be defined as
well, for instance in an extension of this SDP based data channel well, for instance in an extension of this SDP based data channel
negotiation specification. negotiation specification.
6. SDP Offer/Answer Procedures 6. SDP Offer/Answer Procedures
This section defines how data channels can be negotiated using the This section defines how data channels can be negotiated using the
SDP offer/answer mechanism. The procedures apply for a given data SDP offer/answer mechanism. A given media description can describe
channel. multiple data channels (each represented by a separate SDP dcmap
attribute) that can be created, modified and closed using different
offer/answer exchanges. The procedures in this section apply for a
given data channel.
The generic offer/answer procedures for negotiating the SCTP The generic offer/answer procedures for negotiating the SCTP
association used to realize are defined in association used to realize data channels are defined in
[I-D.ietf-mmusic-sctp-sdp]. This section only defines the data [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data
channel specific procedures. channel specific procedures.
"Initial offer" refers to the offer in which a data channel is "Initial offer" refers to the offer in which a data channel is
opened. It can be the initial offer, or a subsequent offer, of the opened. It can be the initial offer, or a subsequent offer, of the
associated SDP session. associated SDP session.
The detailed offer/answer procedures for the dcsa attribute are
dependent on the associated sub-protocol. A sub-protocol
specification MUST define the offer/answer procedures for the dsca
attribute (if applicable) associated with the sub-protocol.
6.1. Managing Stream Identifiers 6.1. Managing Stream Identifiers
As described in [I-D.ietf-rtcweb-data-protocol], in order to avoid In order to avoid SCTP Stream identifier collisions, in alignment
SCTP Stream identifier collisions, the endpoint acting as DTLS client with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS
(for the SCTP association used to realize data channels) will use client (for the SCTP association used to realize data channels) MUST
even identifier values, and the endpoint acting as DTLS server will use even identifier values, and the endpoint acting as DTLS server
use odd identifier values. Those rules also apply when SCTP streams MUST use odd identifier values. SCTP stream identifiers associated
for data channels are negotiated using the offer/answer mechanism. with data channels that have been negotiated using DCEP MUST NOT be
included in SDP offers and answers.
SCTP stream identifiers associated with data channels that have been SCTP stream identifiers associated with data channels that have been
negotiated using DCEP MUST NOT be included in SDP offers and answers. negotiated using DCEP MUST NOT be included in SDP offers and answers.
6.2. Negotiating Data Channel Parameters 6.2. Negotiating Data Channel Parameters
The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
mapped to the dcmap SDP media description in the following manner mapped to the dcmap SDP attribute parameters in the following manner
where "ordered=true" is the default and may be omitted: where "ordered=true" is the default and may be omitted:
DATA_CHANNEL_RELIABLE DATA_CHANNEL_RELIABLE
ordered=true ordered=true
DATA_CHANNEL_RELIABLE_UNORDERED DATA_CHANNEL_RELIABLE_UNORDERED
ordered=false ordered=false
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
ordered=true;max-retr=<number of retransmissions> ordered=true;max-retr=<number of retransmissions>
skipping to change at page 13, line 39 skipping to change at page 14, line 5
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 at By definition max-retr and max-time are mutually exclusive, so at
most one of them MAY be present in the "a=dcmap:" attribute line. If most one of them MAY be present in the "a=dcmap:" attribute line. If
a SDP offer contains both of these parameters then the receiver of a SDP offer contains both of these parameters then the receiver of
such an SDP offer MUST reject the SDP offer. If a SDP answer such an SDP offer MUST reject the SDP offer. If a SDP answer
contains both of these parameters then the offerer MUST treat the contains both of these parameters then the offerer MUST treat the
associated SDP offer/answer failed. associated SDP offer/answer failed.
The SDP answer SHALL echo the same subprotocol, max-retr, max-time,
and ordered parameters, form the offer, and MAY include a label
parameter. They MAY appear in any order, which could be different
from the SDP offer, in the SDP answer.
When sending a subsequent offer or an answer, and for as long as the
data channel is still open, the sender MUST replicate the same
information.
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
o MAY include one or more SDP dcsa attributes (Section 6.2) o MAY include one or more SDP dcsa attributes (Section 5.2)
associated with the data channel. The value of the stream-id part associated with the data channel. The value of the stream-id part
of each attribute SHALL match the dcmap-stream-id value of the of each attribute SHALL match the dcmap-stream-id value of the
dcmap attribute. dcmap attribute.
6.4. Generating SDP Answer 6.4. Generating SDP Answer
When an answerer receives an offer that includes an "m=" section for When an answerer receives an offer that includes an "m=" section for
an SCTP association, that describes an SCTP stream for a data an SCTP association, that describes an SCTP stream for a data
channel, if the answerer accepts the data channel it: channel, if the answerer accepts the data channel it:
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. The value the SCTP association used to realize the data channel. The value
of the dcmap-stream-id value of the dcmap attribute SHALL be of the dcmap-stream-id, max-retr and max-time values of the dcmap
identical to the value used for the data channel in the offer; and attribute SHALL be identical to the value used for the data
channel in the offer; and
o MAY include one or more SDP dcsa attributes (Section 6.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 a SDP answer performs the following:
o SHALL closes any created data channels as described in o SHALL closes 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
skipping to change at page 15, line 21 skipping to change at page 15, line 25
the SDP answer confirming acceptance of the data channel or when the SDP answer confirming acceptance of the data channel or when
it begins to receive data on the data channel from the peer, it begins to receive data on the data channel from the peer,
whichever occurs first. whichever occurs first.
Note: DCEP is not used, that is neither the SDP offerer nor the SDP Note: DCEP is not used, that is neither the SDP offerer nor the SDP
answerer send an in-band DCEP DATA_CHANNEL_OPEN message. answerer send an in-band DCEP DATA_CHANNEL_OPEN message.
6.6. Modifying the Session 6.6. Modifying the Session
When an offer sends a subsequent offer, that includes information for When an offer sends a subsequent offer, that includes information for
a previously negotiated SCTP stream for a data channel, unless the a previously negotiated data channel, unless the offerer intends to
offerer intends to close the data channel (Section 6.6.1), the close the data channel (Section 6.6.1), the offerer SHALL include the
offerer SHALL include the previously negotiated SDP attributes and previously negotiated SDP attributes and attribute values associated
attribute values associated with the data channel. with the data channel.
6.6.1. Closing a Data Channel 6.6.1. Closing a Data Channel
In order to close a data channel the endpoint that wants to close In order to close a data channel the endpoint that wants to close
SHALL send the SCTP SSN reset message [RFC6525], following the SHALL send the SCTP SSN reset message [RFC6525], following the
procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In
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:
skipping to change at page 15, line 52 skipping to change at page 16, line 11
channel for a new data channel, using the procedures in channel for a new data channel, using the procedures in
Section 6.3. The offerer SHALL use a different SDP dcmap Section 6.3. The offerer SHALL use a different SDP dcmap
attribute value for the data channel using the same SCTP stream. 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 SHOULD ignore the "a=dcsa:" such an SDP offer or answer MUST discard this "a=dcsa:"
attributes and SHOULD process the SDP offer or answer as per attributes.
above case 'SDP offer has no "a=dcmap:" attributes' or case
'SDP answer has no "a=dcmap:" attributes'.
SDP offer or answer has an "a=dcsa" attribute, whose subprotocol SDP offer or answer has an "a=dcsa" attribute, whose subprotocol
attribute is unknown. attribute is unknown.
* The receiver of such an SDP offer or answer SHOULD ignore this * The receiver of such an SDP offer or answer SHOULD ignore this
entire "a=dcsa" attribute line. entire "a=dcsa" attribute line.
SDP offer or answer has an "a=dcsa" attribute, whose subprotocol SDP offer or answer has an "a=dcsa" attribute, whose subprotocol
attribute is known, but whose subprotocol attribute semantic is attribute is known, but whose subprotocol attribute semantic is
not known for the data channel transport case. not known for the data channel transport case.
 End of changes. 18 change blocks. 
38 lines changed or deleted 37 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/