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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 26 August 2019 19:59 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 8BB98120E1F for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 12:59:42 -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, HTML_MESSAGE=0.001, 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 DIi6116BJBQp for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 12:59:37 -0700 (PDT)
Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (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 C6AB5120E1B for <mmusic@ietf.org>; Mon, 26 Aug 2019 12:59:36 -0700 (PDT)
X-Halon-ID: 002e24f3-c83c-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 002e24f3-c83c-11e9-837a-0050569116f7; Mon, 26 Aug 2019 21:59:24 +0200 (CEST)
To: mmusic@ietf.org, Christer Holmberg <christer.holmberg@ericsson.com>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.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> <f59f9335-329d-7b26-dec3-0898051040ce@omnitor.se> <VI1PR07MB31675A98F9B08A07D984369293A10@VI1PR07MB3167.eurprd07.prod.outlook.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <084e8ee3-56fe-b764-fbbe-8afbee72e8e3@omnitor.se>
Date: Mon, 26 Aug 2019 21:59:32 +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: <VI1PR07MB31675A98F9B08A07D984369293A10@VI1PR07MB3167.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------D7CE537FAA2162DC4BF6E57D"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/X5Z299UVr0Ovpfd1dBeWQOiiXDY>
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 19:59:43 -0000

Hi Christer,


I change my mind, I do not think we should try to modify the 
requirements on the "label" parameter. There are too many 
implementations made to the current specification.


So, let us look at the needs from a practical viewpoint:


1. For the simple case with a call between two users, opening just one 
T140 data channel between them, the sources are usually regarded to be 
the caller and the called parties. Some identities can be found in the 
call establishment for presenting the sources to the users.


2. For a more complex case with a call between two users, opening more 
than one T140 data channel between them, some kind of indication will be 
desired to show what purpose there is for the different T140 data 
channels. Assume for example that it is a foreign language learning 
session, with one channel for discussion held in one language and 
another channel for writing the original and translation proposals, ( so 
that the translation proposal stands there clearly on the screen while 
it is discussed in the other channel. The labels could help indicating 
the difference in use, e.g. "mother tongue discussion" and "translation 
original and result".


3. A multi-party server S, combining a number of sources into one call 
to a participant A, with real-time text from and to each other 
participant (B,C,...) communicated in one T140 data channel per 
participant. Only the server knows how many they are, so the server 
offers a number of T140 data channels in that call. Assigning a label 
with an identity (B, C,...) of the sourcing participant retrieved from 
the session information for that participant can help the receiving 
participant (A) to indicate the source. The server needs to do similar 
offers of T140 data channels to each participant and can provide some 
identity for each (retrieved from session information) in the label. So, 
here, use of the label for source seems to make sense.

If any T140 data channels breaks and reconnects, the same information is 
used for the reconnect and text can continue to be presented under the 
same source identity.


4. A multi-party server S, combining a number of sources into one call 
to a participant A, with real-time text from each other participant 
(B,C,...) communicated in just one T140 data channel between S and A.  
There is a need to indicate source for each T140block sent to A. We 
currently have no way specified for that. An extension of T.140 could do it.


Summary: The advice to use the label for source is useful, but should be 
limited to the source for offered T140 data channels. For answered T140 
data channels some session information may be used as source.


So, our sentence about label can be modified to:


The "label" attribute may be used by the offering party to convey a 
presentable source.


I hope the reasoning was possible to follow.


Regards


Gunnar




Den 2019-08-26 kl. 19:03, skrev Christer Holmberg:
> Hi Gunnar,
>
> >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.
>
> Correct.
>
> Just to clarify, though: as each data channel will use a unique SCTP 
> port/stream-id, it will be possible to associate each T140block with a 
> data channel.
>
> The "label" would be used to provide additional information (e.g., 
> source) about a data channel, but it is not needed to determine on 
> which data channel a T140block is received.
>
> >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?
>
> I would need to double-check what the specs say, but if the stream-id 
> change I assume there will a new offer/answer exchange to indicate that.
>
> >Or do we need to create a unique source attribute and add a place for it to the protocol?
>
> If we indicate the source in the SDP it is not needed.
>
> (In future, if a single data channel will be used for multiple 
> sources, then you obviously need something in the protocol - as we 
> will indicate in the NOTE).
>
> Regards,
>
> Christer
>
>
>
>
>
>
> 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
>
>
> _______________________________________________
> 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