Subject: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2019 17:41:32 +0000

Hi,

Once upon a time in MMUSIC, there was work on a draft named draft-schwarz-mmusic-t140-usage-data-channel. 

Then, the authors stopped working on it, and nobody has been willing to take over.

The draft is a 3GPP dependency, so there is a need to get it finalized.

Some time ago I decided to take a close look at the draft, so see how much work it would take to finalize. One thing led ted to another, and I ended up re-writing the draft. Say hello to draft-holmberg-mmusic-t140-usage-data channel:

https://www.ietf.org/id/draft-holmberg-mmusic-t140-usage-data-channel-00.txt

The holmberg draft is based on the schwarz draft (also mentioned in the Acknowledgements), and much of the content is still the same. However, I have done editorial changes, and some re-structuring in order to better separate between the SDP considerations and the T.140 considerations.

The NEW technical stuff is describing how the T.140 abstract service functions map to T.140 data channels established with SDP O/A.

I have removed much of the Gateway text, because that's where most of the open issues were. That way, I also got rid of the dependency on draft-ietf-rtcweb-gateways, a draft I doubt is ever going to get finalized. If needed, gateway functions can be specified elsewhere, and 3GPP has already defined the H.248 parts for interworking between T.140 data channel and RFC 4103.

There are currently no open issues in the draft.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 Aug 2019 16:02:23 -0700

You may be interested to know that
draft-holmberg-mmusic-t140-usage-data-channel appears relevant to "RTC
Accessibility Use Cases" recently developed by the W3C APA WG:
https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases

On Fri, Aug 9, 2019 at 10:42 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> Once upon a time in MMUSIC, there was work on a draft named
> draft-schwarz-mmusic-t140-usage-data-channel.
>
> Some time ago I decided to take a close look at the draft, so see how much
> work it would take to finalize. One thing led ted to another, and I ended
> up re-writing the draft. Say hello to draft-holmberg-mmusic-t140-usage-data
> channel:
>
>
> The holmberg draft is based on the schwarz draft (also mentioned in the
> Acknowledgements), and much of the content is still the same. However, I
> have done editorial changes, and some re-structuring in order to better
> separate between the SDP considerations and the T.140 considerations.
>
> The NEW technical stuff is describing how the T.140 abstract service
> functions map to T.140 data channels established with SDP O/A.
>
> I have removed much of the Gateway text, because that's where most of the
> open issues were. That way, I also got rid of the dependency on
> draft-ietf-rtcweb-gateways, a draft I doubt is ever going to get finalized.
> If needed, gateway functions can be specified elsewhere, and 3GPP has
> already defined the H.248 parts for interworking between T.140 data channel
> and RFC 4103.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 17 Aug 2019 06:09:19 +0000

Hi Bernard,

Thank You for the information!

Does that mean you think we should adopt the draft? :)

Regards,

Christer

Lähettäjä: Bernard Aboba <[email-masked]>
Lähetetty: lauantai 17. elokuuta 2019 2.02
Vastaanottaja: Christer Holmberg <[email-masked]>
Kopio: [email-masked]
Aihe: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel

You may be interested to know that draft-holmberg-mmusic-t140-usage-data-channel appears relevant to "RTC Accessibility Use Cases" recently developed by the W3C APA WG:
https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases

On Fri, Aug 9, 2019 at 10:42 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: <[email-masked]>
Date: Tue, 20 Aug 2019 19:46:43 +0000

Hi
I support the adoption of the draft.
Best Regards
Roland

sent with Corporate Mobile Service

Am 17.08.2019 08:10 schrieb Christer Holmberg <[email-masked]>:
Hi Bernard,

Regards,

Christer

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Aug 2019 14:11:38 -0700

I also support adoption of this draft.

On Tue, Aug 20, 2019 at 12:46 PM <[email-masked]> wrote:

> *Lähettäjä:* Bernard Aboba <[email-masked]>
> *Lähetetty:* lauantai 17. elokuuta 2019 2.02
> *Vastaanottaja:* Christer Holmberg <[email-masked]>
> *Kopio:* [email-masked]
> *Aihe:* Re: [MMUSIC] Draft new:
> draft-holmberg-mmusic-t140-usage-data-channel
>
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 21 Aug 2019 22:47:18 +0200

Thanks Christer for bringing the t140-usage to life again.

Some comments below:

Den 2019-08-17 kl. 08:09, skrev Christer Holmberg:
> *Lähettäjä:*Bernard Aboba <[email-masked]>
Bernard, I noticed a mistake in that specification. A note close to the 
end says:

"*NOTE:*People familiar with Unix, and now Linux command line interfaces 
will understand the distinction described here as that between the two 
applications "write" and "talk." The former functions like RTT 
specifies. The latter functions like a classic IRC session. Both need to 
be supported by WebRTC user agents."

It seems to me that "write" and "talk" in the end of the first sentence 
are interchanged. The order should be "talk" and "write" to match the 
description in the second sentence. How can this be brought to the 
awareness of the editor of that document?

> On Fri, Aug 9, 2019 at 10:42 AM Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Some time ago I decided to take a close look at the draft, so see
>     how much work it would take to finalize. One thing led ted to
>     another, and I ended up re-writing the draft. Say hello to
>     draft-holmberg-mmusic-t140-usage-data channel:
>
>     The holmberg draft is based on the schwarz draft (also mentioned
>     in the Acknowledgements), and much of the content is still the
>     same. However, I have done editorial changes, and some
>     re-structuring in order to better separate between the SDP
>     considerations and the T.140 considerations.
>
>     The NEW technical stuff is describing how the T.140 abstract
>     service functions map to T.140 data channels established with SDP O/A.
>
>     I have removed much of the Gateway text, because that's where most
>     of the open issues were. That way, I also got rid of the
>     dependency on draft-ietf-rtcweb-gateways, a draft I doubt is ever
>     going to get finalized. If needed, gateway functions can be
>     specified elsewhere, and 3GPP has already defined the H.248 parts
>     for interworking between T.140 data channel and RFC 4103.
>
A couple of comments:

1) In 3.2, the attribute "cps" is misspelled "cpc" once.

2) Section 5 has some historical references to real-time text transports 
that may not be of much interest anymore and instead confuse the reader, 
while some other more relevant transports may be added.  I would also 
like to discuss if it could be possible to have a few general 
recommendations on the webrtc to sip/rfc4103 case without the problems 
you see with having a detailed gateway section.

3) Reliability. Section 3.1 implies that the channel is used in the 
reliable and ordered mode. We have been discussing back and forth if 
that is the right choice for real-time text. I tend to think it is, but 
it might be useful to discuss it once again. The traditional user 
requirement on real-time text is that produced characters shall be 
presented to the receiver within one second from their creation. Modern 
usage in speech-to-text applications may require more rapid 
transmission. As I understand it, the reliable mode of the data channel 
may imply long periods of choked transmission in case of network 
problems or by influence of heavy transmission in another channel. As 
long as this happens only in case of network problems, I now tend to 
think that that might be acceptable. The effects of being forced to use 
an unreliable channel are so far-going so I would like to avoid that.

However, the word "reliable" is misleading. A "reliable" channel is not 
really reliable. It can break in case of problems. I think some 
recommendations should be inserted in section 4 about what to do when a 
channel breaks. The natural action would be for both sides to try to 
figure out what was the last T.140 data that was transmitted and 
received, and then try to reconnect and resume transmission if 
successful. If any T.140 data was lost during the break, that state 
should be marked by inserting the "missing data" T.140 indicator in the 
received stream. There needs of course also be a recommended action if 
it turns out to be impossible to reconnect after a low number of retries.

Regards,

Gunnar

>     [email-masked] <mailto:[email-masked]>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Aug 2019 10:38:45 +0000

Hi Gunnar,

Thanks you for your support (I assume :) and comments on the draft! 

See inline.
  
>1) In 3.2, the attribute "cps" is misspelled "cpc" once.

Will fix.

---

>2) Section 5 has some historical references to real-time text transports that may not be of much interest anymore 
>and instead confuse the reader, while some other more relevant transports may be added. 

I took these from the schwarz draft. You probably know better than me which ones are relevant, so feel to suggest which one(s) should be removed, and which one(s) should be be added :)

>I would also like to discuss if it could be possible to have a few general recommendations on the webrtc to sip/rfc4103 case without 
>the problems you see with having a detailed gateway section.

The second last paragraph covers some things on the media plane (out of order and loss of RTP packets) that I think are worth mentioning.

As far as SDP interworking is concerned, this draft defines the m- line for T.140 data channel, and RFC 4103 defines the m- line for T.140 RTP, and the interworking should be very straight forwards. Do you have something specific in mind regarding general recommendations?

---

> 3) Reliability. Section 3.1 implies that the channel is used in the reliable and ordered mode. We have been discussing back and forth
> if that is the right choice for real-time text. I tend to think it is, but it might be useful to discuss it once again. The traditional user 
> requirement on real-time text is that produced characters shall be presented to the receiver within one second from their creation. 
> Modern usage in speech-to-text applications may require more rapid transmission. As I understand it, the reliable mode of the 
> data channel may imply long periods of choked transmission in case of network problems or by influence of heavy transmission 
> in another channel. As long as this happens only in case of network problems, I now tend to think that that might be acceptable. 
> The effects of being forced to use an unreliable channel are so far-going so I would like to avoid that.
> However, the word "reliable" is misleading. A "reliable" channel is not really reliable. It can break in case of problems. 

True, but "reliable" is the terminology used in both RFC 4960 (SCTP) and draft-ietf-rtcweb-data-channel.

> I think some recommendations should be inserted in section 4 about what to do when a channel breaks. The natural action 
> would be for both sides to try to figure out what was the last T.140 data that was transmitted and received, and then try to 
> reconnect and resume transmission if successful. If any T.140 data was lost during the break, that state should be marked 
> by inserting the "missing data" T.140 indicator in the received stream. There needs of course also be a recommended action 
> if it turns out to be impossible to reconnect after a low number of retries. 

I can for sure add some text about that. Are there generic T.140 recommendations for failure that we can reference, or do you think there is something T.140 data channel specific? 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Aug 2019 14:28:52 +0000

I have created a pull request, which will be used for the changes based on Gunnar's comments:

https://github.com/cdh4u/draft-datachannel-t140/pull/5

Regards,

Christer

On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Gunnar,

    See inline.

    Will fix.
    
    ---

    

    
    ---

    

    Regards,
    
    Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 22 Aug 2019 22:34:16 +0200

I want to add one issue for the security section: Can we specify a way 
to achieve end-to-end encryption of T.140 data between a WebRTC endpoint 
and a traditional SIP/RFC 4103 endpoint through a gateway? I know that 
that is a desired feature.

/Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Aug 2019 20:55:08 +0000

Hi,

>I want to add one issue for the security section: Can we specify a way to achieve end-to-end encryption of T.140 >data between a WebRTC endpoint and a traditional SIP/RFC 4103 endpoint through a gateway? I know that that is a >desired feature.

How would you do that? The data channel uses DTLS encryption, and SIP/RFC 4103 uses SRTP encryption, so doesn't the gateway have to decrypt/encrypt the T.140 traffic?

Regards,

Christer

Den 2019-08-22 kl. 16:28, skrev Christer Holmberg:
> https://protect2.fireeye.com/url?k=f453465c-a88743e3-f45306c7-868f633d
> bf25-4deb49c05b8a2375&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-d
> atachannel-t140%2Fpull%2F5
>
> Regards,
>
> Christer
>
>      I took these from the schwarz draft. You probably know better 
> than me which ones are relevant, so feel to suggest which one(s) 
> should be removed, and which one(s) should be be added :)
>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 23 Aug 2019 12:01:41 +0200

> How would you do that? The data channel uses DTLS encryption, and SIP/RFC 4103 uses SRTP encryption, so doesn't the gateway have to decrypt/encrypt the T.140 traffic?

I have just heard the requirement to have end-to-end encryption of RTT, 
I do not have the solution. One possibility would maybe be to have media 
encryption end-to-end as well as the two transport encryptions. But that 
complicates the possibility to insert the missing text markers by the 
gateway if text loss is detected.

/Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 10:09:29 +0000

Hi,

>>> I want to add one issue for the security section: Can we specify a way to achieve end-to-end encryption of T.140 
>>> data between a WebRTC endpoint and a traditional SIP/RFC 4103 endpoint through a gateway? I know that that is a 
>>> desired feature.
>>
>> How would you do that? The data channel uses DTLS encryption, and SIP/RFC 4103 uses SRTP encryption, so 
>> doesn't the gateway have to decrypt/encrypt the T.140 traffic?
>    
  
Yes.

However, keep in mind that the scope of the draft is how to use SDP O/A to negotiate a T.140 WebRTC data channel. We DO include some text regarding interworking with SIP/RFC 4103, because we know there are environments where such interworking takes place.

But, extending T.140 and/or RFC 4103 (e.g., defining a new application level encryption mechanism for T.140) is outside the scope.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 23 Aug 2019 14:51:05 +0200

I hope I can stop introducing new topics soon, and contribute to 
resolving them instead... But another topic to cover is multi-party 
session support.  The requirement is:

    U-C 5:  Realtime text chat during an audio and/or video call with an
            individual or with multiple people in a conference.

I hope that will be straightforward.

/Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 13:08:35 +0000

Hi,

>I hope I can stop introducing new topics soon, and contribute to resolving them instead... But another topic to cover is multi-party session >support.  The requirement is:

I can't think of any impact on the document based on that. The SDP for such conference will contain an m- line for the T.140 data channel, as described in the draft, and m- lines for the RTP audio and video streams (described elsewhere).

If there are some additional conference specific SDP attributes are needed for the T.140 data channel we can add them, but I can't think of any.  

Regards,

Christer

   
  
Yes.

Regards,

Christer

    >> On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg" mailto:[email-masked]@ericsson.com wrote:
    >>
    >>       Hi Gunnar,
    >>       
    >>       mailto:[email-masked]
    > mailto:[email-masked]
    > +46 708 204 288
    >
    > mailto:[email-masked]
    
    -- 
    -----------------------------------------
    Gunnar Hellström
    Omnitor
    mailto:[email-masked]
    +46 708 204 288

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
mailto:[email-masked]
+46 708 204 288

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Aug 2019 10:26:19 -0400

