draft-ietf-mmusic-msrp-usage-data-channel-16.txt   draft-ietf-mmusic-msrp-usage-data-channel-17.txt 
MMUSIC J. Recio, Ed. MMUSIC J. Recio, Ed.
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track C. Holmberg Intended status: Standards Track C. Holmberg
Expires: November 5, 2020 Ericsson Expires: November 30, 2020 Ericsson
May 4, 2020 May 29, 2020
MSRP over Data Channels MSRP over Data Channels
draft-ietf-mmusic-msrp-usage-data-channel-16 draft-ietf-mmusic-msrp-usage-data-channel-17
Abstract Abstract
This document specifies how the Message Session Relay Protocol (MSRP) This document specifies how the Message Session Relay Protocol (MSRP)
can be transported as a WebRTC data channel sub-protocol, using the can be transported as a WebRTC data channel sub-protocol, using the
SDP offer/answer generic data channel negotiation framework to SDP offer/answer generic data channel negotiation framework to
establish such a channel. Two network configurations are supported: establish such a channel. Two network configurations are supported:
connecting two MSRP over data channel endpoints; and a gateway connecting two MSRP over data channel endpoints; and a gateway
configuration, connecting an MSRP over data channel endpoint with an configuration, connecting an MSRP over data channel endpoint with an
MSRP over TCP or TLS endpoint. MSRP over TCP or TLS endpoint. This document updates [RFC4975]
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 November 5, 2020. This Internet-Draft will expire on November 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 28 skipping to change at page 2, line 28
4.4. Use of the dcsa Attribute . . . . . . . . . . . . . . . . 6 4.4. Use of the dcsa Attribute . . . . . . . . . . . . . . . . 6
4.5. Use of the dcsa embedded setup Attribute . . . . . . . . 7 4.5. Use of the dcsa embedded setup Attribute . . . . . . . . 7
4.6. Session Closing . . . . . . . . . . . . . . . . . . . . . 7 4.6. Session Closing . . . . . . . . . . . . . . . . . . . . . 7
4.7. Support for MSRP File Transfer Function . . . . . . . . . 7 4.7. Support for MSRP File Transfer Function . . . . . . . . . 7
4.8. Example SDP Negotiation . . . . . . . . . . . . . . . . . 8 4.8. Example SDP Negotiation . . . . . . . . . . . . . . . . . 8
5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 8 5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 8
5.2. Session Opening . . . . . . . . . . . . . . . . . . . . . 9 5.2. Session Opening . . . . . . . . . . . . . . . . . . . . . 9
5.3. Session Closing . . . . . . . . . . . . . . . . . . . . . 9 5.3. Session Closing . . . . . . . . . . . . . . . . . . . . . 9
5.4. Data Framing . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Data Framing . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Data Sending and Reporting . . . . . . . . . . . . . . . 9 5.5. Data Sending, Receiving and Reporting . . . . . . . . . . 9
5.6. Support for MSRP File Transfer Function . . . . . . . . . 9 5.6. Support for MSRP File Transfer Function . . . . . . . . . 9
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Updates to RFC4975 . . . . . . . . . . . . . . . . . . . . . 10
7.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 10
7.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. msrps URI scheme . . . . . . . . . . . . . . . . . . . . 11
10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data- 9.2. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 11
9.3. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-16' . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-15' . . . . . . . . . . . . . . . . . . . . . . 12 channel-15' . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-14' . . . . . . . . . . . . . . . . . . . . . . 12 channel-14' . . . . . . . . . . . . . . . . . . . . . . 12
10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-13' . . . . . . . . . . . . . . . . . . . . . . 12 channel-13' . . . . . . . . . . . . . . . . . . . . . . 12
10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-12' . . . . . . . . . . . . . . . . . . . . . . 12 channel-12' . . . . . . . . . . . . . . . . . . . . . . 12
10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-11' . . . . . . . . . . . . . . . . . . . . . . 12 channel-11' . . . . . . . . . . . . . . . . . . . . . . 13
10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-10' . . . . . . . . . . . . . . . . . . . . . . 12 channel-10' . . . . . . . . . . . . . . . . . . . . . . 13
10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-09' . . . . . . . . . . . . . . . . . . . . . . 12 channel-09' . . . . . . . . . . . . . . . . . . . . . . 13
10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-08' . . . . . . . . . . . . . . . . . . . . . . 12 channel-08' . . . . . . . . . . . . . . . . . . . . . . 13
10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-07' . . . . . . . . . . . . . . . . . . . . . . 13 channel-07' . . . . . . . . . . . . . . . . . . . . . . 13
10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-06' . . . . . . . . . . . . . . . . . . . . . . 13 channel-06' . . . . . . . . . . . . . . . . . . . . . . 13
10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-05' . . . . . . . . . . . . . . . . . . . . . . 13 channel-05' . . . . . . . . . . . . . . . . . . . . . . 14
10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-04' . . . . . . . . . . . . . . . . . . . . . . 13 channel-04' . . . . . . . . . . . . . . . . . . . . . . 14
10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-03' . . . . . . . . . . . . . . . . . . . . . . 13 channel-03' . . . . . . . . . . . . . . . . . . . . . . 14
10.14. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-02' . . . . . . . . . . . . . . . . . . . . . . 13 channel-02' . . . . . . . . . . . . . . . . . . . . . . 14
10.15. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-01' . . . . . . . . . . . . . . . . . . . . . . 14 channel-01' . . . . . . . . . . . . . . . . . . . . . . 15
10.16. Changes against 'draft-ietf-mmusic-msrp-usage-data- 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-00' . . . . . . . . . . . . . . . . . . . . . . 15 channel-00' . . . . . . . . . . . . . . . . . . . . . . 16
10.17. Changes against 'draft-ejzak-mmusic-msrp-usage-data- 11.18. Changes against 'draft-ejzak-mmusic-msrp-usage-data-
channel-01' . . . . . . . . . . . . . . . . . . . . . . 16 channel-01' . . . . . . . . . . . . . . . . . . . . . . 17
10.18. Changes against '-00' . . . . . . . . . . . . . . . . . 16 11.19. Changes against '-00' . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . 16 12. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for
transmitting a series of related instant messages in the context of a transmitting a series of related instant messages in the context of a
session. In addition to instant messaging, MSRP can also be used for session. In addition to instant messaging, MSRP can also be used for
image sharing or file transfer. MSRP is currently defined to work image sharing or file transfer. MSRP was initially defined in
over TCP and TLS connections, and over a WebSocket subprotocol [RFC4975] to work over TCP and TLS connections, and over a WebSocket
specified by [RFC7977]. subprotocol specified by [RFC7977].
This document specifies the negotiation and transport of MSRP over a This document specifies the negotiation and transport of MSRP over a
WebRTC data channel [I-D.ietf-rtcweb-data-channel]. Negotiation is WebRTC data channel [I-D.ietf-rtcweb-data-channel]. Negotiation is
carried out as specified in [I-D.ietf-mmusic-data-channel-sdpneg] and carried out as specified in [I-D.ietf-mmusic-data-channel-sdpneg] and
MSRP is transported as a sub-protocol of a WebRTC data channel. MSRP is transported as a sub-protocol of a WebRTC data channel,
without the TCP and TLS layers.
Defining MSRP as a data channel sub-protocol has many benefits: Defining MSRP as a data channel sub-protocol has many benefits:
o provides to applications a proven protocol enabling instant o provides to applications a proven protocol enabling instant
messaging, file transfer, image sharing messaging, file transfer, image sharing
o integrates those features with other RTCWeb voice, video and data o integrates those features with other WebRTC voice, video and data
features features
o leverages the SDP-based negotiation already defined for MSRP o leverages the SDP-based negotiation already defined for MSRP
o allows the interworking with MSRP endpoints running on a TCP or o allows the interworking with MSRP endpoints running on a TCP or
TLS connection TLS connection
Compared to WebSockets, which provide a message passing protocol to Compared to WebSockets, which provide a message passing protocol to
applications with no direct access to TCP or TLS sockets, data applications with no direct access to TCP or TLS sockets, data
channels provide a low latency transport, leverage NAT-aware channels provide a low latency transport, leverage NAT-aware
connectivity and security features of WebRTC, and are increasingly connectivity and security features of WebRTC, and are increasingly
available not only in modern browsers but in other applications that available not only in modern browsers but in other applications that
use WebRTC for media or other purposes, such as IoT or telemetry in use WebRTC for media or other purposes, such as IoT or telemetry in
general, non-media data exchange, and so on. general, non-media data exchange, and so on.
skipping to change at page 4, line 36 skipping to change at page 4, line 42
3. WebRTC Data Channel Considerations 3. WebRTC Data Channel Considerations
3.1. MSRP Data Channel 3.1. MSRP Data Channel
In this document, an MSRP data channel is a data channel for which In this document, an MSRP data channel is a data channel for which
the instantiated sub-protocol is "MSRP", and where the channel is the instantiated sub-protocol is "MSRP", and where the channel is
negotiated using the SDP-based external negotiation method defined in negotiated using the SDP-based external negotiation method defined in
[I-D.ietf-mmusic-data-channel-sdpneg]. [I-D.ietf-mmusic-data-channel-sdpneg].
The following WebRTC data channel property values [I-D.ietf-rtcweb- The following WebRTC data channel property values
data-channel] apply to a MSRP data channel: [I-D.ietf-rtcweb-data-channel] apply to a MSRP data channel:
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
| Property | Value | | Property | Value |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
| Subprotocol Identifier | MSRP | | Subprotocol Identifier | msrp |
| Transmission reliability | reliable | | Transmission reliability | reliable |
| Transmission order | in-order | | Transmission order | in-order |
| Label | See Section 4.3 | | Label | See Section 4.3 |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
4. SDP Considerations 4. SDP Considerations
This section describes the SDP considerations which are specific to a This section describes the SDP considerations which are specific to a
MSRP data channel MSRP data channel
4.1. MSRP URI 4.1. MSRP URI
This document extends the MSRP URI syntax [RFC4975] by defining the This document extends the MSRP URI syntax [RFC4975] by defining the
new transport parameter value "dc": new transport parameter value "dc":
transport /= "dc" / 1*ALPHANUM transport /= "dc"
; Add "dc" to existing transports per [RFC4975] ; Add "dc" to existing transports per [RFC4975]
MSRP design provides for new transport bindings, see Section 6 of MSRP design provides for new transport bindings, see Section 6 of
[RFC4975], MSRP implementations are expected to allow unrecognized [RFC4975], MSRP implementations are expected to allow unrecognized
transports for which there is no need to establish a connection to transports for which there is no need to establish a connection to
the resource described by the URI, as it's the case of data channels the resource described by the URI, as it's the case of data channels
(Section 4.4). (Section 4.4).
4.2. msrp-scheme 4.2. msrp-scheme
The msrp-scheme portion of the MSRP-URI that represents an MSRP data The msrp-scheme portion of the MSRP-URI that represents an MSRP data
channel endpoint (used in the SDP path attribute and in the MSRP channel endpoint (used in the SDP path attribute and in the MSRP
message headers) is always "msrps", which indicates that the MSRP message headers) is always "msrps", which indicates that the MSRP
data channel is always secured using DTLS as described in data channel is always secured using DTLS as described in
[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-rtcweb-data-channel].
4.3. Use of the dcmap Attribute 4.3. Use of the dcmap Attribute
An offerer and answerer MUST, in each offer and answer, include a An offerer and answerer SHALL, in each offer and answer, include a
dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within
the media description of the SCTP association for each MSRP data the media description of the SCTP association for each MSRP data
channel session to be negotiated. channel session to be negotiated.
The attribute includes the following data channel parameters: The attribute includes the following data channel parameters:
o "label=" labelstring o "label=" labelstring
o "subprotocol=" "MSRP" o "subprotocol=" "msrp"
The labelstring is set by the MSRP application according to The labelstring is set by the MSRP application according to
[I-D.ietf-mmusic-data-channel-sdpneg]. [I-D.ietf-mmusic-data-channel-sdpneg].
The offerer and answerer MUST NOT include the max-retr and the max- The offerer and answerer SHALL NOT include the max-retr and the max-
time attribute parameters in the dcmap attribute. time attribute parameters in the dcmap attribute.
The offerer and answerer MAY include the ordered attribute parameter The offerer and answerer MAY include the ordered attribute parameter
in the dcmap attribute. If included, the attribute parameter value in the dcmap attribute. If included, the attribute parameter value
MUST be set to "true". SHALL be set to "true".
Below is an example of the dcmap attribute for an MSRP session to be Below is an example of the dcmap attribute for an MSRP session to be
negotiated with stream-id=2 and label="chat": negotiated with stream-id=2 and label="chat":
a=dcmap:2 label="chat";subprotocol="MSRP" a=dcmap:2 label="chat";subprotocol="msrp"
4.4. Use of the dcsa Attribute 4.4. Use of the dcsa Attribute
An offerer and answerer MUST, in each offer and answer, include a An offerer and answerer SHALL, in each offer and answer, include a
dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within
the media description for the SCTP association for each MSRP-specific the media description for the SCTP association for each MSRP-specific
SDP attribute to be negotiated for each MSRP data channel being SDP attribute to be negotiated for each MSRP data channel being
negotiated. negotiated.
An offerer and answerer MUST include a dcsa attribute for the An offerer and answerer SHALL include a dcsa attribute for each of
following MSRP-specific SDP attributes: the following MSRP-specific SDP attributes:
o defined in [RFC4975]: "path". o defined in [RFC4975]: "path".
o defined in [RFC6714]: "msrp-cema". o defined in [RFC6714]: "msrp-cema".
o defined in [RFC6135]: "setup". See Section 4.5 o defined in [RFC6135]: "setup". See Section 4.5
It is considered a protocol error if one or more of the dcsa embedded It is considered a protocol error if one or more of the dcsa embedded
attributes listed above are not included in an offer or answer. attributes listed above are not included in an offer or answer.
An offerer and answerer MAY include a dcsa attribute for the An offerer and answerer MAY include a dcsa attribute for any of the
following MSRP-specific SDP attributes, following the procedures following MSRP-specific SDP attributes, following the procedures
defined for each attributes: defined for each attributes:
o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and
"max-size" "max-size"
o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and
"sendrecv" "sendrecv"
o defined in [RFC5547]: all the parameters related to MSRP file o defined in [RFC5547]: all the parameters related to MSRP file
transfer. See Section 4.7. transfer. See Section 4.7.
A subsequent offer or answer MAY update the previously negotiated A subsequent offer or answer MAY update the previously negotiated
MSRP subprotocol attributes while keeping the same subprotocol MSRP subprotocol attributes while keeping the same subprotocol
a=dcmap description. The semantics for newly negotiated MSRP a=dcmap description. The semantics for newly negotiated MSRP
subprotocol attributes are per [RFC4975]. subprotocol attributes are per [RFC4975].
The path attribute SHALL NOT be used for transport negotiation. When MSRP messages are transported on a data channel, the "path"
attribute is not used for routing of the messages. The MSRP data
channel is established using the SDP offer/answer procedures defined
in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are
then transported on that data channel. This is different from legacy
MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. However, when an
endpoint receives an MSRP message over a data channel, it MUST still
perform the MSRP-URI comparison procedures defined in [RFC4975].
4.5. Use of the dcsa embedded setup Attribute 4.5. Use of the dcsa embedded setup Attribute
As described in Section 4.4, the usage of a dsca embedded setup As described in Section 4.4, the usage of a dsca embedded setup
attribute is mandated for MSRP sessions over data channels. It is attribute is mandated for MSRP sessions over data channels. It is
used to negotiate which MSRP session endpoint assumes the active role used to negotiate which MSRP session endpoint assumes the active role
as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It
has no relationship with the DTLS connection establishment roles has no relationship with the DTLS connection establishment roles
[I-D.ietf-mmusic-sctp-sdp]. [I-D.ietf-mmusic-sctp-sdp].
The dcsa embedded setup attribute is of the form "a=dcsa:x The dcsa embedded setup attribute is of the form "a=dcsa:x
setup:<role>", with x being the data channel's SCTP stream setup:<role>", with x being the data channel's SCTP stream
identifier, so that such attribute is explicitly associated with an identifier, so that such attribute is explicitly associated with an
MSRP session over a specific data channel. MSRP session over a specific data channel.
4.6. Session Closing 4.6. Session Closing
The closure of an MSRP session MUST be signaled via an SDP offer/ An MSRP session is closed by closing the associated data channel,
answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute following the procedures in [I-D.ietf-mmusic-data-channel-sdpneg].
lines associated with the MSRP session from the associated DTLS/SCTP
based media description. This results in the associated data channel
being closed as well as per [I-D.ietf-mmusic-data-channel-sdpneg],
where the actual data channel closure procedure is typically
initiated by the SDP answerer right after having accepted the SDP
offer.
The port value for the "m" line SHOULD NOT be changed (e.g. to zero) The port value for the "m=" line SHOULD NOT be changed (e.g. to zero)
when closing an MSRP session (unless all data channels are being when closing an MSRP session (unless all data channels are being
closed and the SCTP association is no longer needed), since this closed and the SCTP association is no longer needed), since this
would close the SCTP association and impact all of the data channels. would close the SCTP association and impact all of the data channels.
In all cases in [RFC4975] where the procedure calls for setting the In all cases in [RFC4975] where the procedure calls for setting the
port to zero for the MSRP "m" line in an SDP offer for TCP transport, port to zero for the MSRP "m=" line in an SDP offer for TCP
the SDP offerer of an MSRP session with data channel transport SHALL transport, the SDP offerer of an MSRP session with data channel
remove the corresponding dcmap and dcsa attributes. transport SHALL remove the corresponding dcmap and dcsa attributes.
The SDP answerer must ensure that no dcmap or dcsa attributes are The SDP answerer must ensure that no dcmap or dcsa attributes are
present in the SDP answer if no corresponding attributes are present present in the SDP answer if no corresponding attributes are present
in the received SDP offer. in the received SDP offer.
4.7. Support for MSRP File Transfer Function 4.7. Support for MSRP File Transfer Function
SDP attributes specified in [RFC5547] for a file transfer "m" line SDP attributes specified in [RFC5547] for a file transfer "m=" line
are embedded as subprotocol-specific attributes using the syntax are embedded as subprotocol-specific attributes using the syntax
defined in [I-D.ietf-mmusic-data-channel-sdpneg]. defined in [I-D.ietf-mmusic-data-channel-sdpneg].
4.8. Example SDP Negotiation 4.8. Example SDP Negotiation
The following is an example of an "m" line for data channels in an The following is an example of an "m=" line for data channels in an
SDP offer that includes the attributes needed to establish two MSRP SDP offer that includes the attributes needed to establish two MSRP
sessions: one for chat and one for file transfer. The example is sessions: one for chat and one for file transfer. The example is
derived from a combination of examples in [RFC4975] and [RFC5547]. derived from a combination of examples in [RFC4975] and [RFC5547].
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 198.51.100.79 c=IN IP4 198.51.100.79
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port:5000 a=sctp-port:5000
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
a=tls-id:4a756565cddef001be82 a=tls-id:4a756565cddef001be82
a=dcmap:0 label="chat";subprotocol="MSRP" a=dcmap:0 label="chat";subprotocol="msrp"
a=dcsa:0 msrp-cema a=dcsa:0 msrp-cema
a=dcsa:0 setup:active a=dcsa:0 setup:active
a=dcsa:0 accept-types:message/cpim text/plain a=dcsa:0 accept-types:message/cpim text/plain
a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc a=dcsa:0 path:msrps://198.51.100.79:54111/si438dsaodes;dc
a=dcmap:2 label="file transfer";subprotocol="MSRP" a=dcmap:2 label="file transfer";subprotocol="msrp"
a=dcsa:2 sendonly a=dcsa:2 sendonly
a=dcsa:2 msrp-cema a=dcsa:2 msrp-cema
a=dcsa:2 setup:active a=dcsa:2 setup:active
a=dcsa:2 accept-types:message/cpim a=dcsa:2 accept-types:message/cpim
a=dcsa:2 accept-wrapped-types:* a=dcsa:2 accept-wrapped-types:*
a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc a=dcsa:2 path:msrps://198.51.100.79:54111/jshA7we;dc
a=dcsa:2 file-selector:name:"picture1.jpg" \ a=dcsa:2 file-selector:name:"picture1.jpg" \
type:image/jpeg size:1463440 hash:sha-1:\ type:image/jpeg size:1463440 hash:sha-1:\
FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4 FF:27:0D:81:14:F1:8A:C3:35:3B:36:64:2A:62:C9:3E:D3:6B:51:B4
a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep
a=dcsa:2 file-disposition:attachment a=dcsa:2 file-disposition:attachment
a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800" a=dcsa:2 file-date:creation:"Mon, 12 Jan 2018 15:01:31 +0800"
a=dcsa:2 file-icon:cid:id2@bob.example.com a=dcsa:2 file-icon:cid:id2@bob.example.com
a=dcsa:2 file-range:1-1463440 a=dcsa:2 file-range:1-1463440
5. MSRP Considerations 5. MSRP Considerations
This section describes the MSRP considerations specific to a MSRP The procedures specified in [RFC4975] apply except when this document
data channel. specifies otherwise. This section describes the MSRP considerations
specific to a MSRP data channel.
5.1. Session Mapping 5.1. Session Mapping
In this document, each MSRP session maps to one data channel exactly. In this document, each MSRP session maps to one data channel exactly.
5.2. Session Opening 5.2. Session Opening
Section 4.5 describes how the active MSRP session endpoint role is Section 4.5 describes how the active MSRP session endpoint role is
negotiated. The active MSRP session endpoint uses the data channel negotiated. The active MSRP session endpoint uses the data channel
established for this MSRP session by the generic data channel opening established for this MSRP session by the generic data channel opening
procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg].
As soon as the WebRTC data channel is opened, the MSRP session is As soon as the WebRTC data channel is opened, the MSRP session is
actually opened by the active MSRP session endpoint. In order to do actually opened by the active MSRP session endpoint. In order to do
this the active MSRP endpoint sends an MSRP SEND message (empty or this the active MSRP endpoint sends an MSRP SEND message (empty or
not) to the other MSRP endpoint. not) to the other MSRP endpoint.
5.3. Session Closing 5.3. Session Closing
The closure of an MSRP session MUST be signaled via SDP following the The closure of an MSRP session SHALL be signaled via SDP following
requirements in Section 4.6 the requirements in Section 4.6
If the data channel used to transport the MSRP session fails and gets
torn down, the endpoints SHALL consider the MSRP session failed. An
MSRP endpoint MAY, based on local policy, try to negotiate a new MSRP
data channel.
5.4. Data Framing 5.4. Data Framing
Each text-based MSRP message is sent on the corresponding SCTP stream Each text-based MSRP message is sent on the corresponding SCTP stream
using standard MSRP framing and chunking procedures, as defined in using standard MSRP framing and chunking procedures, as defined in
[RFC4975], with each MSRP chunk delivered in a single SCTP user [RFC4975], with each MSRP chunk delivered in a single SCTP user
message. Therefore all sent MSRP chunks including the MSRP chunk message. Therefore all sent MSRP chunks including the MSRP chunk
header MUST have lengths of less than or equal to the value of the header SHALL have lengths of less than or equal to the value of the
peer's "a=max-message-size" attribute, which is associated with the peer's "a=max-message-size" attribute, which is associated with the
data channel's SCTP association. data channel's SCTP association.
5.5. Data Sending and Reporting 5.5. Data Sending, Receiving and Reporting
Data sending and reporting procedures SHALL conform to [RFC4975]. Data sending, receiving and reporting procedures SHALL conform to
[RFC4975].
5.6. Support for MSRP File Transfer Function 5.6. Support for MSRP File Transfer Function
[RFC5547] defines an end-to-end file transfer method based on MSRP [RFC5547] defines an end-to-end file transfer method based on MSRP
and the SDP offer/answer mechanism. This file transfer method is and the SDP offer/answer mechanism. This file transfer method is
also usable by MSRP endpoints using data channels, with the following also usable by MSRP endpoints using data channels, with the following
considerations: considerations:
o As an MSRP session maps to one data channel, a file transfer o As an MSRP session maps to one data channel, a file transfer
session maps also to one data channel. session maps also to one data channel.
skipping to change at page 10, line 29 skipping to change at page 10, line 32
Alternately, the gateway can provide transport level interworking Alternately, the gateway can provide transport level interworking
between MSRP endpoints using different transport protocols. In between MSRP endpoints using different transport protocols. In
accordance with Section 4.4, path attributes SHALL NOT be used for accordance with Section 4.4, path attributes SHALL NOT be used for
transport level interworking. transport level interworking.
When the gateway performs transport level interworking between MSRP When the gateway performs transport level interworking between MSRP
endpoints, all of the procedures in Section 5 and Section 4 apply to endpoints, all of the procedures in Section 5 and Section 4 apply to
each peer, with the following additions: each peer, with the following additions:
o The gateway MUST use CEMA towards the non-data channel endpoint. o The gateway SHALL use CEMA towards the non-data channel endpoint.
o If the non-data channel endpoint does not support CEMA, transport o If the non-data channel endpoint does not support CEMA, transport
level interworking mode is not possible, the gateway needs to act level interworking mode is not possible, the gateway needs to act
as an MSRP B2BUA. as an MSRP B2BUA.
o The gateway MUST NOT modify the path attribute received from data o The gateway SHALL NOT modify the path attribute received from data
channel or from non-data channel endpoints. channel or from non-data channel endpoints.
o The gateway MUST NOT modify the setup value received from data o The gateway SHALL NOT modify the setup value received from data
channel or from non-data channel endpoints. channel or from non-data channel endpoints.
o The endpoint establishing an MSRP session using data channel o The endpoint establishing an MSRP session using data channel
transport SHALL NOT request inclusion of any relays, although it transport SHALL NOT request inclusion of any relays, although it
MAY interoperate with a peer that signals the use of relays. MAY interoperate with a peer that signals the use of relays.
7. IANA Considerations 7. Updates to RFC4975
7.1. Subprotocol Identifier MSRP This document updates [RFC4975], by allowing the usage of the "msrps"
scheme when the underlying connection is protected with DTLS.
NOTE to RFC Editor: Please replace "XXXX" with the number of this 8. Security Considerations
RFC.
This document adds the subprotocol identifier "MSRP" to the MSRP traffic over data channels is secured, including
"WebSocket Subprotocol Name Registry" as follows: confidentiality, integrity and source authentication, as specified by
[I-D.ietf-rtcweb-data-channel]
+--------------------------+---------+ Note that discussion in [RFC4975] on MSRP message attribution to
| Subprotocol Identifier: | MSRP | remote identities applies to data channel transport.
| Subprotocol Common Name: | MSRP |
| Subprotocol Definition: | RFCXXXX |
| Reference: | RFCXXXX |
+--------------------------+---------+
7.2. setup Attribute 9. IANA Considerations
9.1. msrps URI scheme
This document modifies the usage of the msrps URI scheme, registered
by [RFC4975], adding DTLS as a protected transport indicated by the
URI scheme.
9.2. Subprotocol Identifier MSRP
This document adds a reference to the subprotocol identifier "msrp"
in the "WebSocket Subprotocol Name Registry"
9.3. setup Attribute
NOTE to RFC Editor: Please replace "XXXX" with the number of this NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC. RFC.
This document modifies the usage of the SDP setup attribute, if this This document modifies the usage of the SDP setup attribute, if this
attribute is embedded in a dcsa attribute and associated with an MSRP attribute is embedded in a dcsa attribute and associated with an MSRP
session over a data channel. The modified usage is described in session over a data channel. The modified usage is described in
Section 4.5. Section 4.5.
Usage level "dcsa(MSRP)" should be added to the IANA registration of Usage level "dcsa(MSRP)" should be added to the IANA registration of
the SDP setup attribute as follows: the SDP setup attribute as follows:
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs | | Contact name: | IESG |
| Contact email: | mmusic-chairs@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | setup | | Attribute name: | setup |
| Usage level: | dcsa(MSRP) | | Usage level: | dcsa(MSRP) |
| Purpose: | Negotiate the active role of an MSRP | | Purpose: | Negotiate the active role of an MSRP |
| | session over a data channel as per | | | session over a data channel as per |
| | Section 4.5 | | | Section 4.5 |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
8. Security Considerations 10. Acknowledgments
MSRP traffic over data channels is secured, including
confidentiality, integrity and source authentication, as specified by
[I-D.ietf-rtcweb-data-channel]
Note that discussion in [RFC4975] on MSRP message attribution to
remote identities applies to data channel transport.
9. Acknowledgments
The authors wish to acknowledge the borrowing of ideas from another The authors wish to acknowledge the borrowing of ideas from another
internet draft by Peter Dunkley and Gavin Llewellyn, and to thank internet draft by Peter Dunkley and Gavin Llewellyn, and to thank
Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox,
Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their
invaluable comments. invaluable comments.
Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed
an earlier version, before the draft was re-adopted. an earlier version, before the draft was re-adopted.
Julien Maisonneuve helped with the re-adoption of the draft, and
Maridi R. Makaraju (Raju) contributed valuable comments after the Maridi R. Makaraju (Raju) contributed valuable comments after the
draft was re-adopted. draft was re-adopted.
10. CHANGE LOG 11. CHANGE LOG
10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-15' 11.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-16'
o WGLC review: draft updates RFC4975; clarify introduction; rewrite
wording on path and transport negotiation; session closing
clarifications; references cleanup.
o Editorial: consistent SHALL usage; reorder updates, security and
IANA sections for consistency; typos; acknowledgements.
11.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-15'
o More concise and clear introduction and section descriptions. o More concise and clear introduction and section descriptions.
o Updates on author list, contributions and acknowledgements. o Updates on author list, contributions and acknowledgements.
10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-14' 11.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-14'
o Reorganization following t140-usage-data-channel structure. o Reorganization following t140-usage-data-channel structure.
10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13' 11.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13'
o Clarify gateway procedures in accordance to mandatory use of CEMA. o Clarify gateway procedures in accordance to mandatory use of CEMA.
10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12' 11.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12'
o Make CEMA mandatory, clarify SDP procedures. o Make CEMA mandatory, clarify SDP procedures.
10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11' 11.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11'
o Additional clarifications on cema and path attribute after mail o Additional clarifications on cema and path attribute after mail
list feedback. list feedback.
10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10' 11.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10'
o Corrections and clarifications on cema and path attributes after o Corrections and clarifications on cema and path attributes after
mail list feedback. mail list feedback.
10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09' 11.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09'
o Corrected area to ART. o Corrected area to ART.
10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08' 11.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08'
o Updated reference to 4566bis. o Updated reference to 4566bis.
o Expanded motivation paragraphs in introduction. o Expanded motivation paragraphs in introduction.
10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07' 11.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07'
o Move security considerations after IANA considerations, following o Move security considerations after IANA considerations, following
RFC7322 suggested order. RFC7322 suggested order.
o Update references to use xml.resource.org citation database. o Update references to use xml.resource.org citation database.
o Reformat of the section discussing setup parameter o Reformat of the section discussing setup parameter
o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg] o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg]
draft. draft.
o Edit section 6 for clarity. o Edit section 6 for clarity.
o Security requirements. o Security requirements.
o Clarify comment on unrecognized transports and session opening. o Clarify comment on unrecognized transports and session opening.
o Update year, add editor. o Update year, add editor.
10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06' 11.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06'
o Modification of Keith's address information. o Modification of Keith's address information.
10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05' 11.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05'
o Modification of Juergen's address information. o Modification of Juergen's address information.
10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04' 11.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04'
o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative o Addition of "I-D.ietf-mmusic-rfc4566bis"/> to list of normative
references. references.
o Addition of Section 7.2 as per section 8.2.4 of o Addition of Section 9.3 as per section 8.2.4 of "I-D.ietf-mmusic-
[I-D.ietf-mmusic-rfc4566bis]. rfc4566bis"/>.
10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03' 11.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03'
o Addition of IANA registration related Section 7.1. o Addition of IANA registration related Section 9.2.
10.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02' 11.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02'
o Addition of "a=setup:actpass", "a=connection:new", o Addition of "a=setup:actpass", "a=connection:new",
"a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to "a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to
the SDP example in Section 4.8. the SDP example in Section 4.8.
o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of o Addition of "RFC4145" and [I-D.ietf-mmusic-sctp-sdp] to list of
normative references. normative references.
o Addition of new Section 4.5 describing how the active MSRP session o Addition of new Section 4.5 describing how the active MSRP session
endpoint role is negotiated. endpoint role is negotiated.
o Extension of first paragraph of session-opening with new first o Extension of first paragraph of session-opening with new first
sentence "Section 4.5 describes how the active MSRP session sentence "Section 4.5 describes how the active MSRP session
endpoint role is negotiated.". endpoint role is negotiated.".
o First sentence of second paragraph in session-opening was "As soon o First sentence of second paragraph in session-opening was "As soon
skipping to change at page 14, line 24 skipping to change at page 15, line 5
opened by the active MSRP endpoint which sends an MSRP SEND opened by the active MSRP endpoint which sends an MSRP SEND
message (empty or not) to the other MSRP endpoint." Replacement message (empty or not) to the other MSRP endpoint." Replacement
of this sentence with "As soon as this data channel is opened, the of this sentence with "As soon as this data channel is opened, the
MSRP session is actually opened by the active MSRP endpoint. In MSRP session is actually opened by the active MSRP endpoint. In
order to do this the active MSRP endpoint sends an MSRP SEND order to do this the active MSRP endpoint sends an MSRP SEND
message (empty or not) to the other MSRP endpoint." message (empty or not) to the other MSRP endpoint."
o Addition of setup attribute specific behavior descriptions of data o Addition of setup attribute specific behavior descriptions of data
channel to TCP or TLS interworking gateways in Section 6. channel to TCP or TLS interworking gateways in Section 6.
10.15. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01' 11.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01'
o In the abstract replacement of the first sentence "This document o In the abstract replacement of the first sentence "This document
specifies how the Message Session Relay Protocol (MSRP) can be specifies how the Message Session Relay Protocol (MSRP) can be
instantiated as a data channel sub-protocol, using the SDP offer/ instantiated as a data channel sub-protocol, using the SDP offer/
answer exchange-based external negotiation defined in answer exchange-based external negotiation defined in
[I-D.ietf-mmusic-data-channel-sdpneg]" with "This document [I-D.ietf-mmusic-data-channel-sdpneg]" with "This document
specifies how the Message Session Relay Protocol (MSRP) can be specifies how the Message Session Relay Protocol (MSRP) can be
instantiated as a data channel sub-protocol, using the SDP offer/ instantiated as a data channel sub-protocol, using the SDP offer/
answer exchange-based generic data channel negotiation framework" answer exchange-based generic data channel negotiation framework"
in order to remove the reference from the abstract text. in order to remove the reference from the abstract text.
skipping to change at page 15, line 43 skipping to change at page 16, line 23
procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with
'The closure of an MSRP session MUST be signaled via an SDP offer/ 'The closure of an MSRP session MUST be signaled via an SDP offer/
answer exchange which removes the "a=dcmap:" and "a=dcsa:" answer exchange which removes the "a=dcmap:" and "a=dcsa:"
attribute lines associated with the MSRP session from the attribute lines associated with the MSRP session from the
associated DTLS/SCTP based media description. This results in the associated DTLS/SCTP based media description. This results in the
associated data channel being closed as well as per associated data channel being closed as well as per
[I-D.ietf-mmusic-data-channel-sdpneg], where the actual data [I-D.ietf-mmusic-data-channel-sdpneg], where the actual data
channel closure procedure is typically initiated by the SDP channel closure procedure is typically initiated by the SDP
answerer right after having accepted the SDP offer.'. answerer right after having accepted the SDP offer.'.
10.16. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00' 11.17. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00'
o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in
list of normative references. list of normative references.
o Replacement of previous document title "MSRP over SCTP/DTLS data o Replacement of previous document title "MSRP over SCTP/DTLS data
channels" with "MSRP over Data Channels" in order to align with channels" with "MSRP over Data Channels" in order to align with
the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg]. the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg].
o In "terminology", "WebRTC data channel" was defined as "A o In "terminology", "WebRTC data channel" was defined as "A
bidirectional channel consisting of paired SCTP outbound and bidirectional channel consisting of paired SCTP outbound and
inbound streams." Replacement of this definition with "Data inbound streams." Replacement of this definition with "Data
channel: A WebRTC data channel as specified in channel: A WebRTC data channel as specified in
[I-D.ietf-rtcweb-data-channel]", and consistent usage of either [I-D.ietf-rtcweb-data-channel]", and consistent usage of either
"data channel" or "MSRP data channel" in the remainder of the "data channel" or "MSRP data channel" in the remainder of the
document." document."
o In the introduction replacement of references to o In the introduction replacement of references to
[I-D.ietf-rtcweb-data-protocol] with a reference to [I-D.ietf-rtcweb-data-protocol] with a reference to
[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-rtcweb-data-channel].
o Consistent usage of '"m" line' in whole document as per [RFC4566]. o Consistent usage of '"m=" line' in whole document as per
[RFC4566].
o In the gateway configuration section (Section 6) replacement of o In the gateway configuration section (Section 6) replacement of
the first sentence "This section describes the network the first sentence "This section describes the network
configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS
connection, the other MSRP endpoint runs MSRP over one or more connection, the other MSRP endpoint runs MSRP over one or more
TLS/TCP connections, and the two endpoints interwork via an MSRP TLS/TCP connections, and the two endpoints interwork via an MSRP
gateway" with "This section describes the network configuration gateway" with "This section describes the network configuration
where one MSRP endpoint uses data channels as MSRP transport, the where one MSRP endpoint uses data channels as MSRP transport, the
other MSRP endpoint uses TLS/TCP connections as MSRP transport, other MSRP endpoint uses TLS/TCP connections as MSRP transport,
and the two MSRP endpoints interwork via an MSRP gateway". and the two MSRP endpoints interwork via an MSRP gateway".
10.17. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01' 11.18. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01'
o Removed empty spaces after ";" in the examples' "a=dcmap" o Removed empty spaces after ";" in the examples' "a=dcmap"
attribute lines. attribute lines.
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
with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines
replaced with "a=max-message-size" attribute lines, as per draft- were replaced with "a=max-message-size" attribute lines, as per
ietf-mmusic-sctp-sdp-12. draft-ietf-mmusic-sctp-sdp-12.
10.18. Changes against '-00' 11.19. Changes against '-00'
o Transport parameter change for MSRP to allow MSRP RFC transports. o Transport parameter change for MSRP to allow MSRP RFC transports.
o Clarification on SDP offer/answer and removing duplicated o Clarification on SDP offer/answer and removing duplicated
procedures and refer them to draft-ejzak-mmusic-data-channel- procedures and refer them to draft-ejzak-mmusic-data-channel-
sdpneg-02. sdpneg-02.
11. Normative References 12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[I-D.ietf-rtcweb-data-protocol] [I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data- Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015. protocol-09 (work in progress), January 2015.
skipping to change at page 17, line 29 skipping to change at page 18, line 13
2019. 2019.
[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.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
DOI 10.17487/RFC4145, September 2005,
<https://www.rfc-editor.org/info/rfc4145>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[I-D.ietf-mmusic-rfc4566bis]
Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", draft-ietf-mmusic-
rfc4566bis-37 (work in progress), August 2019.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"The Message Session Relay Protocol (MSRP)", RFC 4975, "The Message Session Relay Protocol (MSRP)", RFC 4975,
DOI 10.17487/RFC4975, September 2007, DOI 10.17487/RFC4975, September 2007,
<https://www.rfc-editor.org/info/rfc4975>. <https://www.rfc-editor.org/info/rfc4975>.
[RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S.,
and P. Kyzivat, "A Session Description Protocol (SDP) and P. Kyzivat, "A Session Description Protocol (SDP)
Offer/Answer Mechanism to Enable File Transfer", RFC 5547, Offer/Answer Mechanism to Enable File Transfer", RFC 5547,
DOI 10.17487/RFC5547, May 2009, DOI 10.17487/RFC5547, May 2009,
<https://www.rfc-editor.org/info/rfc5547>. <https://www.rfc-editor.org/info/rfc5547>.
 End of changes. 82 change blocks. 
153 lines changed or deleted 169 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/