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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 25 August 2019 21:27 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 26626120041 for <mmusic@ietfa.amsl.com>; Sun, 25 Aug 2019 14:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, URIBL_BLOCKED=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 8oJqzwvgS-IQ for <mmusic@ietfa.amsl.com>; Sun, 25 Aug 2019 14:27:57 -0700 (PDT)
Received: from bin-mail-out-06.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 CA5AE120020 for <mmusic@ietf.org>; Sun, 25 Aug 2019 14:27:56 -0700 (PDT)
X-Halon-ID: 2ef3ffc1-c77f-11e9-837a-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 2ef3ffc1-c77f-11e9-837a-0050569116f7; Sun, 25 Aug 2019 23:27:47 +0200 (CEST)
To: mmusic@ietf.org
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <665185b6-c1e7-62c3-4e3b-e9374d23bfd5@omnitor.se> <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>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <a5057f34-f222-e290-df88-da6e96d56294@omnitor.se>
Date: Sun, 25 Aug 2019 23:27:54 +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: <HE1PR07MB3161CC8F09E178F2E982E5AC93A60@HE1PR07MB3161.eurprd07.prod.outlook.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/qf_4im8At19g3O3Yt1ddDm7_c7s>
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: Sun, 25 Aug 2019 21:27:59 -0000

Hi Christer,

Please see inline,

Den 2019-08-25 kl. 11:23, 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.


Regards

Gunnar

>
> 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