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

[Gunnar Hellström <[e-mail]>]

Hi Christer,

With "source" I in fact mean two things:

1. A unique identification of the source of the T140blocks used to 
separate the received text and present it in a way that is possible to 
read. This can correspond to SSRC or CSRC in RTP.  For the cases 1,2,3 
below, I think the stream ID is suitable for this purpose. For case 4, 
we do not have a solution yet for the WebRTC data channel, but for RTP, 
it is CSRC.

2. A presentable readable identity, that can be used to present some 
information about the sender of the real-time text. Different ways to 
present the text calls for different placement of that information. For 
one column per source, it can be in a column header, for an IRC-style 
real-time text presentation, it can be in a label in front of a received 
text chunk. For cases 1,2,3, the "label" is good for that purpose from 
the offering party, while something from session setup may be used to 
identify the answering part. In RTP, CNAME in RTCP may be a base for 
composing that kind of source info. Again, for case 4, we do not have 
any current solution.

I do not want to leave this topic until we have a solution on the way 
also for case 4.

A question: can we rely on the combining server to have some SDP 
signaling with all participants for each participant entering the 
multi-party call? If so, what?

I think we need two items, similar to CSRC and CNAME. One short and 
unique that can be repeated in each data channel message, and one 
longer, human readable that is sufficient to transmit less often, e.g. 
just when a participant enters the call.

We need to decide if it is sufficient to limit the application to only 
have T140blocks from one source in each T140 data channel message, or if 
we must be able to multiplex between sources in each T140 data channel 
message. If we allow only one source per message, then we may need to 
allow the transmission rate of T140 data messages to increase over what 
is normally used in a one-to-one situation.  How much overhead has a 
T140 data channel message and the exchanges occurring to get it delivered?

Regards


Gunnar


Den 2019-08-27 kl. 10:09, skrev Christer Holmberg:
>
> Hi Gunnar,
>
> >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.
>
> Yes. I also think it would be very difficult to get anything changed 
> in RTCWEB. They just closed the WG, and everyone just want the 
> documents to be published...
>
> >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.
>
> Yes.
>
> >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".
>
> Yes.
>
> RFC 4796 defines the SDP ‘content’ attribute, which can be used to 
> provide more information about a media stream. However, you need to 
> define and register actual values with IANA - you cannot use it for an 
> arbitrary string.
>
> >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.
>
> Just to clarify: what exactly do you mean by the “source”? For the 
> audio/video streams you will have the SSRC. Are you thinking about 
> something similar for the data channel?
>
> >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.
>
> Yes.
>
> (But such extension is outside the charter of MMUSIC.)
>
> >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.
>
> Please see my question regarding what you mean by “source”.
>
> Regards,
>
> Christer
>
> 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
>     >      > [e-mail] <mailto:[e-mail]>
>     >      > https://www.ietf.org/mailman/listinfo/mmusic
>     >
>     >      --
>     > -----------------------------------------
>     >      Gunnar Hellström
>     >      Omnitor
>     > [e-mail] <mailto:[e-mail]>
>     >      [phone]
>     >
>     >
>     >
>     > _______________________________________________
>     > mmusic mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/mmusic
>
>     -- 
>     -----------------------------------------
>     Gunnar Hellström
>     Omnitor
>     [e-mail] <mailto:[e-mail]>
>     [phone]
>
>
>
>     _______________________________________________
>
>     mmusic mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail] <mailto:[e-mail]>
> [phone]
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]