Gunnar,

What is the source for these requirements?

	Thanks,
	Paul

On 8/23/19 8:51 AM, Gunnar Hellström wrote:
>>      >> On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg"<[email-masked] on behalf of [email-masked]>  wrote:
>>      >>
>>      >>       Hi Gunnar,
>>      >>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 23 Aug 2019 16:56:36 +0200

> What is the source for these requirements?
Paul, assuming that you ask for the source for all requirements I have 
mentioned:

1. The cited U-C 5 requirement for multi-party support is from section 
3.2 of draft-ietf-rtcweb-data-channel-13

2. The end-to-end encryption between technologies is hearsay from the 
NANC INTEROPERABLE VIDEO CALLING group. I do not have the exact source.

3. The user requirement for a maximum of one second delay from text 
entry to far end presentation is from ITU-T F.700 / F.703 (the 
requirement may be more strict nowadays because of new applications)

4. The requirement to insert a missing text marker in case of suspected 
loss is from ITU-T T.140 amendment 1

5. The requirement to try to reconnect in case of channel break is just 
general user expectation on call behavior. If the session is still up 
and the RTP media flows, then the RTT is also expected to be maintained. 
Only if the whole session is also lost, then it is accepted to give up 
on the RTT.

Regards

Gunnar

>>>>>> I want to add one issue for the security section: Can we specify 
>>>>>> a way to achieve end-to-end encryption of T.140
>>>>>> data between a WebRTC endpoint and a traditional SIP/RFC 4103 
>>>>>> endpoint through a gateway? I know that that is a
>>>>>> desired feature.
>>> However, keep in mind that the scope of the draft is how to use SDP 
>>> O/A to negotiate a T.140 WebRTC data channel. We DO include some 
>>> text regarding interworking with SIP/RFC 4103, because we know there 
>>> are environments where such interworking takes place.
>>>
>>> But, extending T.140 and/or RFC 4103 (e.g., defining a new 
>>> application level encryption mechanism for T.140) is outside the scope.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>      >
>>>      >
>>>      > Den 2019-08-22 kl. 16:28, skrev Christer Holmberg:
>>>      >> I have created a pull request, which will be used for the 
>>> changes based on Gunnar's comments:
>>>      >>
>>>      >> 
>>>      >> atachannel-t140%2Fpull%2F5
>>>      >>
>>>      >> Regards,
>>>      >>
>>>      >> Christer
>>>      >>
>>>      >> On 22/08/2019, 13.39, "mmusic on behalf of Christer 
>>> Holmberg"<[email-masked] on behalf of 
>>>      >>
>>>      >>       Hi Gunnar,
>>>      >>
>>>      >>       Thanks you for your support (I assume :) and comments 
>>> on the draft!
>>>      >>
>>>      >>       See inline.
>>>      >>
>>>      >>       >A couple of comments:
>>>      >>       >1) In 3.2, the attribute "cps" is misspelled "cpc" once.
>>>      >>
>>>      >>       Will fix.
>>>      >>
>>>      >>       ---
>>>      >>
>>>      >>       >2) Section 5 has some historical references to 
>>> real-time text transports that may not be of much interest anymore
>>>      >>       >and instead confuse the reader, while some other more 
>>> relevant transports may be added.
>>>      >>
>>>      >>       I took these from the schwarz draft. You probably know 
>>> better
>>>      >> than me which ones are relevant, so feel to suggest which 
>>> one(s)
>>>      >> should be removed, and which one(s) should be be added :)
>>>      >>
>>>      >>       >I would also like to discuss if it could be possible 
>>> to have a few general recommendations on the webrtc to sip/rfc4103 
>>> case without
>>>      >>       >the problems you see with having a detailed gateway 
>>> section.
>>>      >>
>>>      >>       The second last paragraph covers some things on the 
>>> media plane (out of order and loss of RTP packets) that I think are 
>>> worth mentioning.
>>>      >>
>>>      >>       As far as SDP interworking is concerned, this draft 
>>> defines the m- line for T.140 data channel, and RFC 4103 defines the 
>>> m- line for T.140 RTP, and the interworking should be very straight 
>>> forwards. Do you have something specific in mind regarding general 
>>> recommendations?
>>>      >>
>>>      >>       ---
>>>      >>
>>>      >>       > 3) Reliability. Section 3.1 implies that the channel 
>>> is used in the reliable and ordered mode. We have been discussing 
>>> back and forth
>>>      >>       > if that is the right choice for real-time text. I 
>>> tend to think it is, but it might be useful to discuss it once 
>>> again. The traditional user
>>>      >>       > requirement on real-time text is that produced 
>>> characters shall be presented to the receiver within one second from 
>>> their creation.
>>>      >>       > Modern usage in speech-to-text applications may 
>>> require more rapid transmission. As I understand it, the reliable 
>>> mode of the
>>>      >>       > data channel may imply long periods of choked 
>>> transmission in case of network problems or by influence of heavy 
>>> transmission
>>>      >>       > in another channel. As long as this happens only in 
>>> case of network problems, I now tend to think that that might be 
>>> acceptable.
>>>      >>       > The effects of being forced to use an unreliable 
>>> channel are so far-going so I would like to avoid that.
>>>      >>       > However, the word "reliable" is misleading. A 
>>> "reliable" channel is not really reliable. It can break in case of 
>>> problems.
>>>      >>
>>>      >>       True, but "reliable" is the terminology used in both 
>>> RFC 4960 (SCTP) and draft-ietf-rtcweb-data-channel.
>>>      >>
>>>      >>       > I think some recommendations should be inserted in 
>>> section 4 about what to do when a channel breaks. The natural action
>>>      >>       > would be for both sides to try to figure out what 
>>> was the last T.140 data that was transmitted and received, and then 
>>> try to
>>>      >>       > reconnect and resume transmission if successful. If 
>>> any T.140 data was lost during the break, that state should be marked
>>>      >>       > by inserting the "missing data" T.140 indicator in 
>>> the received stream. There needs of course also be a recommended action
>>>      >>       > if it turns out to be impossible to reconnect after 
>>> a low number of retries.
>>>      >>
>>>      >>       I can for sure add some text about that. Are there 
>>> generic T.140 recommendations for failure that we can reference, or 
>>> do you think there is something T.140 data channel specific?
>>>      >>
>>>      >>       Regards,
>>>      >>
>>>      >>       Christer
>>>      >>
>>>      >>
>>>      >> _______________________________________________
>>>      >>       mmusic mailing list
>>>      >>[email-masked]
>>>      >>https://www.ietf.org/mailman/listinfo/mmusic
>>>      >>
>>>      >>
>>>      > --
>>>      > -----------------------------------------
>>>      > Gunnar Hellström
>>>      > Omnitor
>>>      >[email-masked]
>>>      > +46 708 204 288
>>>      >
>>>      > _______________________________________________
>>>      > mmusic mailing list
>>>      >[email-masked]
>>>      >https://www.ietf.org/mailman/listinfo/mmusic
>>>           --

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Aug 2019 11:10:18 -0400

Gunnar,

> Only if the whole session is also lost, then it is accepted to give up 

Thanks! That helps me with context.

ISTM that some of these are *system* requirements that can't be resolved 
with link-level requirements, though there may be link-level features 
that can contribute to a solution.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Aug 2019 16:34:54 +0000

Hi,

>1. The cited U-C 5 requirement for multi-party support is from section 3.2 of draft-ietf-rtcweb-data-channel-13

I think the draft supports that requirement, but let me know if you think something is missing.

>2. The end-to-end encryption between technologies is hearsay from the NANC INTEROPERABLE VIDEO >CALLING group. I do not have the exact source.

I’d be happy to get more information about that, and if there are some mechanisms available we may be able to reference them. But, defining such mechanism is outside the scope of the draft.

>3. The user requirement for a maximum of one second delay from text entry to far end presentation is from ITU-T >F.700 / F.703 (the requirement may be more strict nowadays because of new applications)

That may be worth to take a look at. I am not sure there is much we can do in the draft in order guarantee such max delay, but it may be useful to point out.

>4. The requirement to insert a missing text marker in case of suspected loss is from ITU-T T.140 amendment 1

The text currently says:

“Data sending and reporting procedures conform to [T140].”

We can for sure add text if the missing text marker is not covered by that statement.

But, the idea is to only reference generic T.140 procedures, and only define the data channel specific aspects.

>5. The requirement to try to reconnect in case of channel break is just general user expectation on call behavior. If >the session is still up and the RTP media flows, then the RTT is also expected to be maintained. Only if the whole >session is also lost, then it is accepted to give up on the RTT.

That is for sure something we can add text about.

But, again, I don’t think it’s a data channel specific requirement, but we can describe how the re-connection etc takes place when using a data channel.

Thanks!

Regards,

Christer

I hope I can stop introducing new topics soon, and contribute to resolving them instead... But another topic to cover is multi-party session support.  The requirement is:

/Gunnar

Hi,

Regards,

Christer

     >> On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg"<[email-masked] on behalf of [email-masked]><mailto:[email-masked]@ericsson.com>  wrote:
     >>
     >>       Hi Gunnar,
     >>
     >[email-masked]<mailto:[email-masked]>
     > +46 708 204 288
     >
          --
     -----------------------------------------
     Gunnar Hellström
     Omnitor
     [email-masked]<mailto:[email-masked]>
     +46 708 204 288

--
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

--

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 24 Aug 2019 00:52:41 +0200

Christer,

Here is a first set of modification proposals for the topics I have 
mentioned, and a few more editorial, but lacking the end-to-end 
encryption requirement for the interworking case that I do not know how 
to handle.

I hope you can handle the simple change proposal format.

Regards

Gunnar

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

1. Change the title from

"T.140 Text Conversation over WebRTC Data Channels"

to

"T.140 Real-time Text over WebRTC Data Channels"

Reason: Real-time text is the current term for Text Conversation

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

2. Modify the second line of the abstract from

"transport mechanism for the ITU-T Protocol for multimedia application"

to

"transport mechanism for Real-time text media using the ITU-T Protocol 
for multimedia application"

Reason: Real-time text is an important keyword for this media.

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

3. In 1. Introduction, line 3, change from

    "conversation, also known as realtime text or text telephony. The"

to

    "conversation, also known as real-time text.  The"

Reason: Text telephony may use T.140, but is not required to have the 
same functionality as true real-time text.

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

4. In 1. Introduction, last sentence of first paragraph, modify:

The  native transport for IP networks is based on the Real-time Transport
    Protocol (RTP) [RFC4103].

to

The native transport for IP networks is RFC 4103 RTP Payload for Text 
Conversation" [RFC4103] based on the Real-time Transport
    Protocol (RTP).

Reason: It looked confusing with the RFC4103 reference after the RTP 
abbreviation.

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

5. In section 1. Introduction, first NOTE, second line there is an 
unbalanced right bracket.:

"to the originally introduced concept of a "T.140 data channel"] for"

Proposal: either delete the bracket or modify to [T140]

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

6. In 1. Introduction, the first NOTE,

Delete "back in 1998"

Reason: Irrelevant

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

7. In 1. Introduction, number the notes NOTE 1 and NOTE 2.

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

8. In 3.1 third line, delete "(m= line)". The correct term is "media 
description" that is already correctly used.

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

9. In 3.1 Use of dcmap Attribute:

The second paragraph says that the "label" attribute MUST be included,  
but the next to last line says "without any label" and the example lacks 
the label.

sdpneg says that "label" is optional, so I suggest that thestatement in 
the second paragraph is modified to not require "label"

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

10. In 3.2, first paragraph, third line, delete "(m= line)".

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

11. In 4th paragraph in 3.2, change "cpc" to "cps"

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

12. At the end of 3.2, add the following about language negotiation

The users may be interested to negotiate language to use during the 
real-time text session. This is done by including specifications of 
language capabilities in the media descriptors for the t140 data 
channels by use of dsca attributes hlang-send and hlang-recv according 
to RFC 8373 [RFC8373]. The format is as follows:
a=dsca:id hlang-send:language
a=dsca:id hlang-send:language
The negotiation is performed as indicated in RFC8373.

-EDITORs NOTE - There may be a need for IANA registration of this way to 
use the human language attributes.

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

13. In 3.3 Example, first line, delete "(m= line)"

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

14. In 4.1, fourth bullet point, Deny session,    change:

"reject a request the establishment of a T.140 data channel,"

to

"reject a request to establish a T.140 data channel,"

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

15. In 4.2, second paragraph, change "reduntant" to "redundant"

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

16. In 4.3, add at the end of the current paragraph:

"The user requirements for smooth flow and low latency in text 
conversation should be considered when assigning a buffer time. The 
default transmission interval of 300 milliseconds from [RFC4103] or 
lower is recommended also for T.140 data channels."

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

17. Add a new section 4.4

"

4.4 Loss of T140blocks

In case of network failure or congestion, T140 data channels may break. 
If this happens but the session sustains, it is recommended that a low 
number of retries are made to reconnect the T140 data channels. If 
reconnection is successful, an evaluation shall be made if any 
T140blocks were lost. Retransmission of already transmitted T140blocks 
MUST be avoided, and missing text markers [T140ad1] should be inserted 
in the received data stream where loss is detected or suspected and 
presented to the user.

If instead also the session breaks, the break is accepted as end of 
session and the user should be informed about the unexpected end of session.

"

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

18. Add a new section 4.5

4.5 Multi-party considerations

Implementations should be prepared to accept establishment and use of 
multiple T140 data channels in order to support multi-party sessions 
with real-time text. A number of scenarios are available for how 
multi-party sessions can be supported in the WebRTC environment. 
Implementations may select any suitable scenario.

Presentation should be made so that the source of the real-time text is 
perceivable and the relative time relations in the conversation 
approximately presented.  The "label" attribute may be used to convey a 
presentable source.

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

19. chapter 5, Gateway considerations is proposed to be replaced by the 
following:

"

5. Interworking Considerations

Real-time text transport protocols have been defined for a number of 
technical environments for both packet switched and circuit switched 
networks. Many of them are based on the ITU-T T.140 protocol on 
application and presentation level [T140]. Some of them are obsolete as 
their multimedia protocol base have become obsolete, while others are in 
use. When interworking with real-time text in another technical 
environment than WebRTC using the T.140 data channel is required, a 
number of factors need to be considered.

