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

[Christer Holmberg <[e-mail]>]

Hi,

.

>> 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:
>
> 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 [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
>   of 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.

Indicating/mandating support of a feature should not be a big problem.

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

I don't know. Input from people with more experience from working with conference servers etc would be useful.

Regards,

Christer