Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 17 October 2015 15:35 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822281A9124 for <mmusic@ietfa.amsl.com>; Sat, 17 Oct 2015 08:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88ghcy6iY1Ak for <mmusic@ietfa.amsl.com>; Sat, 17 Oct 2015 08:35:23 -0700 (PDT)
Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1573A1A9121 for <mmusic@ietf.org>; Sat, 17 Oct 2015 08:35:22 -0700 (PDT)
Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-07v.sys.comcast.net with comcast id WFay1r0035AAYLo01FbNFV; Sat, 17 Oct 2015 15:35:22 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id WFbM1r00N3Ge9ey01FbNnX; Sat, 17 Oct 2015 15:35:22 +0000
To: mmusic@ietf.org
References: <786615F3A85DF44AA2A76164A71FE1ACDF796695@FR711WXCHMBA01.zeu.alcatel-lucent.com> <56202783.3010300@cisco.com> <7594FB04B1934943A5C02806D1A2204B37B45C83@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACDF79D867@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B45FDB@ESESSMB209.ericsson.se> <56213DD9.8080308@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B46EA0@ESESSMB209.ericsson.se> <5621596C.3070706@alum.mit.edu> <56215EA6.2010503@omnitor.se> <CA+9kkMApRrks_aMbKTzZideXM=Y-W+tqEhWCSmJXzT+TrsE8Sw@mail.gmail.com> <56217878.4000009@omnitor.se> <CA+9kkMAr+QZxOowrxmGtjVX=MC1j8zR_Y4-EJECiPX_3t5_b8g@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56226AB8.9060002@alum.mit.edu>
Date: Sat, 17 Oct 2015 11:35:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CA+9kkMAr+QZxOowrxmGtjVX=MC1j8zR_Y4-EJECiPX_3t5_b8g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445096122; bh=Al+mDJDxk3ZTTwRi6WNjlGsaoPFtNqik4HuQOoyq/0s=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PozM23DhcZalkYWIgcFIWGlpSFDOsVxBUo8qpcsn18bujmYPTsaN2uVRm2BprShyd M2RHNSnN2/hat5rKpINYnYO2/yKEKOTniutqvCOgoJC0k+RUXXjEmsGOrUDMOPO8pM ibmDVGEGezRZdKuqcarPnz0FMJbmKKIdiUYXcBCqV8MOsSsxASSjK7/QU846f/hV/f 8Xe8rc1RBBq08aA0rsX4GVoHoye4ZO3WDjH9sYoST2YZQ3jkIRbKGpPjX9Jn64mvLb mpN2diKaKyXo1KaXYZ0t/exaXHm5g2sjXdLJNKEzx5TMxxqpW+gtdys+DVVQY9lbbY bb4rtHpG76sOg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Cx_VGWyB0a-_bEWbaY5ZwTJTBWQ>
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 17 Oct 2015 15:35:24 -0000

On 10/16/15 6:39 PM, Ted Hardie wrote:
> On Fri, Oct 16, 2015 at 3:21 PM, Gunnar Hellström
> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>
>
>     Yes, but it is useful to use sdpneg to tell the other party what
>     protocol you want to use.
>
>
> ​I think this is where the confusion lies.  My understanding from Paul's
> message was that he felt that WebRTC endpoints could exchange real time
> text over a data channel, using T.140​.

Yes, that was my thought. More or less. I haven't thought through the 
details.

> In 4103 terms, I thought that
> meant sending text/t140 in RTP payload format (that is, one "T140block"
> per payload). I believe you could do this just using SCTP payload
> protocol identifiers.

If you were using SCTP natively then you could do that.
If you are using *data channels* then you can't use PPIDs for that. 
Instead, you need to negotiate the protocol when you open the channel, 
using the protocol name.

For webrtc browser apps this appears to be the only option.

> Any webrtc endpoint that received that would then
> send it off to whatever is listed in its media types handler registry as
> owning T.140 (if there is one).

Again, IIUC, webrtc should upset by any PPID other than the three 
defined for use with data channels.

So I think what is needed is to register a protocol name for T.140 (or 
for RTT). While no spec is required to register the name, one is needed 
to specify the semantics of the messages sent in that protocol. If it 
follows T.140 then it might be a very simple document.

	Thanks,
	Paul

> Presuming that this data channel is being negotiated between two clients
> both of which share the same javascript application, you could also
> assume that they negotiated it because they could handle the media type
> themselves.  That case isn't very different from the subprotocol case
> it's simply that it's a default rather than a named subprotocol.
>
> I note that if you go the sub-protocol route, your T.140 data channel
> will only get used if exactly the same sub-protocol is used
> (chat.example.com <http://chat.example.com> won't be able to talk to
> chat.example.org <http://chat.example.org>), even if both could handle
> the T.140 media type in RTP payload format.
>
> regards,
>
> Ted
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>