Subject: [MMUSIC] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 9 Jul 2013 19:32:28 +0000

Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how to use DataChannel transport for MSRP.  Our draft does not place restrictions on the number of MSRP sessions that can be established within an SCTP association and describes alternatives for using a gateway to interconnect to existing MSRP endpoints.  The SDP extensions described are applicable to other potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt

A new version of I-D, draft-marcon-msrp-over-webrtc-data-channels-00.txt
has been successfully submitted by Jerome Marcon and posted to the IETF repository.

Filename:	 draft-marcon-msrp-over-webrtc-data-channels
Revision:	 00
Title:		 MSRP over WebRTC data channels
Creation date:	 2013-07-09
Group:		 Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-channels-00.txt
Status:          http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
Htmlized:        http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00

Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocols to support direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  For the support of data communication, the RTCWeb working
   group has in particular defined the concept of bi-directional data
   channels over SCTP, where each data channel might be used to
   transport other protocols, called sub-protocols.  This document
   specifies how the Message Session Relay Protocol (MSRP) can be
   instantiated as a WebRTC data channel sub-protocol, using the SDP
   offer/exchange to negotiate out-of-band the sub-protocol specific
   parameters.  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 endpoint).

The IETF Secretariat

---

From: Gavin Llewellyn <[email-masked]>
Date: Wed, 10 Jul 2013 12:50:51 +0100

As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for
establishment of MSRP sessions between WebRTC endpoints.  The SDP
enhancements allowing re-use of the SCTP association is very much along the
lines of what we had in mind for the next version of our draft, but we have
not had time to complete it.  We will likely be implementing this as a
feature in our WebRTC library in the near future, as the DataChannel
implementations in browsers mature (support SCTP, reliable delivery, binary
data, etc).

Having said that, it would have been appreciated if the authors had
contacted Peter and/or myself to discuss the existing draft and its
limitations - we would have been happy to receive feedback and work
together to find the best solution going forward.

I cannot see the value in introducing DataChannel gateways as a means to
communicate with traditional TCP-based MSRP endpoints.  I believe this is
better catered for by the WebSocket-based solution, as described in
draft-pd-dispatch-msrp-websocket,
which already has client and server implementations, and is currently
in-use in a production environment.  Given the (intentional) similarities
between the WebSocket and DataChannel APIs, it is not difficult for the
client application to support both transports.  I would like to see a clear
justification for this aspect of the draft.

One minor correction: the opening paragraph of section 5.2.3 appears to
reference the wrong SDP syntax for sub-protocol-specific attributes; I
believe it should reference the syntax for the new "wdcsa" attribute.

Regards,
Gavin Llewellyn

--
Gavin Llewellyn
Principal Design Engineer
Crocodile RCS Ltd
GPG key: 0xF8F6FFF2

On 9 July 2013 20:32, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

> Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how to
> use DataChannel transport for MSRP.  Our draft does not place restrictions
> on the number of MSRP sessions that can be established within an SCTP
> association and describes alternatives for using a gateway to interconnect
> to existing MSRP endpoints.  The SDP extensions described are applicable to
> other potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc.
>
> Richard
>
> Subject: New Version Notification for
> draft-marcon-msrp-over-webrtc-data-channels-00.txt
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-channels-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels
> Htmlized:
> http://tools.ietf.org/html/draft-marcon-msrp-over-webrtc-data-channels-00
>
>
> Abstract:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 10 Jul 2013 14:22:36 +0000

Hi Gavin,
Thanks for your support of our approach and for your comments.  It's great that you are planning an implementation along these lines.

I am including mmusic on this distribution to not exclude anyone who may be interested, but please limit the distribution to dispatch only for subsequent emails in this thread.

Regarding why we chose to create a new draft: Our approach was sufficiently different from yours that we felt a separate draft was a better idea in the short term.  We can merge when it's appropriate to do so.  Even though we have no significant difference of opinion regarding the SDP extensions needed, we clearly have different views regarding the value of a DataChannel gateway.  It would be good to hear other opinions on this matter, as you are clearly heavily committed to your preference.

Our preference for support of a DataChannel gateway model is based on the numerous advantages of DataChannels.  Just a partial list: We have one transport mechanism for all cases; we don't have to offer two options or perform fallback/retry procedures on failure of one transport option; we can easily multiplex all media and sub-protocols together; we can leverage the integrated browser handling of multiple flows of different priority; we have to be able to interoperate with legacy tcp/tls endpoints anyway.

We look forward to continuing the debate.

BR, Richard

From: Gavin Llewellyn [mailto:[email-masked]]
Sent: Wednesday, July 10, 2013 6:51 AM
To: Ejzak, Richard P (Richard)
Cc: [email-masked]; [email-masked] WG
Subject: Re: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt

As a co-author of draft-pd-msrp-webrtc-00, I support this new draft for establishment of MSRP sessions between WebRTC endpoints.  The SDP enhancements allowing re-use of the SCTP association is very much along the lines of what we had in mind for the next version of our draft, but we have not had time to complete it.  We will likely be implementing this as a feature in our WebRTC library in the near future, as the DataChannel implementations in browsers mature (support SCTP, reliable delivery, binary data, etc).

Having said that, it would have been appreciated if the authors had contacted Peter and/or myself to discuss the existing draft and its limitations - we would have been happy to receive feedback and work together to find the best solution going forward.

