Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

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

Den 2019-08-27 kl. 21:59, skrev Christer Holmberg:
> Hi,
>
>>>> 4. A multi-party server S, combining a number of sources into one
>>>> call to a participant A, with real-time text from each other
>>>> participant (B,C,...) communicated in just one T140 data channel
>>>> between S and A. There is a need to indicate source for each
>>>> T140block sent to A. We currently have no way specified for that. An
>>>> extension of T.140 could do it.
>>> Is there a reason to ever do this?
>>>
>>> In audio and video the "mixing" actually does something irreversible.
>>> And it takes real work to do it, and doing so reduces the bandwith
>>> considerably over what is required to transmit the individual streams.
>>>
>>> For RTT none of that is true. There is very little impact in bandwidth
>>> or processing in transmitting them all as separate channels.
>>>
>>> So why not just say "don't do that"?
>> Yes, interesting and realistic thought. It would likely be the best choice for many practical cases.
>>
>> I am not sure however how it will work with a huge conference with hundreds of participants, and some
>> of them occasionally asking for the floor and send a bit of RTT text. A server using one data channel per
>> participant would either be required to establish an enormous amount ofT140 data channels being prepared
>> to send what has been received, or take the effort to establish a new T140 data channel to all users at the
>> moment a user gets the floor, and then possibly close it again.
>>
>> What do you think about that case?
> You earlier told me about the IRC case, where meta data about the transmitted T140 text is included in the actual text, as some kind of a tag/label. You could define some kind of "protocol", so that the receiver doesn't print out those tags/labels as text, but use them for other things.
>
> That way you don't have to extend T140. But, it would obviously only work for endpoints that support the "protocol". Perhaps even IETF could define such "protocol"?

Yeah, maybe.

T.140 make use of control codes from ISO 6429, but implementations are 
not required to support all. Only a few are mentioned in T.140. So, it 
would be possible to take another control code sequence and use its 
parameter space for the source information we need.

But I think the documented extension mechanism is more suitable.

This is how it is expressed in T.140:

8.7 Application protocol function
Purpose: Identify coding of extensions to the protocol, so that the 
extensions can be introduced
unilaterally without disturbing the display.
Coding: SOS, function code, parameter string, ST.
Where: The function code is one ISO/IEC 10646-1 character uniquely 
identifying the function.
The parameter string shall not be more than 255 ISO/IEC 10646-1 
characters in length and shall not
include the ST character.
Procedure: The receiving terminal shall function according to the 
request. The whole function shall
be ignored by a terminal not supporting it. For terminals supporting the 
extended function, they will
have an effect specified for that function.
If no trailing ST is received after the maximum length of the parameter 
string, the protocol reverts to
normal element decoding mode.

(SOS and ST are control codes )

https://tools.ietf.org/html/draft-hellstrom-text-conference-04 proposes 
the following new extensions to T.140:


    6
    <https://tools.ietf.org/html/draft-hellstrom-text-conference-04#section-6>.
    Presentation level source indicator


    In certain application environments, it may be known to be unsuitable
    to use the CSRC identification on the RTP level as the base for
    identificating the source of text.  In such cases, an inline coding
    of the source of text SHOULD be applied in the data stream itself,
    and an RTP mixer function normally without CSRC identification used
    for coordinating the sources of text into one RTP stream.

    The support of this mixer type is indicated by the SIP header rtt-
    mix=t140, both by the focus and the user agent.

    Information uniquely identifying each user in the multi-party session
    SHALL then be placed as the parameter value "cn" in the T.140
    application protocol function with the function code "c".  The
    identifier shall thus be formatted like this: SOS c cn field contents
    ST, where SOS and ST are coded as specified in ITU-T T.140 [T.140  <https://tools.ietf.org/html/draft-hellstrom-text-conference-04#ref-T.140>].
    The cn parameter shall be kept short so that it can be repeated in
    the transmission without concerns for network load.
    The information otherwise conveyed in the NAME field of an SDES
    packet SHOULD then be placed as the parameter value in the T.140
    application protocol function with the function code "n".

    A T.140 application protocol function with the function code "c" MUST
    be included in the text in the beginning of text when the source of
    the text changes.  A T.140 application protocol function with the
    function code "c" MAY be repeated in the text from the same the
    source.  A T.140 application protocol function with the function code
    "n" MAY be included in the text to further provide identification of
    the transmitting party.  This information SHOULD also be provided in
    the SDES name field.  A receiving UA SHOULD separate text from the
    different sources and identify and display them accordingly.

    In this case, the mixer can use the redundancy transmission function
    ofRFC 4103  <https://tools.ietf.org/html/rfc4103>  without restrictions.

--------------------------------------------------------------------------------------------------

Before using it we must however as you say, know if the receiver support 
this. Otherwise, text from all participants will be merged in an 
unreadable way on the screen. So, a negotiation with an sdp attribute 
seems also to be needed.


Still, Paul's question is relevant: Do we need support for one data 
channel transporting RTT from many sources?

Regards


Gunnar



>
> Regards,
>
> Christer
>
>
>
>
>>      Thanks,
>>      Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic