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

Ted Hardie <ted.ietf@gmail.com> Fri, 16 October 2015 22:39 UTC

Return-Path: <ted.ietf@gmail.com>
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 300481A6FD2 for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 15:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 UadPerGtF_8R for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 15:39:38 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33AE1A6FBF for <mmusic@ietf.org>; Fri, 16 Oct 2015 15:39:38 -0700 (PDT)
Received: by qkfm62 with SMTP id m62so58938330qkf.1 for <mmusic@ietf.org>; Fri, 16 Oct 2015 15:39:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wWmEfpAtpYQvUEFCk6DWbam3DWI7TAyE3j4+yevTMD8=; b=VrtjCU5bGiuOJNOkSioMk/Eg8LkB9Ago1IYlCfBT+lZXx9jzXe7hoO3Uy1x48SW4+D dJRaR4Zjz5Ngg8x+POdtCPbVQn19P9tn5LC0r+ra9bR5QaaNooZSbzGwVQshjp1Vj3nJ TOz2gnQhxfQGcS0/uyNM1rkj9boJx32/lf2hzi3Vq2ugU3oUwv+wypmoPyT7K1ZHayzz oFlDAO0pfexjlDIIx0Q46MNmqLoMHEIgWnVnNKzOEjzkLCeZE5OOuk/nZVTADrMaaH+M xDY2paWxywcj7iW7T4dJ1usMC39Kn8eYL6F1bwZ85Ow7fnPre8WoJNXGHGY58soch67H CemA==
MIME-Version: 1.0
X-Received: by 10.55.24.6 with SMTP id j6mr21911179qkh.93.1445035177680; Fri, 16 Oct 2015 15:39:37 -0700 (PDT)
Received: by 10.55.50.2 with HTTP; Fri, 16 Oct 2015 15:39:37 -0700 (PDT)
In-Reply-To: <56217878.4000009@omnitor.se>
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>
Date: Fri, 16 Oct 2015 15:39:37 -0700
Message-ID: <CA+9kkMAr+QZxOowrxmGtjVX=MC1j8zR_Y4-EJECiPX_3t5_b8g@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Content-Type: multipart/alternative; boundary="001a11441cfe7446000522407867"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/fnWkBDUhcsj9p8gEyy8KuC5OzAs>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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: Fri, 16 Oct 2015 22:39:40 -0000

On Fri, Oct 16, 2015 at 3:21 PM, Gunnar Hellström <
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​.  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.  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).

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
won't be able to talk to chat.example.org), even if both could handle the
T.140 media type in RTP payload format.

regards,

Ted