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

[Christer Holmberg <[e-mail]>]

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]
>      > https://www.ietf.org/mailman/listinfo/mmusic
>
>      --
>      -----------------------------------------
>      Gunnar Hellström
>      Omnitor
>      [e-mail]
>      [phone]
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

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