The most used other real-time text transport protocol than the T.140 
data channel is the RTP based RFC 4103 [RFC4103], used in legacy SIP 
situations. The considerations specified below for the interworking case 
between WebRTC with T.140 data channels and legacy SIP with RFC 4103 
based T.140 transport can be taken as examples of what to consider also 
for other interworking situations using gateways. The considerations 
specified here are not to be seen as comprehensive, but rather as a 
brief description and a set of reminders. The detailed gateway 
procedures are out of scope of this document.

5.1 Channel establishment

For each T140 data channel established on the WebRTC side of the 
gateway, an RFC 4103 RTP stream should be established on the legacy SIP 
side. Redundancy is by default declared and used on the RFC 4103 side to 
achieve reliability, while on the T.140 data channel side no redundancy 
and instead reliable channels are declared and used.

5.2 Transmission

During normal flow of text, T140blocks received from one side are 
transmitted in the related session on the other side of the gateway.

Keep-alive traffic is implicit on the T140 data channel side and not 
visible on the data channel transmission level, while some form of 
keep-alive traffic may need to be inserted and extracted by the gateway 
on the RTP side according to the habits for RFC 4103 usage.

It is advisable to use the same transmission interval on both sides of 
the gateway if possible, and by that be able to transmit as soon as 
data  is received, keeping the delay added by buffering in the gateway low.

If the RTP session contains more than one RTT stream in a multi-party 
call through a text mixer, a corresponding mechanism for establishment 
and transmission in multiple T140 data channels shall be used. The 
"label" attribute on the T140 data channel side may be made to 
correspond to the Cname RTP field of the stream on the RFC 4103 side.

If loss of data is detected or suspected after use of available 
redundancy on the RFC 4103 side, the gateway should insert the T.140 
missing text marker [T140ad1].

If a T140 data channel breaks while the session is maintained, a limited 
number of reconnection efforts should be made. If re-connection of the 
T140 data channel is successful, then if text loss was detected after 
the reconnection, missing text marker should be inserted in the stream 
sent to the RTP side.

-EDITOR NOTE-The last two items will be hard to achieve when an 
end-to-end encryption method is applied-

"

20. At the end of 9.1, insert

[T140ad1]     ITU-T, "Recommendation ITU-T T.140 Addendum 1 (02/2000)

[RFC8373]    IETF RFC 8373 Negotiation of Human Language

-------------------------------------------end of proposed 
changes--------------------------------

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 24 Aug 2019 11:26:42 +0200

A bit more about the proposal to add the use of the hlang-send and 
hlang-recv attributes for language negotiation.

Den 2019-08-24 kl. 00:52, skrev Gunnar Hellström:
> -EDITORs NOTE - There may be a need for IANA registration of this way 
> to use the human language attributes. 

RFC 8373 was created partly to satisfy a dependency from 3GPP requiring 
negotiation of language per media. We knew that the T140 text data 
channel was about to be specified, but we could not request IANA to 
register the use of the hlang- attributes because of the state of the 
t140-usage-data channel draft, so the registration request was deleted 
from RFC 8373. It needs to be completed now.

I think the following actions are needed:

12a: Allow use of hlang- attributes together with m=application media 
declarations

RFC 8373 has a statement in section 5.3 saying:
"This document does not define the use of language tags in media other 
than interactive streams of audio, video, and text (such as "message" or 
"application"). Such use could be supported by future work or by 
application agreement."

The reason for this limitation is that it must be clear for what 
modality (spoken or written or signed ) the language is intended to be 
used. For audio, text and video, RFC 8373 defines the implicit relation 
audio=spoken, text=written, video=signed, but for "application" there is 
no such implicit relation and it is in our case the subprotocol T140 
that we can be sure carries written language modality. So, we just need 
to specify in the draft that for media "application  / 
webrtc-datachannel" and subprotocol "t140", the language modality is 
"written".  It may in fact be evident from the context.

12b: Allow use of hlang-attributes in dsca parameter values.

RFC 8373 registers SDP parameter att-values hlang-send and hlang-recv 
only for media-level use. The registration requirements in rfc4566bis 
require us to register the use also on dsca(subprotocol) level for the 
t140 subprotocol.

I am not sure how to express that registration. The attributes and 
values are as defined in RFC 8373. We just need to add a usage level for 
SDP att-values hlang-send and hlang-recv for media "application  / 
webrtc-datachannel"

    o  Usage Level: Add the following
     dcsa(subprotocol).
         dcsa(t140)  for written media.

I would appreciate guidance on how this should be expressed in IANA 
considerations.

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Aug 2019 10:04:39 +0000

Hi Gunnar,

Thank You for the detailed review and suggestions! Please see inline.

> Here is a first set of modification proposals for the topics I have mentioned, and a few more editorial, but 
> lacking the end-to-end encryption requirement for the interworking case that I do not know how to handle.

Maybe that should be looked at as a separate delivery, probably in a separate WG (AVT?).

> I hope you can handle the simple change proposal format.

That's fine - based on the outcome of your comments I will update the pull request :)

> Reason: Real-time text is the current term for Text Conversation

See my reply to comment #3.

> "transport mechanism for Real-time text media using the ITU-T Protocol for multimedia application"
>

See my reply to comment #3.

> Reason: Text telephony may use T.140, but is not required to have the same functionality as true real-time text.

I will change as suggested.

4. In 1. Introduction, last sentence of first paragraph, modify:

> The native transport for IP networks is RFC 4103 RTP Payload for Text Conversation" [RFC4103] based on the Real-time Transport
>    Protocol (RTP).
>
> Reason: It looked confusing with the RFC4103 reference after the RTP abbreviation.

I will change as suggested, but I don't think we need to say "RFC 4103" in the beginning of the sentence.

So, something like:

"native transport for IP networks is "RTP Payload for Text Conversation" [RFC4103], based on the Real-time Transport Protocol (RTP) [RFC3550]."

> Proposal: either delete the bracket or modify to [T140]

I will remove the bracket, as there is a reference at the end of the sentence.

>Reason: Irrelevant

Will be removed.

Will add NOTE numbers.

8. In 3.1 third line, delete "(m= line)". The correct term is "media description" that is already correctly used.

In other documents (e.g., BUNDLE) we say "SDP media description (m= section)" on the first occurrence, and later only 'm= section'.

Maybe would could do the same in this document? I do agree that we don't need to say 'SDP media description' and 'm= section/m= line' in every occurrence.

9. In 3.1 Use of dcmap Attribute:

> The second paragraph says that the "label" attribute MUST be included, but the next to last line says 
> "without any label" and the example lacks the label.
>
> sdpneg says that "label" is optional, so I suggest that thestatement in the second paragraph is modified to not require "label"

Will fix as suggested.

See my reply to comment #8.

Will fix.

You sent a follow-up e-mail regarding this this comment, so I will address it in a reply to that e-mail.

See my reply to comment #8.

Will fix.

Will fix.

"The user requirements for smooth flow and low latency in text conversation should be considered when assigning a buffer time. 
The default transmission interval of 300 milliseconds from [RFC4103] or lower is recommended also for T.140 data channels."

I will add the text.

Is there a reason why you want to say "text conversation" instead of "real-time text conversation" in this case?

> If this happens but the session sustains, it is recommended that a low number of retries are made to reconnect
> the T140 data channels. If reconnection is successful, an evaluation shall be made if any T140blocks were lost. 
> Retransmission of already transmitted T140blocks MUST be avoided, and missing text markers [T140ad1] should 
> be inserted in the received data stream where loss is detected or suspected and presented to the user.
>
> If instead also the session breaks, the break is accepted as end of session and the user should be informed about the unexpected end of session.
>
>"

I will add the text (with some minor editorial changes).

> Implementations should be prepared to accept establishment and use of multiple T140 data channels in order to support multi-party sessions 
> with real-time text. A number of scenarios are available for how multi-party sessions can be supported in the WebRTC environment. 

I don't think we need the two last sentences.

Also, in some cases all communication will go via a central server, so there will only be one T.140 data channel towards each participant.

So, maybe something like:

"In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly 
with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels."

> Presentation should be made so that the source of the real-time text is perceivable and the relative time relations in the conversation approximately presented. 
> The "label" attribute may be used to convey a presentable source.

I am not sure I understand the "relative time relations" part.

Regarding the source, perhaps extending my suggested text above with something like:

"In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly 
with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels. The label
attribute can be used to provide information that helps an implementation to distinguish between the T.140 data channels."

In order to not make the e-mails too long, I will address this in a separate reply :)

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Aug 2019 10:25:55 +0000

Hi Gunnar,

Please see inline.

> The negotiation is performed as indicated in RFC8373.

I may modify it a little, but I will add the text.

There will be a pull request, so you will be able to comment on the text (and all other changes based on your comments) before a new draft version is submitted :)

> RFC 8373 was created partly to satisfy a dependency from 3GPP requiring negotiation of language per media. We knew 
> that the T140 text data channel was about to be specified, but we could not request IANA to register the use of the 
> hlang- attributes because of the state of the t140-usage-data channel draft, so the registration request was deleted from 
> RFC 8373. It needs to be completed now.

Not sure I follow. The attributes have been registered with IANA, and BCP47 is referenced for the attribute values. What else is needed?

---

>12a: Allow use of hlang- attributes together with m=application media declarations
>
> "This document does not define the use of language tags in media other than interactive streams of audio, video, and 
> text (such as "message" or "application"). Such use could be supported by future work or by application agreement."
>
> The reason for this limitation is that it must be clear for what modality (spoken or written or signed ) the language is intended 
> to be used. For audio, text and video, RFC 8373 defines the implicit relation audio=spoken, text=written, video=signed, but 
> for "application" there is no such implicit relation and it is in our case the subprotocol T140 that we can be sure carries written 
> language modality. So, we just need to specify in the draft that for media "application  / webrtc-datachannel" and subprotocol "t140", 
> the language modality is "written".  It may in fact be evident from the context.

I will look into it, but it seems like a useful clarification to make.

---

> RFC 8373 registers SDP parameter att-values hlang-send and hlang-recv only for media-level use. The registration requirements in rfc4566bis
> require us to register the use also on dsca(subprotocol) level for the t140 subprotocol.
>
> I am not sure how to express that registration. The attributes and values are as defined in RFC 8373. We just need to add a usage level
> for SDP att-values hlang-send and hlang-recv for media "application  / webrtc-datachannel"
>
> I would appreciate guidance on how this should be expressed in IANA considerations.

I don't think that is needed. We haven't registered other attributes that are carried within a dsca attribute either. From an SDP perspective, the attributes will still be used for media-level.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 25 Aug 2019 07:17:28 +0200

Christer,

I am satisfied with all your responses and actions except for number 18, 
the multi-party case. I will handle that in a separate answer.

For number 16, I had no reason for not inserting "real-time text" in the 
sentence you asked about.

Thanks, no inline comments here.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 25 Aug 2019 08:48:56 +0200

Hi Christer,

Below are comments on the multi-party considerations

No, T.140 has no source indicator of its own, it relies on the transport 
to indicate the source for each T140block. In RTP, this can be done by 
an RTP mixer making one stream from multiple sources including CSRC for 
the sources of the primary text and for the redundant generations of 
text in each packet. On the T140 data channel side, I do not know any 
corresponding way to indicate different sources in the same data channel.

The solutions I see are: 1) create one T140 channel per 
source/destination pair. or 2) Introduce a source indicator in the data 
format for the T140 data channel, either one per STCP message requiring 
all T140blocks in the message being from one source only, or inline 
between series of T140blocks from different sources.

This is because the real-time text from multiple sources simultaneously 
need to be presented with some separation, so that the text gets 
readable at least sentence-wise from each source. The T.140 Appendix 1 
shows two ways to do this, one column-oriented, and one 
sentence-oriented with a label per start of sentence. You can read more 
about the topic in draft-hellstrom-text-conference-04.txt 
<https://www.ietf.org/archive/id/draft-hellstrom-text-conference-04.txt>

> with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels."
While that is true, it does not tell us how to solve the case with a 
conference server.
> I am not sure I understand the "relative time relations" part.

In order to enable the reader to follow the flow of a multi-party text 
conversation, it is a good habit to present older text placed higher in 
the text area and newer text placed lower. (This is valid for both when 
you present text in one column per source and if you combine all sources 
in one (IRC-style) column).

It is also a good habit to present text from the same source readable 
together, e.g. sentence by sentence, (and not break the text just 
because a text item from another source was received during the time the 
sentence was created).

These two requirements are in conflict. A true time-related presentation 
would fragment simultaneous text from different sources into 
unreadability, and presenting all text from each source in one chunk 
each would give no clue about the flow of the discussion.

Therefore this expression " the relative time relations in the 
conversation approximately presented".

> attribute can be used to provide information that helps an implementation to distinguish between the T.140 data channels."
Yes, this is a good statement for the case without the server, or can be 
modified for a server that maintains a channel per source. But which 
solution do you prefer if we allow a mixing server?

1) require also servers to support one T140 data channel per source

2) introduce a data format for the T140 data channel containing a unique 
source identifier

3) introduce a source identifier in-line in the T.140 data stream. 
(T.140 is extendable)

/Gunnar

> -
> -

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Aug 2019 08:25:35 +0000

Hi Gunnar,

Please see inline.

> No, T.140 has no source indicator of its own, it relies on the transport to indicate the source for each T140block. 

Good point.

