IETF Logo Mail Archive

Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 26 August 2019 09:11 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 0399B120111 for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 02:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 byPxWdRoK6TW for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 02:11:44 -0700 (PDT)
Received: from bin-mail-out-05.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 A223F120106 for <mmusic@ietf.org>; Mon, 26 Aug 2019 02:11:43 -0700 (PDT)
X-Halon-ID: 83a416f8-c7e1-11e9-903a-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id 83a416f8-c7e1-11e9-903a-005056917f90; Mon, 26 Aug 2019 11:11:40 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <DF010721-81CD-40DE-A848-DE4D36836FDA@ericsson.com> <ED158CF5-E059-482B-8D7E-934BA2C753A1@ericsson.com> <2201665d-5054-1872-d208-a0fe2d26095c@omnitor.se> <VI1PR07MB3167055C995D17D4BA9E36DE93A50@VI1PR07MB3167.eurprd07.prod.outlook.com> <8d14b055-8405-4a4f-174d-d7580bea348c@omnitor.se> <0DA1248C-41FC-4155-A578-29A19883857C@ericsson.com> <a91850b9-6e86-058f-dddd-3f856bcd6710@omnitor.se> <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@ericsson.com> <6fcf46a6-544d-027c-97c7-5c0e08caa555@omnitor.se> <HE1PR07MB3161A9A0C696B9636BBD380C93A70@HE1PR07MB3161.eurprd07.prod.outlook.com> <6484f305-0c38-4178-ee12-05a7dc38364f@omnitor.se> <HE1PR07MB31617F7C6E81EF041716749793A60@HE1PR07MB3161.eurprd07.prod.outlook.com> <ee4e6d3a-e984-15c7-dcaa-571be0e726b8@omnitor.se> <HE1PR07MB3161CC8F09E178F2E982E5AC93A60@HE1PR07MB3161.eurprd07.prod.outlook.com> <a5057f34-f222-e290-df88-da6e96d56294@omnitor.se> <A48CA18B-567B-46B9-9501-4FF65D4C8CAE@ericsson.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <6c6d13ad-8699-73b9-f8aa-8ef16c5b3451@omnitor.se>
Date: Mon, 26 Aug 2019 11:11:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <A48CA18B-567B-46B9-9501-4FF65D4C8CAE@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/mfH56uFcRIAj6Do5RPl6vtlEczo>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 26 Aug 2019 09:11:46 -0000

Hi Christer,

I can accept to not include "the T140 data channel data format".

Regards

Gunnar

Den 2019-08-26 kl. 09:33, skrev Christer Holmberg:
> Hi Gunnar,
>
>>>>> So, what about the following text:
>>>>>
>>>>> "If an implementation needs to support multi-party scenarios,
>>>>> implementations (both clients and servers) need to support multiple
>>>>> simultaneous T.140 data channels, one for each source. At the time of
>>>>> writing this document, this is true even in scenarios where each participants
>>>>> communicate via a centralized conference server. The reason is that, unlike
>>>>> RTP media, WebRTC data channels and the T.140 protocol do not support the
>>>>> indication of the source of T.140 data.
>>>> "participants" s.b. "participant"
>>> Will fix.
>>>
>>>>> NOTE: Future extensions to T.140, or to the T140block, might allow
>>>>> indicating the source of T.140 data, in which case it might be possible to use
>>>>> a single T.140 data channel to transport data from multiple sources."
>>>> Should also "the T140 data channel data format" be among the options for where to place the source information?
>>> What is the "data format"? Isn't the T140block the data format?
>>     
>>     Currently yes, but a more complex format could be defined, e.g. with a
>>     structure containing a source indicator and the T140blocks with some
>>     separator or structure. Of coulse it would be best to have that
>>     structure in place already from the beginning in this draft, so that
>>     there will be no interworking problems when a source address is
>>     introduced. Or at least a specified way to extend the format.
> Yes. But, again, that work would have to be done elsewhere. It is not within the charter of MMUSIC to define media plane formats.
>
> Regards,
>
> Christer
>   
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

v2.23.0 | Report a Bug | By Email