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.

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]