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

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

Paul,  thanks for comments and questions,

Den 2020-04-07 kl. 16:35, skrev Paul Kyzivat:
> 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.

Yes, that was the scenario I imagined. It is a risk that implementations 
get designed for two-party sessions and suddenly get into a situation 
where multi-party functionality is expected. I assume that there are 
proper failure returns on requests to open new channels, so that it will 
be possible to activate the mixing for multi-party unaware endpoints in 
the initial channel if the application is of a kind that requires the 
call to be successful.

And since multi-party support is assumed in T.140, I hope that 
implementations will fulfill that up to some realistic number of users 
in a session.

With these assumptions, there will not be any need for a multi-party 
capability attribute for the WebRTC real-time text case.

Thanks,

Gunnar

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

-- 

+ + + + + + + + + + + + + +

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