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

[Christer Holmberg <[e-mail]>]

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



    >
    >
    > 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:
    >>
    >> 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
    >>
    >> On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg" <[e-mail] on behalf of [e-mail]> wrote:
    >>
    >>       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
    >>       [e-mail]
    >>       https://www.ietf.org/mailman/listinfo/mmusic
    >>       
    >>
    > --
    > -----------------------------------------
    > Gunnar Hellström
    > Omnitor
    > [e-mail]
    > [phone]
    >
    > _______________________________________________
    > mmusic mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/mmusic
    
    -- 
    -----------------------------------------
    Gunnar Hellström
    Omnitor
    [e-mail]
    [phone]