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

[Peter Dunkley <[e-mail]>]

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) <
[e-mail]> 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:[e-mail]]
> *Sent:* Wednesday, July 10, 2013 6:51 AM
>
> *To:* Ejzak, Richard P (Richard)
> *Cc:* [e-mail]; [e-mail] 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****
>
> ** **
>
> --****
>
> Gavin Llewellyn****
>
> Principal Design Engineer****
>
> Crocodile RCS Ltd****
>
> GPG key: 0xF8F6FFF2****
>
> ** **
>
> On 9 July 2013 20:32, Ejzak, Richard P (Richard) <
> [e-mail]> 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: [e-mail] [mailto:[e-mail]]
> 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
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch****
>
> ** **
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd