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

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

Hi Christer,

Den 2020-04-07 kl. 11:30, skrev Christer Holmberg:
> 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.

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

>
> Regards,
>
> Christer
>
>
>
> On 07/04/2020, 12.00, "Gunnar Hellström" <[e-mail]> 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. 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
>      [e-mail]
>      [phone]
>      
>      
>
-- 

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

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