>In RTP, this can be done by an RTP mixer making one stream from multiple sources including CSRC for the sources
>of the primary text and for the redundant generations of text in each packet. On the T140 data channel side, I do
>not know any corresponding way to indicate different sources in the same data channel. 
>
> The solutions I see are:
>        1) create one T140 channel per source/destination pair. or 
>        2) Introduce a source indicator in the data format for the T140 data channel, either one per STCP message
>        requiring all T140blocks in the message being from one source only, or inline between series of T140blocks
>        from different sources. 
>
> This is because the real-time text from multiple sources simultaneously need to be presented with some separation, 
> so that the text gets readable at least sentence-wise from each source. The T.140 Appendix 1 shows two ways to do 
> this, one column-oriented, and one sentence-oriented with a label per start of sentence. You can read more about 
> the topic in https://www.ietf.org/archive/id/draft-hellstrom-text-conference-04.txt
>
>
> While that is true, it does not tell us how to solve the case with a conference server.
>
> In order to enable the reader to follow the flow of a multi-party text conversation, it is a good habit to present older text placed higher in 
> the text area and newer text placed lower. (This is valid for both when you present text in one column per source and if you combine all 
> sources in one (IRC-style) column).  
> It is also a good habit to present text from the same source readable together, e.g. sentence by sentence, (and not break the text just 
> because a text item from another source was received during the time the sentence was created).
> These two requirements are in conflict. A true time-related presentation would fragment simultaneous text from different sources into unreadability, 
> and presenting all text from each source in one chunk each would give no clue about the flow of the discussion.  
> Therefore this expression " the relative time relations in the conversation approximately presented".

Gotcha.

> Yes, this is a good statement for the case without the server, or can be modified for a server that maintains a channel per source.
>
> But which solution do you prefer if we allow a mixing server?
> 2) introduce a data format for the T140 data channel containing a unique source identifier
> 3) introduce a source identifier in-line in the T.140 data stream. (T.140 is extendable)

Short term, as far as the draft is concerned, I think we should go for alternative 1. Alternatives 2 and 3 would probably take some time, so 
if done I think it should be done as a separate task (and, again, probably in a separate WG).

So, what about the following text:

"If an implementation needs to support multi-party scenarios, implementations (both clients and servers) need
to support multiple simultaneous T.140 data channels, one for each source. At the time of writing this document, this
is true even in scenarios where each participants communicate via a centralized conference server. The reason is 
that, unlike RTP media, WebRTC data channels and the T.140 protocol do not support the indication of the source of T.140 data.

NOTE: Future extensions to T.140, or to the T140block, might allow indicating the source of T.140 data, in which case 
it might be possible to use a single T.140 data channel to transport data from multiple sources."

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 25 Aug 2019 10:56:04 +0200

Hi Christer,

Quite good, see one comment inline,

Gunnar

> Please see inline.
"participants" s.b. "participant"
> it might be possible to use a single T.140 data channel to transport data from multiple sources."
Should also "the T140 data channel data format" be among the options for 
where to place the source information?

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Aug 2019 09:23:38 +0000

Hi Gunnar,

...

>> "If an implementation needs to support multi-party scenarios, 
>> implementations (both clients and servers) need to support multiple 
>> simultaneous T.140 data channels, one for each source. At the time of 
>> writing this document, this is true even in scenarios where each participants 
>> communicate via a centralized conference server. The reason is that, unlike 
>> RTP media, WebRTC data channels and the T.140 protocol do not support the 
>>indication of the source of T.140 data.
>

Will fix.

>> NOTE: Future extensions to T.140, or to the T140block, might allow 
>> indicating the source of T.140 data, in which case it might be possible to use 
>> a single T.140 data channel to transport data from multiple sources."
>
> Should also "the T140 data channel data format" be among the options for where to place the source information?

What is the "data format"? Isn't the T140block the data format?

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 25 Aug 2019 12:17:26 +0200

Hi Christer,

Please see inline,

>> The negotiation is performed as indicated in RFC8373.

Whoops, there was a copy-paste error there. the second dsca attribute 
was intended to be:

a=dsca:id hlang-recv:language
also, the value may be a list of space separated language tags, so it would be more correct to say:

a=dsca:id hlang-send:language(s)
a=dsca:id hlang-recv:language(s)

This is a bit informal way to specify the format. Do you think it is acceptable? The reader should anyway look into RFC 8373 for the complete specification.

> Not sure I follow. The attributes have been registered with IANA, and BCP47 is referenced for the attribute values. What else is needed?
See below
> I will look into it, but it seems like a useful clarification to make.
Yes, it may be sufficient with a clear statement that for m=application 
/ webrtc-datachannel subprotocol T140, language indications according to 
RFC 8373 are allowed and indicate written language media. But that is a 
kind of extension over what RFC 8373 specified because the use for 
a=application was excluded there. Do we need to make IANA aware of that 
extension in some way?
> I don't think that is needed. We haven't registered other attributes that are carried within a dsca attribute either. From an SDP perspective, the attributes will still be used for media-level.

Yes, the sdpneg draft, section 9.2.2 seems to indicate that attributes 
already specified for media level are allowed to be used at dsca level 
without specific registration if the use is not modified from its 
original use at media level.

But rfc4566bis, section 8.2.4.2 about updates to existing attributes 
requires us to register if there is a change to the semantics of the 
original attribute. Maybe we should view as modified semantics the use 
together with m=application and the need to look at the subprotocol T140 
to understand that it is about written language indications.

If so, there is a simplified registration format in rfc4566bis 8.2.4.2 
that we could use.

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Aug 2019 14:12:15 +0000

Hi Gunnar,

>> channels by use of dsca attributes hlang-send and hlang-recv 
>> according to RFC 8373 [RFC8373]. The format is as follows:
> Whoops, there was a copy-paste error there. the second dsca attribute was intended to be:
>

I don't think we need to say anything how to specify. draft-data-channel-sdpneg defines how to convey SDP attributes in the dsca attribute, and 8873 defines the format of the hdland-send/recv attributes.

>>> RFC 8373 was created partly to satisfy a dependency from 3GPP 
>>> requiring negotiation of language per media. We knew that the T140 
>>> text data channel was about to be specified, but we could not request 
>>> IANA to register the use of the
>>> hlang- attributes because of the state of the t140-usage-data channel 
>>> draft, so the registration request was deleted from RFC 8373. It needs to be completed now.

>>> "This document does not define the use of language tags in media 
>>> other than interactive streams of audio, video, and text (such as "message" or "application"). 
>>> Such use could be supported by future work or by application agreement."
>>>
>>> modality (spoken or written or signed ) the language is intended to 
>>> be used. For audio, text and video, RFC 8373 defines the implicit 
>>> relation audio=spoken, text=written, video=signed, but for 
>>> "application" there is no such implicit relation and it is in our case the subprotocol T140 that 
>>> we can be sure carries written language modality. So, we just need to specify in the draft that 
>>> for media "application  / webrtc-datachannel" and subprotocol "t140", the language modality 
>>> is "written".  It may in fact be evident from the context.
>>
> Yes, it may be sufficient with a clear statement that for m=application / webrtc-datachannel 
> subprotocol T140, language indications according to RFC 8373 are allowed and indicate written 
> language media. But that is a kind of extension over what RFC 8373 specified because the use 
> for a=application was excluded there. Do we need to make IANA aware of that extension in some way?

Not sure about IANA, but it might be an update to 8373.

The problem is that we are not defining usage of the lang attributes, and modality, for the 'application/webrtc-datachannel' media type: we are defining modality and usage of the attributes for a specific data channel. 

     "This document updates RFC 8373, by defining how the SDP hlang-send and hlang-recv attributes are used for 
       the "application/webrtc-datachannel" media type. 

      SDP endpoints MUST NOT include the attributes directly in the m= section associated with the 
      'application/webrtc-datachannel' media type. Instead, the attributes MUST be associated with
      individual data channels, using the  SDP dcsa attribute. A specification that defines a subprotocol 
      that uses the attributes MUST specify the modality for that subprotocol. 

      For T.140 data channels the modality is 'written'."

(Of course, the text above should have been included in draft-data-channel-sdpneg, because in future one might use the lang attributes for other types of data channels than T.140. The draft is in the RFC EQ, and I don't think we want to bring it back to the WG, but maybe the t140 draft updates draft-data-channel-sdpneg too)

---

>>> only for media-level use. The registration requirements in rfc4566bis require 
>>> us to register the use also on dsca(subprotocol) level for the t140 subprotocol.
>>>
>>> SDP att-values hlang-send and hlang-recv for media "application  / webrtc-datachannel"
>>>
>> I don't think that is needed. We haven't registered other attributes that are carried within a dsca attribute either. 
>> From an SDP perspective, the attributes will still be used for media-level.
>
> Yes, the sdpneg draft, section 9.2.2 seems to indicate that attributes already specified for media level are allowed 
> to be used at dsca level without specific registration if the use is not modified from its original use at media level.
>
> But rfc4566bis, section 8.2.4.2 about updates to existing attributes requires us to register if there is a change to the 
> semantics of the original attribute. Maybe we should view as modified semantics the use together with m=application
> and the need to look at the subprotocol T140 to understand that it is about written language indications.

I personally don't think there is a change to the semantics of the original attribute. But, I'm sure we'll sort out the IANA stuff, once we get everything else done :)

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 25 Aug 2019 23:19:54 +0200

Hi Christer,

Please see inline,

> I don't think we need to say anything how to specify. draft-data-channel-sdpneg defines how to convey SDP attributes in the dsca attribute, and 8873 defines the format of the hdland-send/recv attri…
We could include an example instead.
>        For T.140 data channels the modality is 'written'."

This works for the T140 data channel, but another subprotocol may be 
able to carry more than one media type and therefore have some other 
indication of what media type is used. An example is the msrp data 
channel that can carry messages with different modalities.

So, yes, it is tempting to say that we extend RFC 8373 in general, but 
we can do in in a fully specified way only for the T140 data channel.

How would you express that?

> I personally don't think there is a change to the semantics of the original attribute. But, I'm sure we'll sort out the IANA stuff, once we get everything else done :)
Right, this discussion prepared us for real discussions on IANA 
registration.

Regards

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 25 Aug 2019 23:27:54 +0200

Hi Christer,

Please see inline,

Den 2019-08-25 kl. 11:23, skrev Christer Holmberg:
> ....

Currently yes, but a more complex format could be defined, e.g. with a 
structure containing a source indicator and the T140blocks with some 
separator or structure. Of coulse it would be best to have that 
structure in place already from the beginning in this draft, so that 
there will be no interworking problems when a source address is 
introduced. Or at least a specified way to extend the format.

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Aug 2019 07:30:00 +0000

Hi Gunnar,

>>> This is a bit informal way to specify the format. Do you think it is acceptable? The reader should 
>>> anyway look into RFC 8373 for the complete specification.
>> I don't think we need to say anything how to specify. draft-data-channel-sdpneg defines how to convey
>> SDP attributes in the dsca attribute, and 8873 defines the format of the hdland-send/recv attributes.

Yes.

---

>> The problem is that we are not defining usage of the lang attributes, and modality, for the 'application/webrtc-datachannel' media type: 
>> we are defining modality and usage of the attributes for a specific data channel.
>>
  
Sure, and the text says that each subprotocol specification need to define what the modality is.

(Of course, it would have been great if 8373 would have defined a way to explicitly indicate the modality, instead of implicitly retrieve it from the media type.)

>    How would you express that?

Using the suggested text above :)

- It updates 8373 by allowing usage of the lang attributes for application/webrtc-datachannel media types.
- It updates draft-data-channel-sdpneg, by indicating that the modality must be defined for each data channel that
  uses the lang attributes. In draft-t140-data-channel we then define the modality for T.140 data channels.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Aug 2019 07:33:28 +0000

Hi Gunnar,

>    introduced. Or at least a specified way to extend the format.

Yes. But, again, that work would have to be done elsewhere. It is not within the charter of MMUSIC to define media plane formats.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 26 Aug 2019 10:58:25 +0200

Hi Christer,

>> We could include an example instead.

Proposal:

Change 3.3. header from Example to Examples

Add at the end of 3.3 the following:

Another example is an offer for a T.140 data channel from an 
organisation offering real-time text conversation in Spanish and 
Esperanto, and an answer accepting Esperanto.

Offer:

  m=application 911 UDP/DTLS/SCTP webrtc-datachannel
        c=IN IP6 2001:db8::3
        a=max-message-size:1000
        a=sctp-port 5000
        a=dcmap:1 label="ACME customer service";subprotocol="t140"
        a=dcsa:1 fmtp:-
        a=dsca:1 hlang-send:es eo
        a=dsca:1 hlang-recv:es eo

Answer:

m=application 911 UDP/DTLS/SCTP webrtc-datachannel
        c=IN IP6 2001:db8::3
        a=max-message-size:1000
        a=sctp-port 5000
        a=dcmap:1 label="ACME customer service";subprotocol="t140"
        a=dcsa:1 fmtp:-
        a=dsca:1 hlang-send:eo
        a=dsca:1 hlang-recv:eo

(Christer, can you please insert the variations needed in the answer to 
make it a realistic example of offer - answer.)

> (Of course, it would have been great if 8373 would have defined a way to explicitly indicate the modality, instead of implicitly retrieve it from the media type.)
Agreed. It was discussed but not included in the final result.
>    uses the lang attributes. In draft-t140-data-channel we then define the modality for T.140 data channels.

Yes, I agree, it can be read your way.

But I read "A specification that defines a subprotocol that uses the 
attributes MUST specify the modality for that subprotocol." as if only 
one modality was tied to a specific subprotocol identity.

Can we change the sentence to "A specification that defines a 
subprotocol that uses the attributes MUST specify how the modality is 
deducted for languages used with that subprotocol."

Regards

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 26 Aug 2019 11:11:40 +0200

Hi Christer,

I can accept to not include "the T140 data channel data format".

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Aug 2019 09:15:41 +0000

Hi,

>I can accept to not include "the T140 data channel data format".
  
Note that we are not restricting how the problem can be solved in the future. It's a note, and the sentence contains an "e.g.," in the so we are just giving examples :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Aug 2019 09:28:34 +0000

Hi Gunnar,

...

>    make it a realistic example of offer - answer.)
  
If we want to keep it realistic, should we really use Esperanto? :)

One of my teachers in high school was a big fan of Esperanto, and claimed that it will take over English as the number one world language. But, that was only 30 years ago, so I guess there is still time :)

---

... 

> Agreed. It was discussed but not included in the final result.

I think anything "implicit" should be forbidden in IETF standards - it always creates problems sooner or later....

 Will fix.

 Regards,

 Christer

    Regards
    
    Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 26 Aug 2019 12:50:28 +0200

Hi Christer,

I have met people who communicate with email in Esperanto. So Esperanto 
is used. But if you want to have a more common language in the example, 
you may exchange eo with for example it for Italian.

---

I just discovered in the draft-ietf-rtcweb-data-channel draft section 
6.4 that the "label" is supposed to be identical in the offar and 
answer. We agreed to insert text somewhere that "label" can be used to 
indicate source. With the requirement that it shall be identical, it is 
only half true that it can indicate source. I forgot where we had that 
wording, so please check its relevance while you edit the resulting 
modifications.

Nothing new inline.

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Aug 2019 11:21:52 +0000

Hi,
    
>    you may exchange eo with for example it for Italian.
  
I am fine using Esperanto. Maybe my old teacher will read the draft and remember me :)

---
    
>    wording, so please check its relevance while you edit the resulting 

If we want to change the identical requirement we need to raise it in RTCWEB. 

It's probably a good idea to also ask them if they think 'label' is good for indicating source in the first place.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 26 Aug 2019 17:54:38 +0200

Hi Christer,

Bringing the "label" discussion into the right thread:

The discussion about the use of "label" for a visible representation of 
the source of text belonged of course to the multi-media aspects, and 
came from this proposal for text in a new section 4.5

"Presentation should be made so that the source of the real-time text is perceivable and the relative time relations in the conversation approximately presented.
The "label" attribute may be used to convey a presentable source."

As I said, I discovered that currently "label" is required in draft-ietf-rtcweb-data-channel-13 section 6.4 to be identical in both directions.

And you commented:
"If we want to change the identical requirement we need to raise it in RTCWEB.

It's probably a good idea to also ask them if they think 'label' is good for indicating source in the first place."

Yes, I think it is good to raise the issue in RTCWEB.

"label" could possibly be made good for indicating source in a similar way as CNAME is used for that in RTCP.
It is not guaranteed to be unique, so it cannot be part of the protocol for appending incoming T140blocks to the right real-time text stream. That is instead the task for the stream-id.

Without the "label" used for this purpose, we have no mechanism for knowing the source of a T.140 data channel.

But we also need to consider what happens when a T140 data channel breaks because of network problems and is then reconnected. Can the stream-id be reused for the reconnection, so that we can continue placing the new incoming text where it belongs? Or do we need to create a unique source attribute and add a place for it to the protocol?

Regards
Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Aug 2019 17:03:54 +0000

Hi Gunnar,

>"Presentation should be made so that the source of the real-time text is
>perceivable and the relative time relations in the conversation approximately presented.
> As I said, I discovered that currently "label" is required in draft-ietf-rtcweb-data-channel-13
> section 6.4 to be identical in both directions.
>
> And you commented:
>It is not guaranteed to be unique, so it cannot be part of the protocol for appending incoming T140blocks to the >right real-time text stream. That is instead the task for the stream-id.
>

Correct.

Just to clarify, though: as each data channel will use a unique SCTP port/stream-id, it will be possible to associate each T140block with a data channel.

The "label" would be used to provide additional information (e.g., source) about a data channel, but it is not needed to determine on which data channel a T140block is received.

>But we also need to consider what happens when a T140 data channel breaks because of network problems and >is then reconnected. Can the stream-id be reused for the reconnection, so that we can continue placing the new >incoming text where it belongs?

I would need to double-check what the specs say, but if the stream-id change I assume there will a new offer/answer exchange to indicate that.

>Or do we need to create a unique source attribute and add a place for it to the protocol?

If we indicate the source in the SDP it is not needed.

(In future, if a single data channel will be used for multiple sources, then you obviously need something in the protocol - as we will indicate in the NOTE).

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 26 Aug 2019 21:59:32 +0200

Hi Christer,

I change my mind, I do not think we should try to modify the 
requirements on the "label" parameter. There are too many 
implementations made to the current specification.

So, let us look at the needs from a practical viewpoint:

1. For the simple case with a call between two users, opening just one 
T140 data channel between them, the sources are usually regarded to be 
the caller and the called parties. Some identities can be found in the 
call establishment for presenting the sources to the users.

2. For a more complex case with a call between two users, opening more 
than one T140 data channel between them, some kind of indication will be 
desired to show what purpose there is for the different T140 data 
channels. Assume for example that it is a foreign language learning 
session, with one channel for discussion held in one language and 
another channel for writing the original and translation proposals, ( so 
that the translation proposal stands there clearly on the screen while 
it is discussed in the other channel. The labels could help indicating 
the difference in use, e.g. "mother tongue discussion" and "translation 
original and result".

3. A multi-party server S, combining a number of sources into one call 
to a participant A, with real-time text from and to each other 
participant (B,C,...) communicated in one T140 data channel per 
participant. Only the server knows how many they are, so the server 
offers a number of T140 data channels in that call. Assigning a label 
with an identity (B, C,...) of the sourcing participant retrieved from 
the session information for that participant can help the receiving 
participant (A) to indicate the source. The server needs to do similar 
offers of T140 data channels to each participant and can provide some 
identity for each (retrieved from session information) in the label. So, 
here, use of the label for source seems to make sense.

If any T140 data channels breaks and reconnects, the same information is 
used for the reconnect and text can continue to be presented under the 
same source identity.

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.

Summary: The advice to use the label for source is useful, but should be 
limited to the source for offered T140 data channels. For answered T140 
data channels some session information may be used as source.

So, our sentence about label can be modified to:

The "label" attribute may be used by the offering party to convey a 
presentable source.

I hope the reasoning was possible to follow.

Regards

Gunnar

Den 2019-08-26 kl. 19:03, skrev Christer Holmberg:
> > It's probably a good idea to also ask them if they think 'label' is 
> good for indicating source in the first place."
> >
> >It is not guaranteed to be unique, so it cannot be part of the 
> protocol for appending incoming T140blocks to the >right real-time 
> text stream. That is instead the task for the stream-id.
> >
> Just to clarify, though: as each data channel will use a unique SCTP 
> port/stream-id, it will be possible to associate each T140block with a 
> data channel.
>
> The "label" would be used to provide additional information (e.g., 
> source) about a data channel, but it is not needed to determine on 
> which data channel a T140block is received.
>
> >But we also need to consider what happens when a T140 data channel breaks because of network 
> problems and >is then reconnected. Can the stream-id be reused for the 
> reconnection, so that we can continue placing the new >incoming text 
> where it belongs?
>
> I would need to double-check what the specs say, but if the stream-id 
> change I assume there will a new offer/answer exchange to indicate that.
>
> (In future, if a single data channel will be used for multiple 
> sources, then you obviously need something in the protocol - as we 
> will indicate in the NOTE).
>
> Regards,
>
> Christer
>
>
>
>
>
>
> > Note that we are not restricting how the problem can be solved in 
> the future. It's a note, and the sentence contains an "e.g.," in the 
> so we are just giving examples :)
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >      > Hi Gunnar,
> >      >>>>> So, what about the following text:
> >      >>>>>
> >      >>>>> "If an implementation needs to support multi-party scenarios,
> >      >>>>> implementations (both clients and servers) need to 
> support multiple
> >      >>>>> simultaneous T.140 data channels, one for each source. At 
> the time of
> >      >>>>> writing this document, this is true even in scenarios 
> where each participants
> >      >>>>> communicate via a centralized conference server. The 
> reason is that, unlike
> >      >>>>> RTP media, WebRTC data channels and the T.140 protocol do 
> not support the
> >      >>>>> indication of the source of T.140 data.
> >      >>>> "participants" s.b. "participant"
> >      >>> Will fix.
> >      >>>
> >      >>>>> NOTE: Future extensions to T.140, or to the T140block, 
> might allow
> >      >>>>> indicating the source of T.140 data, in which case it 
> might be possible to use
> >      >>>>> a single T.140 data channel to transport data from 
> multiple sources."
> >      >>>> Should also "the T140 data channel data format" be among 
> the options for where to place the source information?
> >      >>> What is the "data format"? Isn't the T140block the data format?
> >      >>
> >      >>     Currently yes, but a more complex format could be 
> defined, e.g. with a
> >      >>     structure containing a source indicator and the 
> T140blocks with some
> >      >>     separator or structure. Of coulse it would be best to 
> have that
> >      >>     structure in place already from the beginning in this 
> draft, so that
> >      >>     there will be no interworking problems when a source 
> address is
> >      >>     introduced. Or at least a specified way to extend the 
> format.
> >      > Yes. But, again, that work would have to be done elsewhere. 
> It is not within the charter of MMUSIC to define media plane formats.
> >      >
> >      > Regards,
> >      >
> >      > Christer
> >      >
> >      >
> >      > [email-masked]
> >      > https://www.ietf.org/mailman/listinfo/mmusic
> >
> >      --

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Aug 2019 08:09:41 +0000

Hi Gunnar,

>I change my mind, I do not think we should try to modify the requirements on the "label" parameter.
>There are too many implementations made to the current specification.

Yes. I also think it would be very difficult to get anything changed in RTCWEB. They just closed the WG, and everyone just want the documents to be published...

>1. For the simple case with a call between two users, opening just one T140 data channel between them,
> the sources are usually regarded to be the caller and the called parties. Some identities can be found in
> the call establishment for presenting the sources to the users.

Yes.

>2. For a more complex case with a call between two users, opening more than one T140 data channel between them,
>some kind of indication will be desired to show what purpose there is for the different T140 data channels. Assume for
>example that it is a foreign language learning session, with one channel for discussion held in one language and another
>channel for writing the original and translation proposals, ( so that the translation proposal stands there clearly on the
>screen while it is discussed in the other channel. The labels could help indicating the difference in use,

>e.g. "mother tongue discussion" and "translation original and result".

Yes.

RFC 4796 defines the SDP ‘content’ attribute, which can be used to provide more information about a media stream. However, you need to define and register actual values with IANA - you cannot use it for an arbitrary string.

>3. A multi-party server S, combining a number of sources into one call to a participant A, with real-time text from and to

>each other participant (B,C,...) communicated in one T140 data channel per participant. Only the server knows how many

>they are, so the server offers a number of T140 data channels in that call. Assigning a label with an identity (B, C,...) of the

>sourcing participant retrieved from the session information for that participant can help the receiving participant (A) to

>indicate the source.

>The server needs to do similar offers of T140 data channels to each participant and can provide some identity for

> each (retrieved from session information) in the label. So, here, use of the label for source seems to make sense.

>If any T140 data channels breaks and reconnects, the same information is used for the reconnect and text can

> continue to be presented under the same source identity.

Just to clarify: what exactly do you mean by the “source”? For the audio/video streams you will have the SSRC. Are you thinking about something similar for the data channel?

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

Yes.

(But such extension is outside the charter of MMUSIC.)

>Summary: The advice to use the label for source is useful, but should be limited to the source for offered T140 data channels. For answered T140 data channels some session information may be used as source.

>The "label" attribute may be used by the offering party to convey a presentable source.

>I hope the reasoning was possible to follow.

Please see my question regarding what you mean by “source”.

Regards,

Christer

Correct.

Regards,

Christer

mmusic mailing list

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 27 Aug 2019 14:09:52 +0200

Hi Christer,

With "source" I in fact mean two things:

1. A unique identification of the source of the T140blocks used to 
separate the received text and present it in a way that is possible to 
read. This can correspond to SSRC or CSRC in RTP.  For the cases 1,2,3 
below, I think the stream ID is suitable for this purpose. For case 4, 
we do not have a solution yet for the WebRTC data channel, but for RTP, 
it is CSRC.

2. A presentable readable identity, that can be used to present some 
information about the sender of the real-time text. Different ways to 
present the text calls for different placement of that information. For 
one column per source, it can be in a column header, for an IRC-style 
real-time text presentation, it can be in a label in front of a received 
text chunk. For cases 1,2,3, the "label" is good for that purpose from 
the offering party, while something from session setup may be used to 
identify the answering part. In RTP, CNAME in RTCP may be a base for 
composing that kind of source info. Again, for case 4, we do not have 
any current solution.

I do not want to leave this topic until we have a solution on the way 
also for case 4.

A question: can we rely on the combining server to have some SDP 
signaling with all participants for each participant entering the 
multi-party call? If so, what?

I think we need two items, similar to CSRC and CNAME. One short and 
unique that can be repeated in each data channel message, and one 
longer, human readable that is sufficient to transmit less often, e.g. 
just when a participant enters the call.

We need to decide if it is sufficient to limit the application to only 
have T140blocks from one source in each T140 data channel message, or if 
we must be able to multiplex between sources in each T140 data channel 
message. If we allow only one source per message, then we may need to 
allow the transmission rate of T140 data messages to increase over what 
is normally used in a one-to-one situation.  How much overhead has a 
T140 data channel message and the exchanges occurring to get it delivered?

Regards

Gunnar

Den 2019-08-27 kl. 10:09, skrev Christer Holmberg:
> Yes. I also think it would be very difficult to get anything changed 
> in RTCWEB. They just closed the WG, and everyone just want the 
> documents to be published...
>
> >some kind of indication will be desired to show what purpose there is 
> for the different T140 data channels. Assume for
> >example that it is a foreign language learning session, with one 
> channel for discussion held in one language and another
> >channel for writing the original and translation proposals, ( so that 
> the translation proposal stands there clearly on the
> RFC 4796 defines the SDP ‘content’ attribute, which can be used to 
> provide more information about a media stream. However, you need to 
> define and register actual values with IANA - you cannot use it for an 
> arbitrary string.
>
> Just to clarify: what exactly do you mean by the “source”? For the 
> audio/video streams you will have the SSRC. Are you thinking about 
> something similar for the data channel?
>
> >Summary: The advice to use the label for source is useful, but should be limited to the source for offered 
> T140 data channels. For answered T140 data channels some session 
> information may be used as source.
>
> >
>
>     > It's probably a good idea to also ask them if they think 'label'
>     is good for indicating source in the first place."
>     >
>     Just to clarify, though: as each data channel will use a unique
>     SCTP port/stream-id, it will be possible to associate each
>     T140block with a data channel.
>
>     >But we also need to consider what happens when a T140 data channel breaks
>     because of network problems and >is then reconnected. Can the
>     stream-id be reused for the reconnection, so that we can continue
>     placing the new >incoming text where it belongs?
>
>     I would need to double-check what the specs say, but if the
>     stream-id change I assume there will a new offer/answer exchange
>     to indicate that.
>
>     > Note that we are not restricting how the problem can be solved
>     in the future. It's a note, and the sentence contains an "e.g.,"
>     in the so we are just giving examples :)
>     >
>     > Regards,
>     >
>     > Christer
>     >
>     >
>     >
>     >
>     >      >>>>> simultaneous T.140 data channels, one for each
>     source. At the time of
>     >      >>>>> RTP media, WebRTC data channels and the T.140
>     protocol do not support the
>     >      >>>>> NOTE: Future extensions to T.140, or to the
>     T140block, might allow
>     >      >>>> Should also "the T140 data channel data format" be
>     among the options for where to place the source information?
>     >      >>     separator or structure. Of coulse it would be best
>     to have that
>     >      >>     structure in place already from the beginning in
>     this draft, so that
>     >      >>     introduced. Or at least a specified way to extend
>     the format.
>     >      > Yes. But, again, that work would have to be done
>     elsewhere. It is not within the charter of MMUSIC to define media
>     plane formats.
>     >      >
>     >      > Regards,
>     >      >
>     >      > Christer
>     >      >
>     >      >
>     >      > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     >      +46 708 204 288
>     >
>     >
>     >
>     [email-masked] <mailto:[email-masked]>
>     +46 708 204 288
>
>
>
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Aug 2019 12:29:02 +0000

Hi,

> 1. A unique identification of the source of the T140blocks used to separate the received text and present it in a way that is possible to read. This can correspond to SSRC or CSRC in RTP. 
> For the cases 1,2,3 below, I think the stream ID is suitable for this purpose. For case 4, we do not have a solution yet for the WebRTC data channel, but for RTP, it is CSRC.
> 2. A presentable readable identity, that can be used to present some information about the sender of the real-time text. Different ways to present the text calls for different placement
> of that information. For one column per source, it can be in a column header, for an IRC-style real-time text presentation, it can be in a label in front of a received text chunk. For cases 
> 1,2,3, the "label" is good for that purpose from the offering party, while something from session setup may be used to identify the answering part. In RTP, CNAME in RTCP may be a 
> base for composing that kind of source info. Again, for case 4, we do not have any current solution. 
> I do not want to leave this topic until we have a solution on the way also for case 4. 
>
> But, in any case I don't want to hold up the draft while waiting for a solution for case 4. > A question: can we rely on the combining server to have some SDP signaling with all participants for each participant entering the multi-party call? If so, what?
> I think we need two items, similar to CSRC and CNAME. One short and unique that can be repeated in each data channel message, and one longer, human readable
> that is sufficient to transmit less often, e.g. just when a participant enters the call.
> We need to decide if it is sufficient to limit the application to only have T140blocks from one source in each T140 data channel message, or if we must be able to
> multiplex between sources in each T140 data channel message. If we allow only one source per message, 

We drafted a note saying that one will need to have separate data channels until a solution for using a single data channel for multiple sources is available.

I'd be interested in discussing and contributing to a solution for case 4, but I don't want to hold up the t140-data-channel draft for that. And, again, I don't think MMUSIC is necessarily the correct place to discuss that, For example,  a T140block extension should be discussed in the WG that defined the T140block, in my opinion.

Regards,

Christer

 

Yes.

Yes.

 

Yes.

 
 
Regards,
 
Christer

 

 

Correct.

 

 
 
Regards,
 
Christer

Den 2019-08-26 kl. 11:15, skrev Christer Holmberg:
>      >>>>> implementations (both clients and servers) need to support multiple
>      >>>>> simultaneous T.140 data channels, one for each source. At the time of
>      >>>>> writing this document, this is true even in scenarios where each participants
>      >>>>> communicate via a centralized conference server. The reason is that, unlike
>      >>>>> RTP media, WebRTC data channels and the T.140 protocol do not support the
>      >>>>> NOTE: Future extensions to T.140, or to the T140block, might allow
>      >>>>> indicating the source of T.140 data, in which case it might be possible to use
>      >>>>> a single T.140 data channel to transport data from multiple sources."
>      >>>> Should also "the T140 data channel data format" be among the options for where to place the source information?
>      >>     Currently yes, but a more complex format could be defined, e.g. with a
>      >>     structure containing a source indicator and the T140blocks with some
>      >>     separator or structure. Of coulse it would be best to have that
>      >>     structure in place already from the beginning in this draft, so that
>      >>     there will be no interworking problems when a source address is
>      >>     introduced. Or at least a specified way to extend the format.
>      > Yes. But, again, that work would have to be done elsewhere. It is not within the charter of MMUSIC to define media plane formats.
>      >
>      > Regards,
>      >
>      > Christer
>      >
>      >
>      > mailto:[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Aug 2019 14:39:49 -0400

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

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 27 Aug 2019 20:44:21 +0200

Hi,

Most functionality needed for multi-party handling of RTT in a SIP and 
RTP environment is specified in expired 
https://tools.ietf.org/html/draft-hellstrom-text-conference-04

There are alternatives based on CSRC / CNAME versus new T.140 extensions 
specified for the source identification we have been discussing.

A central need is a negotiation where the parties specify what they 
support so that the session can be performed in a way that the parties 
can manage.

All aspects are specified together in this draft, both SIP / SDP 
signaling, RTP / RTCP fields and T.140 extensions.

What is needed now is rework of this draft for the T140 data channel 
case and distribution of the changes or new specifications needed in the 
corresponding groups.

draft-holmberg-mmusic-t140-usage-data-channel  or an update of it would 
need to describe the negotiation of the method for source identification 
to use and its use.

I intend to draft a very rough first draft of what can be needed.

Regards

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 27 Aug 2019 20:57:07 +0200

Hi Paul,

Please see inline,

Den 2019-08-27 kl. 20:39, skrev Paul Kyzivat:
>> 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.
>

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

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Aug 2019 19:59:15 +0000

Hi,

> 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

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

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 27 Aug 2019 23:15:33 +0200

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Aug 2019 21:40:14 +0000

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. 
>  Purpose: Identify coding of extensions to the protocol, so that the extensions can be introduced
>  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
>  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
>  If no trailing ST is received after the maximum length of the parameter string, the protocol reverts to
> 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
>
>   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].
>   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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 10:49:32 -0400

> What do you think about that case?

Initially each user would only have one channel. Then he gets another 
one added each time there is a new speaker who hasn't spoken before. I 
don't know if there would be formal floor control, or if everyone would 
always be allowed to talk. Formal floor control would provide an early 
hint to establish the new channels, possibly preventing delays. But 
adding a channel isn't an expensive operation and delaying messages 
until it is done shouldn't be a problem.

But is this a realistic issue? Do RTT conferences with hundreds of 
speakers happen in practice?

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 28 Aug 2019 20:26:23 +0200

Hi Paul, see comment at the end,

Den 2019-08-28 kl. 16:49, skrev Paul Kyzivat:
>>>> T140block sent to A. We currently have no way specified for that. 
>>>> An extension of T.140 could do it.
>>>
>>> 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.
>>>
>> 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 of T140 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.
>>
> don't know if there would be formal floor control, or if everyone 
> would always be allowed to talk. Formal floor control would provide an 
> early hint to establish the new channels, possibly preventing delays. 
> But adding a channel isn't an expensive operation and delaying 
> messages until it is done shouldn't be a problem.
>

It is realistic to the same degree as use of video and audio in 
multi-party multi-media conferences.

It is not realistic to let hundreds of participants talk simultaneously, 
but one or a very low number. It is realistic to let one at a time have 
the floor and speak, sending the audio to all the others, and have the 
opportunity to hand over the floor to someone else with a lose or strict 
protocol.

There is very little use for transmitting live video from hundreds of 
participants simultaneously, but it is realistic to show a low number of 
users and be prepared to switch who are seen.

Similarly it is not realistic to let hundreds of participants present 
new RTT simultaneously, but one or a very low number. It is realistic to 
let a few at a time transmit, sending the RTT to all the others. Anyone 
should have the opportunity to transmit RTT, controlled by either no 
protocol or a lose or a strict protocol.

RTT is sadly often characterized as media for accessibility and thereby 
expected to be used only in special cases. This is wrong from two points 
of view:

1: If used for accessibility, in cases when one or some users have no or 
little use of audio or video for language communication because of a 
disability, then it is very important that all other participants can 
use the same media, so that communication can go directly to or from the 
one(s) who need RTT. This is the whole idea of accessibility, that users 
are not forced to limited technology corners, but are able to 
participate anywhere with the same technology as others and have full 
and equal participation. (sometimes a translating service between 
different modalities are still needed so that everybody are enabled to 
use the modality they prefer)

2. In any multimedia conference there appears reasons to communicate 
something in text. The three real-time media: audio, video and RTT are 
needed together for alternating or simultaneous use. Talk, show and 
write for a complete and efficient communication. In that scenario, text 
messaging is a slow tool, causing delays and risk for losing the 
interest from  viewers. When anyone starts texting RTT, it is possible 
to start following the thoughts as they are expressed in text 
immediately from start, while for messaging the typing user needs to 
complete the message and risking to enter the message far too late to be 
valid in the discussion.

3. Automatic subtitling by speech-to-text services and even language 
translation before presentation would be useless without a form of RTT. 
It is now realistic to use such services to enhance multimedia 
conferences and make the contents available for both people with other 
languages, people in noisy areas and for deaf or hard-of-hearing users. 
This is a rapidly increasing use. Also for this case it is realistic 
only with a few actively transmitting users, while the result can be if 
interest to distribute to many.

This said, I anyway agree that the usage that will develop most rapidly 
will likely be for meetings with not more than five participants having 
audio, video and RTT available and most commonly only three taking turns 
on sending RTT. Some of these calls will be in emergency services and 
interpreting (or relay) services, while there is also a need for 
user-to-user conferences.

I would also like to know which MCU model is most realistic for these 
applications. Is it the one with separate text channels per active 
source opened and closed when there is a need, or is it the single text 
channel with in-line identification of the source for each new data 
channel message?

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Aug 2019 18:34:32 +0000

Hi,

I think it's not worth trying to predict what type of MCU will be most common - unless someone has some data that really can be used to justify a specific type.

Also, whatever the solution is, I assume you also want it to work in interworking cases, where the MCU might be using RTP-based text (RFC 4103)? From that perspective a T.140 extension would be the best solution, because it would work both for T140 data channels and RTP streams without having to touch the T140 data.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Gunnar Hellström
Lähetetty: keskiviikko 28. elokuuta 2019 21.26
Vastaanottaja: Paul Kyzivat <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

> speakers happen in practice?

It is realistic to the same degree as use of video and audio in multi-party multi-media conferences.

It is not realistic to let hundreds of participants talk simultaneously, but one or a very low number. It is realistic to let one at a time have the floor and speak, sending the audio to all the others, and have the opportunity to hand over the floor to someone else with a lose or strict protocol.

There is very little use for transmitting live video from hundreds of participants simultaneously, but it is realistic to show a low number of users and be prepared to switch who are seen.

Similarly it is not realistic to let hundreds of participants present new RTT simultaneously, but one or a very low number. It is realistic to let a few at a time transmit, sending the RTT to all the others. Anyone should have the opportunity to transmit RTT, controlled by either no protocol or a lose or a strict protocol.

RTT is sadly often characterized as media for accessibility and thereby expected to be used only in special cases. This is wrong from two points of view:

1: If used for accessibility, in cases when one or some users have no or little use of audio or video for language communication because of a disability, then it is very important that all other participants can use the same media, so that communication can go directly to or from the
one(s) who need RTT. This is the whole idea of accessibility, that users are not forced to limited technology corners, but are able to participate anywhere with the same technology as others and have full and equal participation. (sometimes a translating service between different modalities are still needed so that everybody are enabled to use the modality they prefer)

2. In any multimedia conference there appears reasons to communicate something in text. The three real-time media: audio, video and RTT are needed together for alternating or simultaneous use. Talk, show and write for a complete and efficient communication. In that scenario, text messaging is a slow tool, causing delays and risk for losing the interest from  viewers. When anyone starts texting RTT, it is possible to start following the thoughts as they are expressed in text immediately from start, while for messaging the typing user needs to complete the message and risking to enter the message far too late to be valid in the discussion.

3. Automatic subtitling by speech-to-text services and even language translation before presentation would be useless without a form of RTT. 
It is now realistic to use such services to enhance multimedia conferences and make the contents available for both people with other languages, people in noisy areas and for deaf or hard-of-hearing users. 
This is a rapidly increasing use. Also for this case it is realistic only with a few actively transmitting users, while the result can be if interest to distribute to many.

This said, I anyway agree that the usage that will develop most rapidly will likely be for meetings with not more than five participants having audio, video and RTT available and most commonly only three taking turns on sending RTT. Some of these calls will be in emergency services and interpreting (or relay) services, while there is also a need for user-to-user conferences.

I would also like to know which MCU model is most realistic for these applications. Is it the one with separate text channels per active source opened and closed when there is a need, or is it the single text channel with in-line identification of the source for each new data channel message?

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Aug 2019 18:35:58 +0000

>Also, whatever the solution is, I assume you also want it to work in interworking cases, where the MCU might be using 
>RTP-based text (RFC 4103)? From that perspective a T.140 extension would be the best solution, because it would work 
>both for T140 data channels and RTP streams without having to touch the T140 data.

...and here I am talking about the case where you would use a single data channel for multiple participants.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Gunnar Hellström
Lähetetty: keskiviikko 28. elokuuta 2019 21.26
Vastaanottaja: Paul Kyzivat <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Aug 2019 18:37:54 +0000

...and, a T140 extension would work both for a single data channel and multiple data channel, because the receiver will only need to look at the T140 data, and not care about what data channel it was received on.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Christer Holmberg
Lähetetty: keskiviikko 28. elokuuta 2019 21.36
Vastaanottaja: Gunnar Hellström <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

>Also, whatever the solution is, I assume you also want it to work in 
>interworking cases, where the MCU might be using RTP-based text (RFC 
>4103)? From that perspective a T.140 extension would be the best solution, because it would work both for T140 data channels and RTP streams without having to touch the T140 data.

....and here I am talking about the case where you would use a single data channel for multiple participants.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Gunnar Hellström
Lähetetty: keskiviikko 28. elokuuta 2019 21.26
Vastaanottaja: Paul Kyzivat <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Regards

Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 14:54:03 -0400

ISTM that this discussion is getting pretty far afield from the proper 
scope of the draft. I think much of what is being discussed here belongs 
in a different draft, probably in a different wg, like AVT.

	Thanks,
	Paul

On 8/28/19 2:37 PM, Christer Holmberg wrote:
> ....and, a T140 extension would work both for a single data channel and multiple data channel, because the receiver will only need to look at the T140 data, and not care about what data channel it was received on.
> 
> Regards,
> 
> Christer
> 
> .....and here I am talking about the case where you would use a single data channel for multiple participants.
> 
> Regards,
> 
> Christer
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 14:57:04 -0400

As I just replied to Christer, I think this discussion ought to pertain 
to a different document that we don't have yet.

Meanwhile, having a channel per stream is hopefully sufficient while 
exploring these other things.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Aug 2019 18:58:17 +0000

Hi,

>ISTM that this discussion is getting pretty far afield from the proper scope of the draft. 
>I think much of what is being discussed here belongs in a different draft, probably in a 
>different wg, like AVT.

Using a single channel for multiple users *IS* outside the scope of the draft. There will also be an explicit note about that in the next version of the draft. Gunnar still wanted to continue the discussion about using a single channel, but I guess we should have changed the subject :)

