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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 26 August 2019 15:54 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 CFE1E120847 for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 08:54: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 iPmc8QTYCx1R for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 08:54:43 -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 08C2712083A for <mmusic@ietf.org>; Mon, 26 Aug 2019 08:54:42 -0700 (PDT)
X-Halon-ID: cf077119-c819-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 cf077119-c819-11e9-903a-005056917f90; Mon, 26 Aug 2019 17:54:39 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@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> <6c6d13ad-8699-73b9-f8aa-8ef16c5b3451@omnitor.se> <FB8E32BC-89C2-41CE-BBE1-81C4E7A56E77@ericsson.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <f59f9335-329d-7b26-dec3-0898051040ce@omnitor.se>
Date: Mon, 26 Aug 2019 17:54:38 +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: <FB8E32BC-89C2-41CE-BBE1-81C4E7A56E77@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/rD91OBaj_AQd4gCZ76wI7VDYWaA>
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 15:54:47 -0000

Hi Christer,

Bringing the "label" discussion into the right thread:

The discussion about the use of "label" for a visible representation of 
the source of text belonged of course to the multi-media aspects, and 
came from this proposal for text in a new section 4.5

"Presentation should be made so that the source of the real-time text is perceivable and the relative time relations in the conversation approximately presented.
The "label" attribute may be used to convey a presentable source."

As I said, I discovered that currently "label" is required in draft-ietf-rtcweb-data-channel-13 section 6.4 to be identical in both directions.

And you commented:
"If we want to change the identical requirement we need to raise it in RTCWEB.

It's probably a good idea to also ask them if they think 'label' is good for indicating source in the first place."

Yes, I think it is good to raise the issue in RTCWEB.

"label" could possibly be made good for indicating source in a similar way as CNAME is used for that in RTCP.
It is not guaranteed to be unique, so it cannot be part of the protocol for appending incoming T140blocks to the right real-time text stream. That is instead the task for the stream-id.

Without the "label" used for this purpose, we have no mechanism for knowing the source of a T.140 data channel.

But we also need to consider what happens when a T140 data channel breaks because of network problems and is then reconnected. Can the stream-id be reused for the reconnection, so that we can continue placing the new incoming text where it belongs? Or do we need to create a unique source attribute and add a place for it to the protocol?

Regards
Gunnar





Den 2019-08-26 kl. 11:15, skrev Christer Holmberg:
> Hi,
>
>> I can accept to not include "the T140 data channel data format".
>    
> Note that we are not restricting how the problem can be solved in the future. It's a note, and the sentence contains an "e.g.," in the so we are just giving examples :)
>
> Regards,
>
> Christer
>    
>
>
>      
>      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
>      
>      
>
> _______________________________________________
> 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