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

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Wed, 10 July 2013 14:22 UTC

Return-Path: <richard.ejzak@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F8421F99F4; Wed, 10 Jul 2013 07:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.979
X-Spam-Level:
X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW+udQi9kY3M; Wed, 10 Jul 2013 07:22:43 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1B41011E8167; Wed, 10 Jul 2013 07:22:41 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6AEMc0q025991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 09:22:38 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r6AEMbKv026861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 10:22:38 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.181]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 10 Jul 2013 10:22:37 -0400
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: Gavin Llewellyn <gavin.llewellyn@crocodilertc.net>
Thread-Topic: [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt
Thread-Index: AQHOfWPFLqfwD9/ad0qtPZT+Eb2kHZld542g
Date: Wed, 10 Jul 2013 14:22:36 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D802975@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <03FBA798AC24E3498B74F47FD082A92F3D80279E@US70UWXCHMBA04.zam.alcatel-lucent.com> <CAJJRMDvkZCQpRaAThRRhc+O64d=C3UZqHVrLWWmxf98gyOasGw@mail.gmail.com>
In-Reply-To: <CAJJRMDvkZCQpRaAThRRhc+O64d=C3UZqHVrLWWmxf98gyOasGw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D802975US70UWXCHMBA04z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, "mmusic@ietf.org WG" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [dispatch] FW: New Version Notification for draft-marcon-msrp-over-webrtc-data-channels-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 14:22:49 -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:gavin.llewellyn@crocodilertc.net]
Sent: Wednesday, July 10, 2013 6:51 AM
To: Ejzak, Richard P (Richard)
Cc: dispatch@ietf.org; mmusic@ietf.org 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) <richard.ejzak@alcatel-lucent.com<mailto:richard.ejzak@alcatel-lucent.com>> 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: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
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
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch