draft-ietf-mmusic-data-channel-sdpneg-13.txt   draft-ietf-mmusic-data-channel-sdpneg-14.txt 
MMUSIC K. Drage, Ed. MMUSIC K. Drage
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track M. Makaraju Intended status: Standards Track M. Makaraju
Expires: March 14, 2018 Nokia Expires: June 6, 2018 Nokia
J. Stoetzer-Bradler J. Stoetzer-Bradler
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
September 10, 2017 R. Even, Ed.
Huawei
December 3, 2017
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-13 draft-ietf-mmusic-data-channel-sdpneg-14
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 4 skipping to change at page 2, line 6
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 March 14, 2018.
This Internet-Draft will expire on June 6, 2018.
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
(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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 6 5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 6
5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. SDP Attribute for Data Channel Parameter Negotiation 6 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 6
5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 7
5.1.1.2. dcmap Multiplexing Category . . . . . . . . . . . 8
5.1.1.3. dcmap-stream-id Parameter . . . . . . . . . . . . 8
5.1.1.4. label Parameter . . . . . . . . . . . . . . . . . 9
5.1.1.5. subprotocol Parameter . . . . . . . . . . . . . . 9
5.1.1.6. max-retr Parameter . . . . . . . . . . . . . . . 9
5.1.1.7. max-time Parameter . . . . . . . . . . . . . . . 9
5.1.1.8. ordered Parameter . . . . . . . . . . . . . . . . 10
5.1.1.9. priority Parameter . . . . . . . . . . . . . . . 10
5.1.2. Other Media Level Attributes . . . . . . . . . . . . 10 5.1.2. Other Media Level Attributes . . . . . . . . . . . . 10
5.1.2.1. dcsa Attribute . . . . . . . . . . . . . . . . . 10
5.1.2.2. dcsa Multiplexing Category . . . . . . . . . . . 12
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 12 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 12
5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 13 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 13
5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 14 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 14
5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 16 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 16
5.2.5. Various SDP Offer/Answer Scenarios and Considerations 17 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 17
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21
skipping to change at page 28, line 22 skipping to change at page 28, line 22
already negotiated via DCEP" with "However, an SCTP stream MUST already negotiated via DCEP" with "However, an SCTP stream MUST
NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ NOT be referenced in a dcmap or dcsa attribute of an SDP offer/
answer exchange if the associated SCTP stream has already been answer exchange if the associated SCTP stream has already been
negotiated via DCEP". negotiated via DCEP".
o In the examples in Section 6 addition of the previously missing o In the examples in Section 6 addition of the previously missing
colons to the "a=sctp-port" attribute lines. colons to the "a=sctp-port" attribute lines.
10.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 10.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'
o Move of reference [I-D.ietf-rtcweb-jsep] from the list of o Move of reference draft-ietf-rtcweb-jsep from the list of
normative references to the list of informative references. normative references to the list of informative references.
Remover in -07 since not referenced
o Addition of [IANA-SDP-Parameters] to the list of informative o Addition of [IANA-SDP-Parameters] to the list of informative
references and addition of following two sentences to the first references and addition of following two sentences to the first
paragraph after the ABNF definition: "Note however that not all paragraph after the ABNF definition: "Note however that not all
SDP attributes are suitable as "a=dcsa:" parameter. SDP attributes are suitable as "a=dcsa:" parameter.
[IANA-SDP-Parameters] contains the lists of IANA registered [IANA-SDP-Parameters] contains the lists of IANA registered
session and media level or media level only SDP attributes." session and media level or media level only SDP attributes."
o In the introduction replacement of last sentence "This document o In the introduction replacement of last sentence "This document
defines SDP-based out-of-band negotiation procedures to establish defines SDP-based out-of-band negotiation procedures to establish
skipping to change at page 29, line 29 skipping to change at page 29, line 29
ietf-mmusic-data-channel-sdpneg-02. ietf-mmusic-data-channel-sdpneg-02.
10.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 10.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'
o New Section 4 regarding applicability to SDP offer/answer only. o New Section 4 regarding applicability to SDP offer/answer only.
o Addition of new Section 8.1 "Subprotocol identifiers" as o Addition of new Section 8.1 "Subprotocol identifiers" as
subsection of the "IANA Considerations" related Section 8. Also subsection of the "IANA Considerations" related Section 8. Also
removal of the temporary note "To be completed. As [I-D.ietf- removal of the temporary note "To be completed. As [I-D.ietf-
rtcweb-data-protocol] this document should refer to IANA's rtcweb-data-protocol] this document should refer to IANA's
WebSocket Subprotocol Name Registry defined in [RFC6455]." WebSocket Subprotocol Name Registry defined in [RFC6455]"
o In Section 5.2.2: o In Section 5.2.2:
* In the first paragraph replacement of the sentence "If an SDP * In the first paragraph replacement of the sentence "If an SDP
offer contains both of these parameters then such an SDP offer offer contains both of these parameters then such an SDP offer
will be rejected." with "If an SDP offer contains both of these will be rejected." with "If an SDP offer contains both of these
parameters then the receiver of such an SDP offer MUST reject parameters then the receiver of such an SDP offer MUST reject
the SDP offer." the SDP offer."
* In the second paragraph capitalization of "shall" and "may" * In the second paragraph capitalization of "shall" and "may"
skipping to change at page 30, line 32 skipping to change at page 30, line 32
offer" and "Subsequent SDP answer" replacement of "All the offer" and "Subsequent SDP answer" replacement of "All the
externally negotiated data channels must be closed now." with "All externally negotiated data channels must be closed now." with "All
the externally negotiated data channels are expected to be closed the externally negotiated data channels are expected to be closed
now.". now.".
o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]" o In Appendix A.2.2's sixth paragraph beginning with "[ASSUMPTION]"
replacement of the two occurrences of "must" with "MUST". replacement of the two occurrences of "must" with "MUST".
o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt"
there was a comment saying that "Either only maxretr-opt or there was a comment saying that "Either only maxretr-opt or
maxtime-opt is present. Both MUST not be present." Removal of maxtime-opt is present. Both MUST NOT be present." Removal of
the second normative sentence and instead addition of following the second normative sentence and instead addition of following
new paragraph to the end of this section: "Within an 'a=dcmap' new paragraph to the end of this section: "Within an 'a=dcmap'
attribute line's 'dcmap-opt' value either only one 'maxretr-opt' attribute line's 'dcmap-opt' value either only one 'maxretr-opt'
parameter or one 'maxtime-opt' parameter is present. Both MUST parameter or one 'maxtime-opt' parameter is present. Both MUST
NOT be present." NOT be present."
o In Section 5.1.1.8 replacement of the first sentence "The o In Section 5.1.1.8 replacement of the first sentence "The
'ordered' parameter with value "true" indicates that DATA chunks 'ordered' parameter with value "true" indicates that DATA chunks
in the channel MUST be dispatched to the upper layer by the in the channel MUST be dispatched to the upper layer by the
receiver while preserving the order." with "The 'ordered' receiver while preserving the order." with "The 'ordered'
skipping to change at page 31, line 9 skipping to change at page 31, line 9
o In Section 5.2.3's first paragraph replacement of the one o In Section 5.2.3's first paragraph replacement of the one
occurrence of "must" with "..., it MUST wait until ...". occurrence of "must" with "..., it MUST wait until ...".
o In Section 5.2.4: o In Section 5.2.4:
* In the second paragraph replacement of "must" with "... whether * In the second paragraph replacement of "must" with "... whether
this closing MUST in addition ..." this closing MUST in addition ..."
* In the third paragraph replacement of the sentence "The port * In the third paragraph replacement of the sentence "The port
value for the "m" line SHOULD not be changed (e.g., to zero) value for the "m" line SHOULD NOT be changed (e.g., to zero)
when closing a data channel ..." with "The offerer SHOULD NOT when closing a data channel ..." with "The offerer SHOULD NOT
change the port value for the "m" line (e.g., to zero) when change the port value for the "m" line (e.g., to zero) when
closing a data channel ...". closing a data channel ...".
* In the last but two paragraph replacement of the sentence "... * In the last but two paragraph replacement of the sentence "...
then an SDP offer which excludes this closed data channel then an SDP offer which excludes this closed data channel
SHOULD be generated." with "... then the client SHOULD generate SHOULD be generated." with "... then the client SHOULD generate
an SDP offer which excludes this closed data channel.". an SDP offer which excludes this closed data channel.".
* In the last but one paragraph replacement of "must" with "The * In the last but one paragraph replacement of "must" with "The
skipping to change at page 33, line 28 skipping to change at page 33, line 28
o In Section 5.2.3 the second sentence of the third SDP answerer o In Section 5.2.3 the second sentence of the third SDP answerer
action was "Note that the browser is asked to create data channels action was "Note that the browser is asked to create data channels
with stream identifiers not "owned" by the agent.". Replacement with stream identifiers not "owned" by the agent.". Replacement
of this sentence with "Note that the agent is asked to create data of this sentence with "Note that the agent is asked to create data
channels with SCTP stream identifiers contained in the SDP offer channels with SCTP stream identifiers contained in the SDP offer
if the SDP offer is accepted." if the SDP offer is accepted."
o In Section 5.2.4 the third paragraph began with "A data channel o In Section 5.2.4 the third paragraph began with "A data channel
can be closed by sending a new SDP offer which excludes the dcmap can be closed by sending a new SDP offer which excludes the dcmap
and dcsa attribute lines for the data channel. The port value for and dcsa attribute lines for the data channel. The port value for
the m line should not be changed (e.g., to zero) when closing a the m line SHOULD NOT be changed (e.g., to zero) when closing a
data channel (unless all data channels are being closed and the data channel (unless all data channels are being closed and the
SCTP association is no longer needed), since this would close the SCTP association is no longer needed), since this would close the
SCTP association and impact all of the data channels. If the SCTP association and impact all of the data channels. If the
answerer accepts the SDP offer then it MUST also exclude the answerer accepts the SDP offer then it MUST also exclude the
corresponding attribute lines in the answer. ..." Replacement of corresponding attribute lines in the answer. ..." Replacement of
this part with "The intention to close a data channel can be this part with "The intention to close a data channel can be
signaled by sending a new SDP offer which excludes the "a=dcmap:" signaled by sending a new SDP offer which excludes the "a=dcmap:"
and "a=dcsa:" attribute lines for the data channel. The port and "a=dcsa:" attribute lines for the data channel. The port
value for the "m" line SHOULD not be changed (e.g., to zero) when value for the "m" line SHOULD NOT be changed (e.g., to zero) when
closing a data channel (unless all data channels are being closed closing a data channel (unless all data channels are being closed
and the SCTP association is no longer needed), since this would and the SCTP association is no longer needed), since this would
close the SCTP association and impact all of the data channels. close the SCTP association and impact all of the data channels.
If the answerer accepts the SDP offer then it MUST close those If the answerer accepts the SDP offer then it MUST close those
data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were
excluded from the received SDP offer, unless those data channels excluded from the received SDP offer, unless those data channels
were already closed, and it MUST also exclude the corresponding were already closed, and it MUST also exclude the corresponding
attribute lines in the answer." attribute lines in the answer."
o In Section 5.2.4 the hanging text after the third paragraph was o In Section 5.2.4 the hanging text after the third paragraph was
skipping to change at page 34, line 19 skipping to change at page 34, line 19
Section 5.1.1 contained already procedural descriptions related to Section 5.1.1 contained already procedural descriptions related to
data channel reliability negotiation. Creation of new data channel reliability negotiation. Creation of new
Section 5.2.2 and moval of reliability negotiation related text to Section 5.2.2 and moval of reliability negotiation related text to
this new section. this new section.
10.14. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 10.14. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02'
o Removal of note "[ACTION ITEM]" from section "subprotocol o Removal of note "[ACTION ITEM]" from section "subprotocol
parameter". As [I-D.ietf-rtcweb-data-protocol] this document parameter". As [I-D.ietf-rtcweb-data-protocol] this document
should refer to IANA's WebSocket Subprotocol Name Registry defined should refer to IANA's WebSocket Subprotocol Name Registry defined
in [RFC6455]. in [RFC6455]
o In whole document, replacement of "unreliable" with "partially o In whole document, replacement of "unreliable" with "partially
reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in
[I-D.ietf-rtcweb-data-protocol] in most places. [I-D.ietf-rtcweb-data-protocol] in most places.
o Clarification of the semantic if the "max-retr" parameter is not o Clarification of the semantic if the "max-retr" parameter is not
present in an a=dcmap attribute line. In section "max-retr present in an a=dcmap attribute line. In section "max-retr
parameter" the sentence "The max-retr parameter is optional with parameter" the sentence "The max-retr parameter is optional with
default value unbounded" was replaced with "The max-retr parameter default value unbounded" was replaced with "The max-retr parameter
is optional. If the max-retr parameter is not present, then the is optional. If the max-retr parameter is not present, then the
skipping to change at page 36, line 6 skipping to change at page 36, line 6
introduced with draft-ietf-mmusic-sctp-sdp-07. introduced with draft-ietf-mmusic-sctp-sdp-07.
o Removal of the SCTP port number from the a=dcmap and a=dcsa o Removal of the SCTP port number from the a=dcmap and a=dcsa
attributes as this is now contained in the a=sctp-port attribute, attributes as this is now contained in the a=sctp-port attribute,
and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP
association on top of the DTLS connection. association on top of the DTLS connection.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[I-D.ietf-mmusic-rfc4566bis] [I-D.ietf-mmusic-rfc4566bis]
Handley, M., Jacobson, V., Perkins, C., and A. Begen, Handley, M., Perkins, C., and A. Begen, "SDP: Session
"SDP: Session Description Protocol", draft-ietf-mmusic- Description Protocol", draft-ietf-mmusic-rfc4566bis-24
rfc4566bis-17 (work in progress), June 2016. (work in progress), October 2017.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015.
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
Procedures For Stream Control Transmission Protocol (SCTP) Procedures For Stream Control Transmission Protocol (SCTP)
over Datagram Transport Layer Security (DTLS) Transport.", over Datagram Transport Layer Security (DTLS) Transport.",
draft-ietf-mmusic-sctp-sdp-26 (work in progress), April draft-ietf-mmusic-sctp-sdp-26 (work in progress), April
2017. 2017.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 2016.
11.2. Informative References [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015.
[I-D.ietf-rtcweb-data-protocol] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Requirement Levels", BCP 14, RFC 2119,
Establishment Protocol", draft-ietf-rtcweb-data- DOI 10.17487/RFC2119, March 1997,
protocol-09 (work in progress), January 2015. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
11.2. Informative References
[I-D.ietf-mmusic-dtls-sdp] [I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-30 (work in progress), draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
September 2017. 2017.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [I-D.ietf-rtcweb-data-protocol]
RFC 4960, DOI 10.17487/RFC4960, September 2007, Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
<https://www.rfc-editor.org/info/rfc4960>. Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015.
[IANA-SDP-Parameters] [IANA-SDP-Parameters]
"Session Description Protocol (SDP) Parameters", Internet "Session Description Protocol (SDP) Parameters", Internet
Assigned Numbers Authority Protocol Assignments Session Assigned Numbers Authority Protocol Assignments Session
Description Protocol (SDP) Parameters, Description Protocol (SDP) Parameters,
<http://www.iana.org/assignments/sdp-parameters/ <http://www.iana.org/assignments/sdp-parameters/
sdp-parameters.xhtml>. sdp-parameters.xhtml>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>.
[WebRtcAPI] [WebRtcAPI]
Bergkvist, A., Burnett, D., Jennings, C., and A. Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-time Communication Between Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD-webrtc-20150210, Browsers", World Wide Web Consortium WD-webrtc-20150210,
February 2015, February 2015,
<http://www.w3.org/TR/2015/WD-webrtc-20150210/>. <http://www.w3.org/TR/2015/WD-webrtc-20150210/>.
Appendix A. Generic Data Channel Negotiation Aspects When Not Using Appendix A. Generic Data Channel Negotiation Aspects When Not Using
DCEP DCEP
skipping to change at page 38, line 10 skipping to change at page 38, line 12
priority). The application also specifies if it wants to make use of priority). The application also specifies if it wants to make use of
the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if
the application intends to negotiate data channels using the SDP the application intends to negotiate data channels using the SDP
offer/answer protocol. offer/answer protocol.
In any case, the SDP offer generated by the application is per In any case, the SDP offer generated by the application is per
[I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for
the SCTP association on top of which data channels will run: the SCTP association on top of which data channels will run:
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 10.10.10.1 c=IN IP4 192.0.2.1
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port:5000 a=sctp-port:5000
a=dtls-id:abcdef1234567 a=dtls-id:abcdef1234567
a=setup:actpass a=setup:actpass
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
Note: A WebRTC application will only use "m" line format "webrtc- Note: A WebRTC application will only use "m" line format "webrtc-
datachannel", and will not use other formats in the "m" line for datachannel", and will not use other formats in the "m" line for
other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports
skipping to change at page 40, line 31 skipping to change at page 40, line 31
When the application requests the closing of a data channel When the application requests the closing of a data channel
negotiated without DCEP, the data channel stack always performs an negotiated without DCEP, the data channel stack always performs an
SCTP SSN reset for this channel. SCTP SSN reset for this channel.
Depending upon the method used for DCEP-less negotiation and the Depending upon the method used for DCEP-less negotiation and the
subprotocol associated with the data channel, the closing might in subprotocol associated with the data channel, the closing might in
addition be signaled to the peer via SDP offer/answer negotiation. addition be signaled to the peer via SDP offer/answer negotiation.
Authors' Addresses Authors' Addresses
Keith Drage (editor) Keith Drage
Unaffiliated Unaffiliated
Email: drageke@ntlworld.com Email: drageke@ntlworld.com
Maridi R. Makaraju (Raju) Maridi R. Makaraju (Raju)
Nokia Nokia
2000 Lucent Lane 2000 Lucent Lane
Naperville, Illinois Naperville, Illinois
US US
skipping to change at line 1875 skipping to change at page 41, line 11
Unaffiliated Unaffiliated
Email: Juergen.S-B.ietf@email.de Email: Juergen.S-B.ietf@email.de
Richard Ejzak Richard Ejzak
Unaffiliated Unaffiliated
Email: richard.ejzak@gmail.com Email: richard.ejzak@gmail.com
Jerome Marcon Jerome Marcon
Unaffiliated Unaffiliated
Roni Even (editor)
Huawei
Email: roni.even@huawei.com
 End of changes. 27 change blocks. 
65 lines changed or deleted 62 lines changed or added

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