MMUSIC K. Drage, Ed.
Internet-Draft M. Makaraju
Intended status: Standards Track J. Stoetzer-Bradler
Expires: June 11, 2020 R. Ejzak
Unaffiliated
J. Recio, Ed.
December 9, 2019
MSRP over Data Channels
draft-ietf-mmusic-msrp-usage-data-channel-14
Abstract
This document specifies how the Message Session Relay Protocol (MSRP)
can be instantiated as a data channel sub-protocol, using the SDP
offer/answer exchange-based generic data channel negotiation
framework. Two network configurations are documented: a WebRTC end-
to-end configuration (connecting two MSRP over data channel
endpoints), and a gateway configuration (connecting an MSRP over data
channel endpoint with an MSRP over TCP or TLS endpoint).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 11, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Drage, et al. Expires June 11, 2020 [Page 1]
Internet-Draft MSRP over Data Channels December 2019
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 5
4.2. Session Mapping . . . . . . . . . . . . . . . . . . . . . 5
4.3. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 5
5. End-to-End Configuration . . . . . . . . . . . . . . . . . . 5
5.1. Basic MSRP Support . . . . . . . . . . . . . . . . . . . 6
5.1.1. SDP Considerations . . . . . . . . . . . . . . . . . 6
5.1.1.1. Use of the dcmap Attribute . . . . . . . . . . . 6
5.1.1.2. Use of the dcsa Attribute . . . . . . . . . . . . 6
5.1.1.3. Use of the dcsa embedded setup Attribute . . . . 7
5.1.1.4. Example SDP Negotiation . . . . . . . . . . . . . 7
5.1.2. Session Opening . . . . . . . . . . . . . . . . . . . 8
5.1.3. Data Framing . . . . . . . . . . . . . . . . . . . . 8
5.1.4. Data Sending and Reporting . . . . . . . . . . . . . 9
5.1.5. Session Closing . . . . . . . . . . . . . . . . . . . 9
5.2. Support for MSRP File Transfer Function . . . . . . . . . 9
6. Gateway Configuration . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 10
7.2. setup Attribute . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-13' . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-12' . . . . . . . . . . . . . . . . . . . . . . 12
10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-11' . . . . . . . . . . . . . . . . . . . . . . 12
10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-10' . . . . . . . . . . . . . . . . . . . . . . 12
10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-09' . . . . . . . . . . . . . . . . . . . . . . 12
10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-08' . . . . . . . . . . . . . . . . . . . . . . 12
10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-
Drage, et al. Expires June 11, 2020 [Page 2]
Internet-Draft MSRP over Data Channels December 2019
channel-07' . . . . . . . . . . . . . . . . . . . . . . 12
10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-06' . . . . . . . . . . . . . . . . . . . . . . 13
10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-05' . . . . . . . . . . . . . . . . . . . . . . 13
10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-04' . . . . . . . . . . . . . . . . . . . . . . 13
10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-03' . . . . . . . . . . . . . . . . . . . . . . 13
10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-02' . . . . . . . . . . . . . . . . . . . . . . 13
10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-01' . . . . . . . . . . . . . . . . . . . . . . 14
10.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-
channel-00' . . . . . . . . . . . . . . . . . . . . . . 15
10.15. Changes against 'draft-ejzak-mmusic-msrp-usage-data-
channel-01' . . . . . . . . . . . . . . . . . . . . . . 16
10.16. Changes against '-00' . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for
transmitting a series of related instant messages in the context of a
session. In addition to instant messaging, MSRP can also be used for
image sharing or file transfer. MSRP is currently defined to work
over TCP and TLS connections, and over a WebSocket subprotocol
specified by [RFC7977].
This document defines the negotiation and transport of this MSRP
protocol over data channels, where a data channel is a bi-directional
communication channel running on top of SCTP/DTLS (as per
[I-D.ietf-rtcweb-data-channel]) and where MSRP is instantiated as a
sub-protocol of this data channel. The MSRP protocol negotiation
defined in this document is based on the generic SDP offer/answer
exchange based data channel negotiation as specified in
[I-D.ietf-mmusic-data-channel-sdpneg].
Defining MSRP as a data channel sub-protocol has many benefits:
o provides to applications a proven protocol enabling instant
messaging, file transfer, image sharing
o integrates those features with other RTCWeb voice, video and data
features
o leverages the SDP-based negotiation already defined for MSRP
Drage, et al. Expires June 11, 2020 [Page 3]
Internet-Draft MSRP over Data Channels December 2019
o allows the interworking with MSRP endpoints running on a TCP or
TLS connection
Compared to WebSockets, that provide a message passing protocol to
applications with no direct access to TCP or TLS sockets, data
channels provide a low latency transport, leverage NAT-aware
connectivity and security features of WebRTC, and are increasingly
available not only in modern browsers but in other applications that
use WebRTC for media or other purposes (IoT or telemetry in general,
non-media data exchange, etc).
Considering an MSRP endpoint being an MSRP application that uses data
channel from WebRTC specifications [I-D.ietf-rtcweb-data-channel],
this document describes two configurations where the other endpoint
is respectively either another MSRP over data channel endpoint (e.g.,
a WebRTC application) or an MSRP endpoint using either TCP or TLS
transport.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
This document uses the following terms:
Data channel: A WebRTC data channel as specified in
[I-D.ietf-rtcweb-data-channel].
MSRP data channel: A data channel specifically used to transport
the messages of one MSRP session.
External negotiation: Data channel negotiation based on out-of-
band or in-band mechanisms other than the Data Channel
Establishment Protocol specified in
[I-D.ietf-rtcweb-data-protocol].
In-band: Transmission through the peer-to-peer SCTP association.
Out-of-band: Transmission through the call control signaling path,
e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer
model [RFC3264].
Peer: From the perspective of one of the agents in a session, its
peer is the other agent. Specifically, from the perspective of
Drage, et al. Expires June 11, 2020 [Page 4]
Internet-Draft MSRP over Data Channels December 2019
the SDP offerer, the peer is the SDP answerer. From the
perspective of the SDP answerer, the peer is the SDP offerer.
4. Principles
4.1. MSRP Data Channel
In this document, an MSRP data channel is a data channel for which
the instantiated sub-protocol is "MSRP", and where the MSRP-related
negotiation is done as part of the SDP-based external negotiation
method defined in [I-D.ietf-mmusic-data-channel-sdpneg].
4.2. Session Mapping
In this design, the MSRP session maps to the SCTP association and the
"SCTP stream pair" assigned to the data channel, and each MSRP
session maps to one data channel exactly.
4.3. MSRP URI
This document extends the MSRP URI syntax [RFC4975] by defining the
new transport parameter value "dc":
transport /= "dc" / 1*ALPHANUM
; Add "dc" to existing transports per [RFC4975]
MSRP design provides for new transport bindings, see Section 6 of
[RFC4975], MSRP implementations are expected to allow unrecognized
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
(Section 5.1.2).
4.4. msrp-scheme
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
message headers) is always "msrps", which indicates that the MSRP
data channel is always secured using DTLS as described in
[I-D.ietf-rtcweb-data-channel].
5. End-to-End Configuration
This section describes the network configuration where each MSRP
endpoint is running MSRP over a data channel.
Drage, et al. Expires June 11, 2020 [Page 5]
Internet-Draft MSRP over Data Channels December 2019
5.1. Basic MSRP Support
5.1.1. SDP Considerations
The generic SDP considerations, including the SDP Offer/Answer
procedures, for negotiating a WebRTC data channel are defined in
[I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP
considerations that are specific to an MSRP data channel.
5.1.1.1. Use of the dcmap Attribute
An offerer and answerer MUST, in each offer and answer, include a
dcmap attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within
the media description of the SCTP association for each MSRP data
channel session to be negotiated.
The attribute includes the following data channel parameters:
o "label=" labelstring
o "subprotocol=" "MSRP"
The labelstring is set by the MSRP application according to
[I-D.ietf-mmusic-data-channel-sdpneg].
The offerer and answerer MUST NOT include the max-retr and the max-
time attribute parameters in the dcmap attribute.
The offerer and answerer MAY include the ordered attribute parameter
in the dcmap attribute. If included, the attribute parameter value
MUST be set to "true".
Below is an example of the dcmap attribute for an MSRP session to be
negotiated with stream-id=2 and label="chat":
a=dcmap:2 label="chat";subprotocol="MSRP"
5.1.1.2. Use of the dcsa Attribute
An offerer and answerer MUST, in each offer and answer, include a
dcsa attribute line ([I-D.ietf-mmusic-data-channel-sdpneg]) within
the media description for the SCTP association for each MSRP-specific
SDP attribute to be negotiated for each MSRP data channel being
negotiated.
An offerer and answerer MUST include a dcsa attribute for the
following MSRP-specific SDP attributes:
Drage, et al. Expires June 11, 2020 [Page 6]
Internet-Draft MSRP over Data Channels December 2019
o defined in [RFC4975]: "path".
o defined in [RFC6714]: "msrp-cema".
o defined in [RFC6135]: "setup". See Section 5.1.1.3
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.
An offerer and answerer MAY include a dcsa attribute for the
following MSRP-specific SDP attributes, following the procedures
defined for each attributes:
o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and
"max-size"
o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and
"sendrecv"
o defined in [RFC5547]: all the parameters related to MSRP file
transfer. See Section 5.2.
A subsequent offer or answer MAY update the previously negotiated
MSRP subprotocol attributes while keeping the same subprotocol
a=dcmap description. The semantics for newly negotiated MSRP
subprotocol attributes are per [RFC4975].
5.1.1.3. Use of the dcsa embedded setup Attribute
As described in Section 5.1.1.2, the usage of a dsca embedded setup
attribute is mandated for MSRP sessions over data channels. It is
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
has no relationship with the DTLS connection establishment roles
[I-D.ietf-mmusic-sctp-sdp].
The dcsa embedded setup attribute is of the form "a=dcsa:x
setup:<role>", with x being the data channel's SCTP stream
identifier, so that such attribute is explicitly associated with an
MSRP session over a specific data channel.
5.1.1.4. Example SDP Negotiation
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
sessions: one for chat and one for file transfer. The example is
derived from a combination of examples in [RFC4975] and [RFC5547].
Drage, et al. Expires June 11, 2020 [Page 7]
Internet-Draft MSRP over Data Channels December 2019
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 198.51.100.79
a=max-message-size:100000
a=sctp-port:5000
a=setup:actpass
a=fingerprint:SHA-1 \
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=dcmap:0 label="chat";subprotocol="MSRP"
a=dcsa:0 msrp-cema
a=dcsa:0 setup:active
a=dcsa:0 accept-types:message/cpim text/plain
a=dcsa:0 path:msrps://bob.example.com:54111/si438dsaodes;dc
a=dcmap:2 label="file transfer";subprotocol="MSRP"
a=dcsa:2 sendonly
a=dcsa:2 msrp-cema
a=dcsa:2 setup:active
a=dcsa:2 accept-types:message/cpim
a=dcsa:2 accept-wrapped-types:*
a=dcsa:2 path:msrps://bob.example.com:54111/jshA7we;dc
a=dcsa:2 file-selector:name:"picture1.jpg" \
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
a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep
a=dcsa:2 file-disposition:attachment
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-range:1-1463440
5.1.2. Session Opening
Section 5.1.1.3 describes how the active MSRP session endpoint role
is negotiated. The active MSRP session endpoint uses the data
channel established for this MSRP session by the generic data channel
opening procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg].
The path attribute SHALL NOT be used for transport negotiation.
As soon as this data channel is opened, the MSRP session is actually
opened by the active MSRP session endpoint. In order to do this the
active MSRP endpoint sends an MSRP SEND message (empty or not) to the
other MSRP endpoint.
5.1.3. Data Framing
Each text-based MSRP message is sent on the corresponding SCTP stream
using standard MSRP framing and chunking procedures, as defined in
[RFC4975], with each MSRP chunk delivered in a single SCTP user
message. Therefore all sent MSRP chunks including the MSRP chunk
Drage, et al. Expires June 11, 2020 [Page 8]
Internet-Draft MSRP over Data Channels December 2019
header MUST have lengths of less than or equal to the value of the
peer's "a=max-message-size" attribute, which is associated with the
data channel's SCTP association.
5.1.4. Data Sending and Reporting
Data sending and reporting procedures SHALL conform to RFC 4975.
5.1.5. Session Closing
The closure of an MSRP session MUST be signaled via an SDP offer/
answer exchange which removes the "a=dcmap:" and "a=dcsa:" attribute
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)
when closing an MSRP session (unless all data channels are being
closed and the SCTP association is no longer needed), since this
would close the SCTP association and impact all of the data channels.
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,
the SDP offerer of an MSRP session with data channel transport SHALL
remove the corresponding dcmap and dcsa attributes.
The SDP answerer must ensure that no dcmap or dcsa attributes are
present in the SDP answer if no corresponding attributes are present
in the received SDP offer.
5.2. Support for MSRP File Transfer Function
[RFC5547] defines an end-to-end file transfer method based on MSRP
and the SDP offer/answer mechanism. This file transfer method is
also usable by MSRP endpoints using data channels, with the following
considerations:
o As an MSRP session maps to one data channel, a file transfer
session maps also to one data channel.
o SDP attributes specified in [RFC5547] for a file transfer "m" line
are embedded as subprotocol-specific attributes using the syntax
defined in [I-D.ietf-mmusic-data-channel-sdpneg].
o Once the file transfer is complete, the same data channel MAY be
reused for another file transfer.
Drage, et al. Expires June 11, 2020 [Page 9]
Internet-Draft MSRP over Data Channels December 2019
6. Gateway Configuration
This section describes the network configuration where one MSRP
endpoint uses data channels as MSRP transport, the other MSRP
endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP
endpoints interwork via an MSRP gateway.
Specifically, a gateway can be configured to interwork an MSRP
session over a data channel with a peer that does not support data
channel transport in one of two ways.
In one model, the gateway performs as a MSRP B2BUA to interwork all
the procedures as necessary between the endpoints. No further
specification is needed for this model.
Alternately, the gateway can provide transport level interworking
between MSRP endpoints using different transport protocols. In
accordance with Section 5.1.2, path attributes SHALL NOT be used for
transport level interworking.
When the gateway performs transport level interworking between MSRP
endpoints, all of the procedures in Section 5 apply to each peer,
with the following additions:
o The gateway MUST use CEMA towards the non-data channel endpoint.
o If the non-data channel endpoint does not support CEMA, transport
level interworking mode is not possible, the gateway needs to act
as an MSRP B2BUA.
o The gateway MUST NOT modify the path attribute received from data
channel or from non-data channel endpoints.
o The gateway MUST NOT modify the setup value received from data
channel or from non-data channel endpoints.
o The endpoint establishing an MSRP session using data channel
transport SHALL NOT request inclusion of any relays, although it
MAY interoperate with a peer that signals the use of relays.
7. IANA Considerations
7.1. Subprotocol Identifier MSRP
NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC.
Drage, et al. Expires June 11, 2020 [Page 10]
Internet-Draft MSRP over Data Channels December 2019
This document adds the subprotocol identifier "MSRP" to the
"WebSocket Subprotocol Name Registry" as follows:
+--------------------------+---------+
| Subprotocol Identifier: | MSRP |
| Subprotocol Common Name: | MSRP |
| Subprotocol Definition: | RFCXXXX |
| Reference: | RFCXXXX |
+--------------------------+---------+
7.2. setup Attribute
NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC.
This document modifies the usage of the SDP setup attribute, if this
attribute is embedded in a dcsa attribute and associated with an MSRP
session over a data channel. The modified usage is described in
Section 5.1.1.3.
Usage level "dcsa(MSRP)" should be added to the IANA registration of
the SDP setup attribute as follows:
+-----------------------+-------------------------------------------+
| Contact name: | MMUSIC Chairs |
| Contact email: | mmusic-chairs@ietf.org |
| Attribute name: | setup |
| Usage level: | dcsa(MSRP) |
| Purpose: | Negotiate the active role of an MSRP |
| | session over a data channel as per |
| | Section 5.1.1.3 |
| Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+
8. Security Considerations
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
internet draft by Peter Dunkley and Gavin Llewellyn, and to thank
Flemming Andreasen, Christian Groves, Christer Holmberg, Paul
Drage, et al. Expires June 11, 2020 [Page 11]
Internet-Draft MSRP over Data Channels December 2019
Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz and
Keith Drage for their invaluable comments.
10. CHANGE LOG
10.1. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-13'
o Clarify gateway procedures in accordance to mandatory use of CEMA.
10.2. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-12'
o Make CEMA mandatory, clarify SDP procedures.
10.3. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-11'
o Additional clarifications on cema and path attribute after mail
list feedback.
10.4. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-10'
o Corrections and clarifications on cema and path attributes after
mail list feedback.
10.5. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-09'
o Corrected area to ART.
10.6. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-08'
o Updated reference to 4566bis.
o Expanded motivation paragraphs in introduction.
10.7. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-07'
o Move security considerations after IANA considerations, following
RFC7322 suggested order.
o Update references to use xml.resource.org citation database.
o Reformat of the section discussing setup parameter
o Align examples with latest [I-D.ietf-mmusic-data-channel-sdpneg]
draft.
o Edit section 6 for clarity.
o Security requirements.
Drage, et al. Expires June 11, 2020 [Page 12]
Internet-Draft MSRP over Data Channels December 2019
o Clarify comment on unrecognized transports and session opening.
o Update year, add editor.
10.8. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-06'
o Modification of Keith's address information.
10.9. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-05'
o Modification of Juergen's address information.
10.10. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-04'
o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative
references.
o Addition of Section 7.2 as per section 8.2.4 of
[I-D.ietf-mmusic-rfc4566bis].
10.11. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-03'
o Addition of IANA registration related Section 7.1.
10.12. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-02'
o Addition of "a=setup:actpass", "a=connection:new",
"a=fingerprint:..." and "a=dcsa:x setup=active" SDP attributes to
the SDP example in Section 5.1.1.4.
o Addition of [RFC4145] and [I-D.ietf-mmusic-sctp-sdp] to list of
normative references.
o Addition of new Section 5.1.1.3 describing how the active MSRP
session endpoint role is negotiated.
o Extension of first paragraph of Section 5.1.2 with new first
sentence "Section 5.1.1.3 describes how the active MSRP session
endpoint role is negotiated.".
o First sentence of second paragraph in Section 5.1.2 was "As soon
as this data channel is opened, the MSRP session is actually
opened by the active MSRP endpoint which sends an MSRP SEND
message (empty or not) to the other MSRP endpoint." Replacement
of this sentence with "As soon as this data channel is opened, the
MSRP session is actually opened by the active MSRP endpoint. In
order to do this the active MSRP endpoint sends an MSRP SEND
message (empty or not) to the other MSRP endpoint."
Drage, et al. Expires June 11, 2020 [Page 13]
Internet-Draft MSRP over Data Channels December 2019
o Addition of setup attribute specific behavior descriptions of data
channel to TCP or TLS interworking gateways in Section 6.
10.13. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-01'
o In the abstract replacement of the first sentence "This document
specifies how the Message Session Relay Protocol (MSRP) can be
instantiated as a data channel sub-protocol, using the SDP offer/
answer exchange-based external negotiation defined in
[I-D.ietf-mmusic-data-channel-sdpneg]" with "This document
specifies how the Message Session Relay Protocol (MSRP) can be
instantiated as a data channel sub-protocol, using the SDP offer/
answer exchange-based generic data channel negotiation framework"
in order to remove the reference from the abstract text.
o Addition of following sentence to the second paragraph in
Section 1: "The MSRP protocol negotiation defined in this document
is based on the generic SDP offer/answer exchange based data
channel negotiation as specified in
[I-D.ietf-mmusic-data-channel-sdpneg]".
o In Section 4.1 replacement of sub-protocol identifier "msrp" with
"MSRP" in order to make this consistent with the formal
specification in Section 5.1.1.1.
o Throughout the text replacement of "shall" with "SHALL" etc where
appropriate as per [RFC2119].
o In Section 5.1.1.1 replacement of sentence 'The max-retr, max-time
and ordered parameters shall not be used.' with 'Ordered and
reliable data channels MUST always be used, such that the "max-
retr" and "max-time" parameters SHALL NOT be used. If the
"ordered" parameter is used, then its value MUST be equal to
"true".'.
o In Section 5.1.1.1 removal of "(on default SCTP port 5000)" from
the sentence preceding the example "a=dcmap" attribute line.
o In Section 5.1.1.2 first paragraph was "The SDP offer shall also
include a dcsa attribute line (defined in
[I-D.ietf-mmusic-data-channel-sdpneg]) within the media
description for the SCTP association for each MSRP-specific SDP
attribute to be negotiated for each MSRP data channel being
negotiated.". Replacement of this paragraph with "The SDP offer
SHALL also include within the media description for the SCTP
association a dcsa attribute line (defined in
[I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP
Drage, et al. Expires June 11, 2020 [Page 14]
Internet-Draft MSRP over Data Channels December 2019
attribute to be negotiated for each MSRP data channel being
negotiated.".
o Appended following sentence at the end of the first paragraph of
Section 5.1.3: "Therefore all sent MSRP chunks MUST have lengths
of less than or equal to the value of the peer's "a=max-message-
size" attribute, which is associated with the data channel's SCTP
association.".
o Addition of the previously missing colon to the "a=sctp-port"
attribute line in Section 5.1.1.4.
o In Section 5.1.5 replacement of the first paragraph "Closing of an
MSRP session is done using the generic data channel closing
procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]." with
'The closure of an MSRP session MUST be signaled via an SDP offer/
answer exchange which removes the "a=dcmap:" and "a=dcsa:"
attribute 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.'.
10.14. Changes against 'draft-ietf-mmusic-msrp-usage-data-channel-00'
o Additional reference to [I-D.ietf-mmusic-data-channel-sdpneg] in
list of normative references.
o Replacement of previous document title "MSRP over SCTP/DTLS data
channels" with "MSRP over Data Channels" in order to align with
the terminology used in [I-D.ietf-mmusic-data-channel-sdpneg].
o In Section 3 "WebRTC data channel" was defined as "A bidirectional
channel consisting of paired SCTP outbound and inbound streams."
Replacement of this definition with "Data channel: A WebRTC data
channel as specified in [I-D.ietf-rtcweb-data-channel]", and
consistent usage of either "data channel" or "MSRP data channel"
in the remainder of the document."
o In the introduction replacement of references to
[I-D.ietf-rtcweb-data-protocol] with a reference to
[I-D.ietf-rtcweb-data-channel].
o Consistent usage of '"m" line' in whole document as per [RFC4566].
o In the gateway configuration section (Section 6) replacement of
the first sentence "This section describes the network
Drage, et al. Expires June 11, 2020 [Page 15]
Internet-Draft MSRP over Data Channels December 2019
configuration where one endpoint runs MSRP over a WebRTC SCTP/DTLS
connection, the other MSRP endpoint runs MSRP over one or more
TLS/TCP connections, and the two endpoints interwork via an MSRP
gateway" with "This section describes the network configuration
where one MSRP endpoint uses data channels as MSRP transport, the
other MSRP endpoint uses TLS/TCP connections as MSRP transport,
and the two MSRP endpoints interwork via an MSRP gateway".
10.15. Changes against 'draft-ejzak-mmusic-msrp-usage-data-channel-01'
o Removed empty spaces after ";" in the examples' "a=dcmap"
attribute lines.
o In all examples, the "m" line proto value "DTLS/SCTP" was replaced
with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were
replaced with "a=max-message-size" attribute lines, as per draft-
ietf-mmusic-sctp-sdp-12.
10.16. Changes against '-00'
o Transport parameter change for MSRP to allow MSRP RFC transports.
o Clarification on SDP offer/answer and removing duplicated
procedures and refer them to draft-ejzak-mmusic-data-channel-
sdpneg-02.
11. 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>.
[I-D.ietf-rtcweb-jsep]
Uberti, J., Jennings, C., and E. Rescorla, "JavaScript
Session Establishment Protocol", draft-ietf-rtcweb-jsep-26
(work in progress), February 2019.
[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>.
[I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015.
Drage, et al. Expires June 11, 2020 [Page 16]
Internet-Draft MSRP over Data Channels December 2019
[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-data-channel-sdpneg]
Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
Even, "SDP-based Data Channel Negotiation", draft-ietf-
mmusic-data-channel-sdpneg-28 (work in progress), May
2019.
[I-D.ietf-mmusic-sctp-sdp]
Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
"Session Description Protocol (SDP) Offer/Answer
Procedures For Stream Control Transmission Protocol (SCTP)
over Datagram Transport Layer Security (DTLS) Transport.",
draft-ietf-mmusic-sctp-sdp-26 (work in progress), April
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
Description Protocol", RFC 4566, DOI 10.17487/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.,
"The Message Session Relay Protocol (MSRP)", RFC 4975,
DOI 10.17487/RFC4975, September 2007,
<https://www.rfc-editor.org/info/rfc4975>.
[RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S.,
and P. Kyzivat, "A Session Description Protocol (SDP)
Offer/Answer Mechanism to Enable File Transfer", RFC 5547,
DOI 10.17487/RFC5547, May 2009,
<https://www.rfc-editor.org/info/rfc5547>.
[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model
for the Message Session Relay Protocol (MSRP)", RFC 6135,
DOI 10.17487/RFC6135, February 2011,
<https://www.rfc-editor.org/info/rfc6135>.
Drage, et al. Expires June 11, 2020 [Page 17]
Internet-Draft MSRP over Data Channels December 2019
[RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection
Establishment for Media Anchoring (CEMA) for the Message
Session Relay Protocol (MSRP)", RFC 6714,
DOI 10.17487/RFC6714, August 2012,
<https://www.rfc-editor.org/info/rfc6714>.
[RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G.,
and R. Ravindranath, "The WebSocket Protocol as a
Transport for the Message Session Relay Protocol (MSRP)",
RFC 7977, DOI 10.17487/RFC7977, September 2016,
<https://www.rfc-editor.org/info/rfc7977>.
Authors' Addresses
Keith Drage (editor)
Unaffiliated
Email: drageke@ntlworld.com
Maridi R. Makaraju (Raju)
Unaffiliated
Email: mmraju@gmail.com
Juergen Stoetzer-Bradler
Unaffiliated
Email: Juergen.S-B.ietf@email.de
Richard Ejzak
Unaffiliated
Email: richard.ejzak@gmail.com
Jose M. Recio (editor)
Email: jose@ch3m4.com
Drage, et al. Expires June 11, 2020 [Page 18]