I have also indicated that data plane extensions should be discussed elsewhere, e.g., in AVT. T.140 extensions should probably be taken to ITU-T.

Regards,

Christer

	Thanks,
	Paul

On 8/28/19 2:37 PM, Christer Holmberg wrote:
> Vastaanottaja: Gunnar Hellström <[email-masked]>; Paul 
> Kyzivat <[email-masked]>; [email-masked]
>>> 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 of T140 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.
>>>
>> one added each time there is a new speaker who hasn't spoken before. 
>> I don't know if there would be formal floor control, or if everyone 
>> would always be allowed to talk. Formal floor control would provide 
>> an early hint to establish the new channels, possibly preventing delays.
> 1: If used for accessibility, in cases when one or some users have no 
> or little use of audio or video for language communication because of 
> a disability, then it is very important that all other participants 
> can use the same media, so that communication can go directly to or 
> from the
> one(s) who need RTT. This is the whole idea of accessibility, that 
> users are not forced to limited technology corners, but are able to

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Aug 2019 19:01:44 +0000

Hi,

>As I just replied to Christer, I think this discussion ought to pertain to a different document that we don't have yet.
>
>Meanwhile, having a channel per stream is hopefully sufficient while exploring these other things.

The pull request contains the following new text:

"If an implementation needs to support multi-party scenarios, implementations need
to support multiple simultaneous T.140 data channels, one for each remote party. At
the time of writing this document, this is true even in scenarios where each participants
communicate via a centralized conference server. The reason is that, unlike RTP media,
WebRTC data channels and the T.140 protocol do not support the indication of the source
of T.140 data. The SDP dcmap attribute label attribute parameter (<xref target="sec.sdp.dcmap"/>)
can be used to provide additional information about each T.140 data channel, and help
implementations to distinguish between them."

Regards,

Christer

	Thanks,
	Paul

On 8/28/19 2:26 PM, Gunnar Hellström wrote:
> It is not realistic to let hundreds of participants talk 
> simultaneously, but one or a very low number. It is realistic to let 
> one at a time have the floor and speak, sending the audio to all the 
> others, and have the opportunity to hand over the floor to someone 
> else with a lose or strict protocol.
> 
> participants simultaneously, but it is realistic to show a low number 
> of users and be prepared to switch who are seen.
> 
> new RTT simultaneously, but one or a very low number. It is realistic 
> to let a few at a time transmit, sending the RTT to all the others. 
> Anyone should have the opportunity to transmit RTT, controlled by 
> either no protocol or a lose or a strict protocol.
> 
> RTT is sadly often characterized as media for accessibility and 
> thereby expected to be used only in special cases. This is wrong from 
> two points of view:
> 
> write for a complete and efficient communication. In that scenario, 
> text messaging is a slow tool, causing delays and risk for losing the 
> complete the message and risking to enter the message far too late to 
> be valid in the discussion.
> 
> only with a few actively transmitting users, while the result can be 
> if interest to distribute to many.
> 
> This said, I anyway agree that the usage that will develop most 
> rapidly will likely be for meetings with not more than five 
> participants having audio, video and RTT available and most commonly 
> only three taking turns on sending RTT. Some of these calls will be in 
> emergency services and interpreting (or relay) services, while there 
> is also a need for user-to-user conferences.
> 
> source opened and closed when there is a need, or is it the single 
> text channel with in-line identification of the source for each new 
> data channel message?
> 
> 
> Regards
> 
> Gunnar
> 
>>
>>
>>     Thanks,
>>     Paul
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 28 Aug 2019 21:47:02 +0200

>> I think much of what is being discussed here belongs in a different draft, probably in a

We needed to have this discussion here in order to understand how the 
limitations of the Data Channels compared to RTP (the lack of SSRC,CSRC, 
CNAME and NAME) influences what we can do for multi-party cases.

Now we have seen and understood that in a few situations we can 
compensate these shortcomings by use of session information, the label 
and the stream ID.  For the case of a single data channel carrying 
T140blocks from many sources, we have a solution for RTP, but not for 
the T.140 data channel.

In order to solve that, we would need an SDP attribute for indicating 
capability for a solution, and then a coding in the data channel 
messages for the case when the solution is used.

Both the attribute and the message coding could be part of the work with 
draft-holmberg-mmusic-t140-usage-data-channel. The need appeared because 
of the limitation in the data channel, and the requirement is specificed 
in the webrtc data channel specification.

However, we have not specified the attribute yet for negotiating 
multi-party functionality in the RTP case. I agree that it would be wise 
to use the same attribute.  Should that work be done in AVT then?

And the coding could be a T.140 extension. Or we could say that for RTP, 
the first CSRC in the packet is the source, and for the T140 data 
channel, the data channel message is a structure with two parts, the 
source (in a form similar to the stream ID) and the T140blocks. (are 
there any habits established for providing structures as payload in data 
channel messages?
I assume that this kind of limited work on the data format can be 
included in the current work in mmusic.

If we do it with a T.140 extension, we need to decide if we require all 
T140 data channel messages must begin with a source indicator, and if 
T140blocks only from one source is allowed in each T140 data channel 
message or if we can switch source within the message and the receiving 
presentation need to scan for new source indicators and let that 
influence the presentation (or further transmission).

Summary, there are things in this that belongs to mmusic or can be done 
here, but depending on some decisions work in other groups or bodies may 
also be needed.

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Aug 2019 20:22:43 +0000

Hi,

>>> I think much of what is being discussed here belongs in a different 
>>> draft, probably in a different wg, like AVT.
>>
> We needed to have this discussion here in order to understand how the limitations of the Data Channels
> compared to RTP (the lack of SSRC,CSRC, CNAME and NAME) influences what we can do for multi-party cases.
>
> Now we have seen and understood that in a few situations we can compensate these shortcomings by use of
> session information, the label and the stream ID.  For the case of a single data channel carrying T140blocks from
> many sources, we have a solution for RTP, but not for the T.140 data channel.
>
> In order to solve that, we would need an SDP attribute for indicating capability for a solution, and then a coding
> in the data channel messages for the case when the solution is used.
>
> Both the attribute and the message coding could be part of the work with draft-holmberg-mmusic-t140-usage-data-channel. 
> The need appeared because of the limitation in the data channel, and the requirement is specificed in the webrtc data channel specification.

I don't think message coding is part of the work of the draft - or even MMUSIC.

> However, we have not specified the attribute yet for negotiating multi-party functionality in the RTP case.
> I agree that it would be wise to use the same attribute.  Should that work be done in AVT then?

If we need an attribute for some solution, we can for sure define the attribute in MMUSIC.

But, we can't define an attribute for a solution that doesn't exist yet :)

> And the coding could be a T.140 extension. Or we could say that for RTP, the first CSRC in the packet is the 
> source, and for the T140 data channel, the data channel message is a structure with two parts, the source
> (in a form similar to the stream ID) and the T140blocks. (are there any habits established for providing
> structures as payload in data channel messages?
> I assume that this kind of limited work on the data format can be included in the current work in mmusic.
>
> If we do it with a T.140 extension, we need to decide if we require all T140 data channel messages must begin with a source indicator, 
> and if T140blocks only from one source is allowed in each T140 data channel message or if we can switch source within the message and
> the receiving presentation need to scan for new source indicators and let that influence the presentation (or further transmission).

I think that discussion needs to be taken to AVT. MMUSIC is more or less about SDP, and what you are talking about has nothing to do with SDP, and you won't necessarily even find the people with the needed expertise in MMUSIC.

> Summary, there are things in this that belongs to mmusic or can be done here, but depending on some decisions work
> in other groups or bodies may also be needed.

My suggestion for the next step would be that you send an e-mail to AVT, and describe the issue, and ask:

1) Is using a single data channel for multiple remote users an issue to begin with (basically Paul's question), or can we assume that there will always be a separate data channel for each remote participant
2) If it is an issue, and a single data channel could be used for multiple remote participants, what would be the best way to solve it

Regards,

Christer

> Using a single channel for multiple users *IS* outside the scope of 
> the draft. There will also be an explicit note about that in the next 
> version of the draft. Gunnar still wanted to continue the discussion 
> about using a single channel, but I guess we should have changed the 
> subject :)
>
>>>>> 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.
>>>>>
>>> Initially each user would only have one channel. Then he gets 
>>> another one added each time there is a new speaker who hasn't spoken before.
>> different modalities are still needed so that everybody are enabled 
>> to use the modality they prefer)
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Aug 2019 10:13:09 +0200

Hi,

Yesterday, I reviewed and commented in GitHub a good set of modification 
proposals from Christer.

I was a bit vague in a few of them, so I want to straighten up and be 
more clear about what I said in a few comments. I also have some further 
thoughts.

1. Keep-alive.

In the gateway considerations section, there were a few sentences about 
keep-alive. It was stated that RFC 4103 does not specify any need for 
keep-alive. That is true, but because RFC 4103 specifies that 
transmission occurs only when there is text to transmit, there will be a 
need for keep-alive traffic in many network configurations. On the data 
channel side, this is implied in the WebRTC data channel, but on the RTP 
side, the need for keep-alive must be considered. This is mentioned in 
RFC 6263, where RTCP multiplexing is recommended as the preferred 
option. Most current RFC 4103 implementations however send keep-alive by 
sending the Unicode BOM character at suitable intervals, and these 
should be extracted and deleted by a gateway on the way from RTP to the 
data channel.

Even if we have said that we cannot have all gateway considerations 
documented here, I suggest that a couple of words about RFC6263 
mentioning the possible need for keep-alive on the RTP side are inserted.

2. Sendonly, recvonly, etc

On the RTP side, there is a possibility to express directions in SDP by 
the sendonly etc. attributes. I think I have seen them used in RFC 4103 
implementations.

Will these attributes automatically be possible to use in the T.140 data 
channel? I guess not, because it is not really said that the T.140 data 
channel tries to be a replica of the RFC 4103 RTP transport with all its 
possible attributes. Some of the attributes enabled for RFC 4103 may be 
of application interest for the T.140 data channel application, while 
others are of little or no interest or irrelevant. I am afraid that we 
need to go through possible attributes and mention the relevant ones in 
a general section on attributes, and then IANA-register the use. (this 
relates also to the current discussion in another thread about IANA 
registration of attributes for data channels).  The msrp-data-channel 
draft has a section on sendonly etc. I suggest that we also include one.

Regards

Gunnar

-

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 08:37:09 +0000

Hi Gunnar,
    
>    mentioning the possible need for keep-alive on the RTP side are inserted.
  
The text in -01 says that the gateway may have to extract keep-alives from, and MAY add keep-alives to, the RTP stream.

We can for sure reference mechanisms normally used to implement 4103 keep-alives. 

But, if you want to define *generic* recommendations/guidance regarding keep-alives on 4103 streams I think that shall be done in an update to 4103. There is nothing data channel gateway specific about that.

---
  
>    draft has a section on sendonly etc. I suggest that we also include one.
  
The data channel itself is always bi-directional. Now, if you want to allow usage of direction attributes for T.140 data I guess we would have to define usage of them inside a 'dcsa' attribute.

Regards,

Christer

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 29 Aug 2019 09:03:13 +0000

Hi,
I read most of the thread.

My view is that is we are talking about WEBRTC, the multiparty and user information will be part of the communication between the application server and the browser and the application server is doing whatever mixing or forwarding that it needs.
I can see that there must be some way for the application server to know what is each t.140 data channel   if there is more than one , some distinction is the language attribute. If you want more maybe as Christer suggested use the “content” attribute whose objective is to provide information about stream.

Roni

From: mmusic [mailto:[email-masked]] On Behalf Of Gunnar Hellström
Sent: Sunday, August 25, 2019 9:49 AM
To: Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Hi Christer,

No, T.140 has no source indicator of its own, it relies on the transport to indicate the source for each T140block. In RTP, this can be done by an RTP mixer making one stream from multiple sources including CSRC for the sources of the primary text and for the redundant generations of text in each packet. On the T140 data channel side, I do not know any corresponding way to indicate different sources in the same data channel.

The solutions I see are: 1) create one T140 channel per source/destination pair. or 2) Introduce a source indicator in the data format for the T140 data channel, either one per STCP message requiring all T140blocks in the message being from one source only, or inline between series of T140blocks from different sources.

This is because the real-time text from multiple sources simultaneously need to be presented with some separation, so that the text gets readable at least sentence-wise from each source. The T.140 Appendix 1 shows two ways to do this, one column-oriented, and one sentence-oriented with a label per start of sentence. You can read more about the topic in draft-hellstrom-text-conference-04.txt<https://www.ietf.org/archive/id/draft-hellstrom-text-conference-04.txt>

In order to enable the reader to follow the flow of a multi-party text conversation, it is a good habit to present older text placed higher in the text area and newer text placed lower. (This is valid for both when you present text in one column per source and if you combine all sources in one (IRC-style) column).

It is also a good habit to present text from the same source readable together, e.g. sentence by sentence, (and not break the text just because a text item from another source was received during the time the sentence was created).

These two requirements are in conflict. A true time-related presentation would fragment simultaneous text from different sources into unreadability, and presenting all text from each source in one chunk each would give no clue about the flow of the discussion.

Yes, this is a good statement for the case without the server, or can be modified for a server that maintains a channel per source. But which solution do you prefer if we allow a mixing server?

/Gunnar

-

-

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Aug 2019 11:07:31 +0200

Hi Christer,

> But, if you want to define *generic* recommendations/guidance regarding keep-alives on 4103 streams I think that shall be done in an update to 4103. There is nothing data channel gateway specific a…
Yes, -01 does not say anymore that RFC 4103 does not specify keep-alive. 
So, by that, mentioning that stripping and inserting it might be needed 
on the RTP side as done in -01 is sufficient. Fine.
> The data channel itself is always bi-directional. Now, if you want to allow usage of direction attributes for T.140 data I guess we would have to define usage of them inside a 'dcsa' attribute.

If it is common to use these attributes for muting etc in conferencing 
scenarios for other media, I think they should be mentioned and 
registered. The action on the T.140 data channel needs then be on 
application level. That provides an opportunity to indicate in the user 
interface that what the user types is not transmitted in case of muted. 
If other mechanisms are usually used for other media, we could ignore 
these attributes.

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 09:07:49 +0000

Hi Roni,

>My view is that is we are talking about WEBRTC, the multiparty and user information will be part of the communication between the application >server and the browser and the application server is doing whatever mixing or forwarding that it needs.
>I can see that there must be some way for the application server to know what is each t.140 data channel   if there is more than one , some >distinction is the language attribute. If you want more maybe as Christer suggested use the “content” attribute whose objective is to provide >information about stream.

The main issue is if you want to use a *single* data channel for T.140 traffic from multiple remote participants. In that case you need to be able to indicate the source of the T.140 data, but unlike RTP you don’t have SSRC etc for doing that.

Regards,

Christer

Hi Christer,

/Gunnar

-

-

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 29 Aug 2019 09:23:38 +0000

HI Christer,
I you want to multiplex but know who is contributing the data you need some identifier as part of the T.140 data packet similar to SSRC in the RTP header. It is not even similar to CSRC since CSRC is more about providing about the content of this specific RTP packet but in this case each t.140 packet is coming from a single source so one identifier is needed.

Roni

From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, August 29, 2019 12:08 PM
To: Roni Even (A); Gunnar Hellström; [email-masked]
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Hi Roni,

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Gunnar Hellström
Sent: Sunday, August 25, 2019 9:49 AM
To: Christer Holmberg; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Hi Christer,

/Gunnar

-

-

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 09:27:58 +0000

Hi,

> I you want to multiplex but know who is contributing the data you need some identifier as part of the T.140 data packet
> similar to SSRC in the RTP header.

Exactly, and that is what have been discussed :)

> It is not even similar to CSRC since CSRC is more about providing about the content of this specific RTP packet but in this 
> case each t.140 packet is coming from a single source so one identifier is needed.

Your comment above shows why I have suggested to take the discussion to AVT: there you will find people (like yourself) that know more about that kind of stuff :)

Regards,

Christer

 
Hi Roni,

 
Regards,
 
Christer 

From: mmusic [mailto:[email-masked]] On Behalf Of Gunnar Hellström
Sent: Sunday, August 25, 2019 9:49 AM
To: Christer Holmberg; mailto:[email-masked]
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
 
Hi Christer,

 

Also, in some cases all communication will go via a central server, so there will only be one T.140 data channel towards each participant.
No, T.140 has no source indicator of its own, it relies on the transport to indicate the source for each T140block. In RTP, this can be done by an RTP mixer making one stream from multiple sources including CSRC for the sources of the primary text and for the redundant generations of text in each packet. On the T140 data channel side, I do not know any corresponding way to indicate different sources in the same data channel. 
The solutions I see are: 1) create one T140 channel per source/destination pair. or 2) Introduce a source indicator in the data format for the T140 data channel, either one per STCP message requiring all T140blocks in the message being from one source only, or inline between series of T140blocks from different sources.  
This is because the real-time text from multiple sources simultaneously need to be presented with some separation, so that the text gets readable at least sentence-wise from each source. The T.140 Appendix 1 shows two ways to do this, one column-oriented, and one sentence-oriented with a label per start of sentence. You can read more about the topic in https://www.ietf.org/archive/id/draft-hellstrom-text-conference-04.txt

 

 

/Gunnar
 
-
-

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 29 Aug 2019 09:36:30 +0000

inline

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, August 29, 2019 12:28 PM
To: Roni Even (A); Gunnar Hellström; [email-masked]
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Hi,

> I you want to multiplex but know who is contributing the data you need 
> some identifier as part of the T.140 data packet similar to SSRC in the RTP header.

> It is not even similar to CSRC since CSRC is more about providing 
> about the content of this specific RTP packet but in this case each t.140 packet is coming from a single source so one identifier is needed.

RE: This is not AVT and not MMUSIC since it is some encapsulation for T.140 which is not RTP. This is a topic for dispatch since it may be a single draft that needs a home

Regards,

Christer

 
Hi Roni,

 
Regards,
 
Christer 

Hi Christer,

 
 
Implementations should be prepared to accept establishment and use of multiple T140 data channels in order to support multi-party sessions with real-time text. A number of scenarios are available for how multi-party sessions can be supported in the WebRTC environment. 
Implementations may select any suitable scenario.
I don't think we need the two last sentences.
 
Also, in some cases all communication will go via a central server, so there will only be one T.140 data channel towards each participant.
No, T.140 has no source indicator of its own, it relies on the transport to indicate the source for each T140block. In RTP, this can be done by an RTP mixer making one stream from multiple sources including CSRC for the sources of the primary text and for the redundant generations of text in each packet. On the T140 data channel side, I do not know any corresponding way to indicate different sources in the same data channel. 
The solutions I see are: 1) create one T140 channel per source/destination pair. or 2) Introduce a source indicator in the data format for the T140 data channel, either one per STCP message requiring all T140blocks in the message being from one source only, or inline between series of T140blocks from different sources. This is because the real-time text from multiple sources simultaneously need to be presented with some separation, so that the text gets readable at least sentence-wise from each source. The T.140 Appendix 1 shows two ways to do this, one column-oriented, and one sentence-oriented with a label per start of sentence. You can read more about the topic in https://www.ietf.org/archive/id/draft-hellstrom-text-conference-04.txt

 

 

/Gunnar
 
-
-

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 09:50:30 +0000

Hi,

>>> about the content of this specific RTP packet but in this case each t.140 packet is 
>>> coming from a single source so one identifier is needed.
>>    
>> Your comment above shows why I have suggested to take the discussion to AVT: there you will find 
>>  people (like yourself) that know more about that kind of stuff :)
>    
>  RE: This is not AVT and not MMUSIC since it is some encapsulation for T.140 which is not RTP. 
> This is a topic for dispatch since it may be a single draft that needs a home

We are using the RFC 4103 T140block also on the data channel, so *IF* the solution would be an update to that, wouldn't it belong to AVT?

*IF* the solution is an update to T.140, I guess that should be done in ITU-T?

Having said that, before going into solutions there should be *A* venue to discuss the problem. 

Regards,

Christer

     
    Hi Roni,

     
    Regards,
     
    Christer 

    Hi Christer,

     

     

     

     
     
    /Gunnar
     
    -
    -

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Aug 2019 12:50:39 +0200

Hi,

We need to remember also Paul's question, if we really need a 
multi-party case with a central server combining real-time text from 
many sources in one data channel and have source indication on every 
T.140 element so that the receiving client can make its own presentation 
layout of the real-time text conference.

Maybe we can assume that for the case that the receiving client want to 
make its own layout, the case with one T.140 data channel per active 
user is realistic and sufficient.

The case with the central server combining a number of real-time text 
sources into one T.140 data channel could be reserved for the case when 
a T.140 mixer dictates layout, and places labels in IRC style in front 
of text from the participants and makes the best of trying to present 
real-time text in that way. It will not be nice, but still possible with 
some limitations. It is similar to a video mixer dictating the layout of 
a number of participants in one combined view, and to audio mixing, 
allowing audio from a number of participants be heard in the same 
channel with no possibility for the receiving user to influence mixing. 
Maybe it is just fair to have that kind of fixed mixing for real-time 
text when the other media have it.

I have always had a view that it was more important to separate the 
sources for real-time text and let the receiving party do its own layout 
than it would be for video and audio participants to do such separation 
on video and audio. But I might be wrong.

See also inline

>>>> coming from a single source so one identifier is needed.
If it was from a combining server on the RTP side, I think it would be 
CSRC. The SSRC would then point at the server.
> *IF* the solution is an update to T.140, I guess that should be done in ITU-T?

T140blocks are just a number of complete T.140 code elements. And it is 
possible to define new such code elements.

So, even if RFC 4103 defined the term T140block, it is in ITU-T that 
additions to it should be defined.

If instead we specify that the T.140 data channel  shall carry a source 
and a T.140block in each T.140 data channel message, then it is a matter 
for mmusic and the draft we discuss here (or AVT or the closed RTCWEB if 
it seems complex) to specify that source element and the structure of 
the T.140 data channel message contents.

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2019 10:56:33 +0000

Hi,
    
>    user is realistic and sufficient.
  
We could make that assumption for now. Then, if the market later asks for something else, we'll start working on it.

The first step is for people to start using data channels for T.140 to begin with :)

Regards,

Christer

    

    
    Regards
    
    Gunnar

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 29 Aug 2019 11:03:07 +0000

Hi,
Consider the case that there is one T.140 data channel from the mixer to each participant and the mixer sends one of the incoming T.140 data packets to all members and switch (based on its logic like voice activated  ) so how does the receiver know who was the source. Even if the switch was controlled by the UI for switching still there will be a timing issue to know when the source was actually switched  (in RTP you have ssrc and csrc for this) mostly since you require for the text to have the identity of the source.

Roni

-----Original Message-----
From: Gunnar Hellström [mailto:[email-masked]] 
Sent: Thursday, August 29, 2019 1:51 PM
To: Christer Holmberg; Roni Even (A); [email-masked]
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Hi,

We need to remember also Paul's question, if we really need a multi-party case with a central server combining real-time text from many sources in one data channel and have source indication on every
T.140 element so that the receiving client can make its own presentation layout of the real-time text conference.

Maybe we can assume that for the case that the receiving client want to make its own layout, the case with one T.140 data channel per active user is realistic and sufficient.

The case with the central server combining a number of real-time text sources into one T.140 data channel could be reserved for the case when a T.140 mixer dictates layout, and places labels in IRC style in front of text from the participants and makes the best of trying to present real-time text in that way. It will not be nice, but still possible with some limitations. It is similar to a video mixer dictating the layout of a number of participants in one combined view, and to audio mixing, allowing audio from a number of participants be heard in the same channel with no possibility for the receiving user to influence mixing. 
Maybe it is just fair to have that kind of fixed mixing for real-time text when the other media have it.

I have always had a view that it was more important to separate the sources for real-time text and let the receiving party do its own layout than it would be for video and audio participants to do such separation on video and audio. But I might be wrong.

See also inline

Den 2019-08-29 kl. 11:50, skrev Christer Holmberg:
> Hi,
>
>>>> I you want to multiplex but know who is contributing the data you 
>>>> need some identifier as part of the T.140 data packet similar to SSRC in the RTP header.
>>>     
>>>> about the content of this specific RTP packet but in this case each 
>>>> t.140 packet is coming from a single source so one identifier is needed.
If it was from a combining server on the RTP side, I think it would be CSRC. The SSRC would then point at the server.
> *IF* the solution is an update to T.140, I guess that should be done in ITU-T?

T140blocks are just a number of complete T.140 code elements. And it is possible to define new such code elements.

So, even if RFC 4103 defined the term T140block, it is in ITU-T that additions to it should be defined.

If instead we specify that the T.140 data channel  shall carry a source and a T.140block in each T.140 data channel message, then it is a matter for mmusic and the draft we discuss here (or AVT or the closed RTCWEB if it seems complex) to specify that source element and the structure of the T.140 data channel message contents.

Regards

Gunnar

>      Subject: Re: [MMUSIC] 
> draft-holmberg-mmusic-t140-usage-data-channel - multi-party
>       
>      Hi Roni,
>       
>      Subject: Re: [MMUSIC] 
> draft-holmberg-mmusic-t140-usage-data-channel - multi-party
>       
>      Hi Christer,
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
>       
> source/destination pair. or 2) Introduce a source indicator in the 
> data format for the T140 data channel, either one per STCP message 
> requiring all T140blocks in the message being from one source only, or 
> inline between series of T140blocks from different sources. This is 
> because the real-time text from multiple sources simultaneously need 
> to be presented with some separation, so that the text gets readable 
> at least sentence-wise from each source. The T.140 Appendix 1 shows 
> two ways to do this, one column-oriented, and one sentence-oriented 
> with a label per start of sentence. You can read more about the topic 
> in 
> https://www.ietf.org/archive/id/draft-hellstrom-text-conference-04.txt
>       
>       
> ----------------------------------------------------------------------
> ------------------------------------------------------------
>       
>      -
>      -

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Aug 2019 11:11:22 -0400

> 2) If it is an issue, and a single data channel could be used for multiple remote participants, what would be the best way to solve it

+1

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Aug 2019 11:20:56 -0400

>> The data channel itself is always bi-directional. Now, if you want to 
>> allow usage of direction attributes for T.140 data I guess we would 
>> have to define usage of them inside a 'dcsa' attribute.
> 

I think it may make sense to use sendonly/recvonly here. Doing so will 
require *some* document to specify that and update the registration of 
those attributes to indicate it.

But I don't think it is sufficient to simply add IANA considerations to 
update the registry. The use of sendrecv/sendonly/recvonly/inactive, as 
specified in rfc4566bis, is strongly linked (at least implicitly) to how 
RTP works. To use them in this new context I think there needs to be a 
document that discusses the details.

	Thanks,
	Paul