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

From: Gunnar Hellström <[email-masked]>
Date: Tue, 7 Apr 2020 11:00:18 +0200

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. 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

-- 

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

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 09:30:28 +0000

Hi,

The short answer is to use some signaling elements, most likely SDP attribute(s), to indicate support of, and negotiate usage of, different alternatives.

Regards,

Christer

On 07/04/2020, 12.00, "Gunnar Hellström" <[email-masked]> wrote:

    Christer,

    

    
    
    Regards
    
    Gunnar
    
    -- 

    Gunnar Hellström
    Omnitor

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 7 Apr 2020 13:15:22 +0200

Hi Christer,

> The short answer is to use some signaling elements, most likely SDP attribute(s), to indicate support of, and negotiate usage of, different alternatives.

So, then in draft-hellstrom-avtcore-multi-party-rtt-source I will 
propose a syntax of the a=rtt-mix attribute that allows a value and 
allows introduction of new values and more than one attribute in a media 
section. e.g. a=rtt-mix:rtp-mix   for the currently specified 
traditional rtp mixer.  And extendability to add other types of rtt 
multi-party solutions.  ... Or should the attribute rather be called 
rtt-multi ?

It will probably be easier to register a new value for an existing 
attribute in the future, rather than defining a new attribute. Right?

Regards

Gunnar

-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 11:34:15 +0000

Hi,

>    attribute in the future, rather than defining a new attribute. Right?
  
I think those details can be decided upon later. The first thing is to make sure you have a way to indicate/negotiate everything you need.

In any case, for now I would like to focus on getting the base t140 draft finalized :)

Regards,

Christer

    -- 

    Gunnar Hellström
    Omnitor

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 7 Apr 2020 10:35:22 -0400

Inline

On 4/7/20 5:00 AM, Gunnar Hellström wrote:
> 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

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 7 Apr 2020 19:28:00 +0200

Paul,  thanks for comments and questions,

Den 2020-04-07 kl. 16:35, skrev Paul Kyzivat:
>> 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 
>> multi-party capability. For an endpoint, it is an indication that it 
>> is able to understand the source of text and present it accordingly.
>>
>> 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.
>
> 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.
>
> other error, such as dropping of the SCTP association? Or perhaps 
> simply with the application at one end crashing?
>

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

-- 

Gunnar Hellström
Omnitor