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

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

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

Some comments below:

Den 2019-08-17 kl. 08:09, skrev Christer Holmberg:
>
> Hi Bernard,
>
> Thank You for the information!
>
> Does that mean you think we should adopt the draft? :)
>
> Regards,
>
> Christer
>
> *Lähettäjä:*Bernard Aboba <[e-mail]>
> *Lähetetty:* lauantai 17. elokuuta 2019 2.02
> *Vastaanottaja:* Christer Holmberg <[e-mail]>
> *Kopio:* [e-mail]
> *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
>
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 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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.
>
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

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

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]