Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel - modification to gateway procedures

[Christer Holmberg <[e-mail]>]

 Hi Gunner,

In this reply I'll address your comments on the gateway section.

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

In general the text looks good. I do have some editorial comments, but you'll see them in the pull request. 

A couple of generic comments, though:

1. I don't want to talk about "WebRTC environment", because I don't really know what that is. Also, while the name contains "WebRTC", data channels can be used by "native" clients too.

2. Regarding the EDITOR NOTE, the way it is written it seems like such method exists (which, AFAIK is not true), and we may be asked to reference such method.

Maybe something like:

"In order for the gateway to insert a missing text marker, or to perform other actions that require that the gateway has access to the T.140 data, the T.140 data cannot
be encrypted end-to-end between the T.140 data channel endpoint and the RFC 4103 endpoint. At the time of writing this document, a mechanism to provide such
encryption has not been defined."

---

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

Will add.

Regards,

Christer