Re: [MMUSIC] Multi-party use of draft-ietf-mmusic-t140-usage-data-channel

[Paul Kyzivat <[e-mail]>]

Inline

On 4/7/20 5:00 AM, Gunnar Hellström wrote:
> Christer,
> 
> This is not related to the reviews of 
> draft-ietf-mmusic-t140-usage-data-channel, but rather a question on its 
> use, and also related to the work with multi-party real-time text in 
> draft-hellstrom-avtcore-multi-party-rtt-source and 
> draft-hellstrom-avtcore-multi-party-rtt-solutions.
> 
> For the RTP based transport of real-time text, we have the situation 
> that many implementations exist which do not support multi-party, and 
> therefore I have drafted an sdp attribute a=rtt-mix to indicate 
> multi-party capability. For an endpoint, it is an indication that it is 
> able to understand the source of text and present it accordingly.
> 
> Now, the question about draft-ietf-mmusic-t140-usage-data-channel. In 
> section 5.5 it specifies multi-party considerations, with the main 
> alternative to open one more data channel per source between the mixer 
> and the endpoint, and a possible fallback to prepare a mix with limited 
> functionality for display in one display area with the sources inserted 
> as readable text.
> 
> How would you see a mixer select between these two alternatives? When a 
> third party enters the session, would the mixer just have a try to open 
> a new data channel, and use it for the third party if successful, and 
> use the fallback method if unsuccessful.

I'd like to understand the situations when adding a new data channel 
fails. SCTP allows a *lot* of channels (I forget how many), so it isn't 
likely that it will be the limitation. So it seems this must be a case 
where one end or the other lacks resources to support another channel.

How would this manifest itself? Would it be gracefully, with both ends 
discovering the failure to add a channel? Or would it manifest as some 
other error, such as dropping of the SCTP association? Or perhaps simply 
with the application at one end crashing?

For reasonable sized conferences I doubt that this will ever come up.

The most likely case I can imagine is an implementation that only 
supports one t140 channel and lacks the logic to present multiple 
speakers. *That* case is easily handled with your rtp-mix attribute.

	Thanks,
	Paul

> Or would the 
> draft-ietf-mmusic-t140-usage-data-channel use case also need an sdp 
> attribute of the same kind as a=rtt-mix ?
> 
> Also, how would the endpoint know if it is in contact with a traditional 
> mixer, so that it is sufficient to send its own text only in the first 
> opened data channel, or if the mixer is some kind of session 
> distribution unit, where the endpoint needs to transmit its own text 
> copied in all connected channels?
> 
> If an attribute is needed, the a=rtt-mix can possibly be specified so 
> that it is usable also for that case, or else the a=rtt-mix can be 
> specified as an attribute with an extendable set of values, e.g. 
> a=rtt-mix:rtp-mix and a=rtt-mix:multi-chan . What is your (or anybode 
> else's) view?
> 
> Regards
> 
> Gunnar
>