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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 18 October 2015 14:03 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 423CC1A8831 for <mmusic@ietfa.amsl.com>; Sun, 18 Oct 2015 07:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 VYabH-o0jaO4 for <mmusic@ietfa.amsl.com>; Sun, 18 Oct 2015 07:03:14 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D031A8830 for <mmusic@ietf.org>; Sun, 18 Oct 2015 07:03:11 -0700 (PDT)
X-Halon-ID: ef4c0022-75a0-11e5-b25c-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [10.101.1.135] (unknown [88.131.62.38]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for <mmusic@ietf.org>; Sun, 18 Oct 2015 16:02:52 +0200 (CEST)
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> <56226AB8.9060002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B6469E@ESESSMB209.ericsson.se>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <5623A683.10700@omnitor.se>
Date: Sun, 18 Oct 2015 16:02:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B6469E@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/_ZmjirGElea4wokSaqIIVBNC3Hg>
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: Sun, 18 Oct 2015 14:03:18 -0000

Den 2015-10-18 kl. 14:44, skrev Christer Holmberg:
> Hi,
>
> ...
>
>> 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.
> For T.140 a specification makes sense, in order to ensure interoperability.
Agreed, e.g. one provider creates a gateway to SIP and another a WebRTC 
communication app, then it is good to indicate the protocol, and also 
have the common standard for how the transmission is done, e.g. media 
coding, error handling etc, even if it is straightforward.
>
> But, what if company wants to use the data channel for a protocol related to a game? In order to avoid name collisions it would be good for them to register the name, but I don't think they would want to reveal the details of the game protocol.
It seems that you can leave the subprotocol field empty and use a label 
instead as an internal indication within the private system about what 
the channel is intended for.  ( or any out-of-band agreement )

/Gunnar
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic