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

[Christer Holmberg <[e-mail]>]

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


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