I cannot see the value in introducing DataChannel gateways as a means to communicate with traditional TCP-based MSRP endpoints.  I believe this is better catered for by the WebSocket-based solution, as described in draft-pd-dispatch-msrp-websocket, which already has client and server implementations, and is currently in-use in a production environment.  Given the (intentional) similarities between the WebSocket and DataChannel APIs, it is not difficult for the client application to support both transports.  I would like to see a clear justification for this aspect of the draft.

One minor correction: the opening paragraph of section 5.2.3 appears to reference the wrong SDP syntax for sub-protocol-specific attributes; I believe it should reference the syntax for the new "wdcsa" attribute.

Regards,
Gavin Llewellyn

On 9 July 2013 20:32, Ejzak, Richard P (Richard) <[email-masked]<mailto:[email-masked]>> wrote:
Please note our proposed alternative to draft-pd-msrp-webrtc-00 for how to use DataChannel transport for MSRP.  Our draft does not place restrictions on the number of MSRP sessions that can be established within an SCTP association and describes alternatives for using a gateway to interconnect to existing MSRP endpoints.  The SDP extensions described are applicable to other potential DataChannel sub-protocols such as T.140, BFCP, T.38, etc.

Richard

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 08, 2013 6:31 PM
To: Ejzak, Richard P (Richard); MARCON, JEROME (JEROME)
Subject: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Peter Dunkley <[email-masked]>
Date: Wed, 10 Jul 2013 15:56:59 +0100

Hello,

My preference for the WebSocket solution for client/server interaction
stems simply from:
1) There are many MSRP use cases that are strictly client to/from server.
WebSockets are a far simpler mechanism for these use cases, is far simpler
to implement at both ends, and is arguably more efficient due to this
simplicity.
2) There are many MSRP use cases that do not involve real-time media, and
use of WebSockets enables these use cases to be satisfied with browsers (or
other environments) that do not support WebRTC at this time (and some of
these browsers/environments may never support WebRTC).  I am not happy
about requiring WebRTC support in a browser just for me to be able to use
MSRP there.

The requirements for peer-to-peer MSRP and client/server MSRP are quite
different.  Even when TCP/TLS is the transport these requirements are
covered by two separate RFCs (which were developed and published in
parallel).  RFC 4976 adds additional MSRP requests and procedures that are
simply not needed for peer-to-peer MSRP.

I have no objection in principle to existence of a "gateway" device as you
have described (although, for the reasons described above, I will continue
to use WebSockets in my production system when client/server interaction is
required), but to me it would make more sense to separate this function
into another document that updates RFC 4976.

When I started writing draft-pd-msrp-webrtc I envisaged this as simply an
update to RFC 4975 to enable a new transport between MSRP peers - and I
believe there is value in this simplicity.

Regards,

Peter

On 10 July 2013 15:22, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

>  Hi Gavin,****
>
> Thanks for your support of our approach and for your comments.  It’s great
> that you are planning an implementation along these lines.****
>
> ** **
>
> I am including mmusic on this distribution to not exclude anyone who may
> be interested, but please limit the distribution to dispatch only for
> subsequent emails in this thread.****
>
> ** **
>
> Regarding why we chose to create a new draft: Our approach was
> sufficiently different from yours that we felt a separate draft was a
> better idea in the short term.  We can merge when it’s appropriate to do
> so.  Even though we have no significant difference of opinion regarding the
> SDP extensions needed, we clearly have different views regarding the value
> of a DataChannel gateway.  It would be good to hear other opinions on this
> matter, as you are clearly heavily committed to your preference.****
>
> ** **
>
> Our preference for support of a DataChannel gateway model is based on the
> numerous advantages of DataChannels.  Just a partial list: We have one
> transport mechanism for all cases; we don’t have to offer two options or
> perform fallback/retry procedures on failure of one transport option; we
> can easily multiplex all media and sub-protocols together; we can leverage
> the integrated browser handling of multiple flows of different priority; we
> have to be able to interoperate with legacy tcp/tls endpoints anyway. ****
>
> ** **
>
> We look forward to continuing the debate.****
>
> ** **
>
> BR, Richard****
>
> ** **
>
> *From:* Gavin Llewellyn [mailto:[email-masked]]
> *Sent:* Wednesday, July 10, 2013 6:51 AM
>
> *To:* Ejzak, Richard P (Richard)
> *Cc:* [email-masked]; [email-masked] WG
> *Subject:* Re: [dispatch] FW: New Version Notification for
> draft-marcon-msrp-over-webrtc-data-channels-00.txt****
>
>  ** **
>
> data, etc).****
> ** **
> together to find the best solution going forward.****
>
> ** **
>
> better catered for by the WebSocket-based solution, as described in draft-pd-dispatch-msrp-websocket,
> justification for this aspect of the draft.****
>
> ** **
>
> believe it should reference the syntax for the new "wdcsa" attribute.****
>
> ** **
>
> Regards,****
>
> Gavin Llewellyn****
>
> ** **
>
> --****
>
> Gavin Llewellyn****
>
> Principal Design Engineer****
>
> Crocodile RCS Ltd****
>
> GPG key: 0xF8F6FFF2****
>
> ** **
>
> [email-masked]> wrote:****
>
> https://www.ietf.org/mailman/listinfo/dispatch****
>
> ** **
>

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd