Re: [Rum] END of WGLC for draft-ietf-rum-rue-07

[Brian Rosen <[e-mail]>]

If there is no objection, I will add this to the version I am working on now.

Brian

> On Sep 16, 2021, at 4:50 PM, Gunnar Hellström <[e-mail]> wrote:
> 
> Brian,
> 
> 
> 
> Den 2021-09-15 kl. 14:32, skrev Brian Rosen:
>> Gunnar
>> 
>> I think you are trying to push the WebRTC media specs too far.
>> Please keep in mind that VRS, as presently deployed, is a SIP videophone service, with middle boxes (SBCs and proxies), and clients need to be able to connect to RUE and non-RUE clients.
> OK, keep RFC 4103 for the RUE interface.
> 
> But 6.2 seems to also talk about the interoperation between a kind of RUE and a browser-implemented WebRTC client. I think it would be appropriate at that point to inform about RFC 8865 at least for possible use on the WebRTC side.
> 
> So, I suggest to add information last in 6.2:
> 
> ----------------------------------------------------------------------------------------------------------
> 
> Current 6.2:
> 
>    Implementations MUST support real-time text ([RFC4102] and [RFC4103])
>    via T.140 media.  One original and two redundant generations MUST be
>    transmitted and supported, with a 300 ms transmission interval.  Note
>    that this is not how real time text is transmitted in WebRTC and some
>    form of transcoder would be required to interwork real time text in
>    the data channel of WebRTC to RFC4103 real time text.
> 
> -------------------------------------------------------------------------------------------------------
> 
> Proposed extended 6.2
> 
>    Implementations MUST support real-time text ([RFC4102] and [RFC4103])
>    via T.140 media.  One original and two redundant generations MUST be
>    transmitted and supported, with a 300 ms transmission interval.  Note
>    that this is not how real time text is transmitted in WebRTC and some
>    form of transcoder would be required to interwork real time text in
>    the data channel of WebRTC to RFC4103 real time text.
> 
>    Transport of T.140 real-time text in WebRTC is specified in RFC 8865 [RFC8865], using
>    the WebRTC data chanel. RFC 8865 also has some advice on how gateways
>    between RFC 4103 and RFC 8865 should operate. It is RECOMMENDED that
>    RFC 8865 is used for communication with browser-based WebRTC implementations.
> 
> ------------------------------------------------------------------------------------------------------------------------
> 
> 
>> 
>> We expressly excluded RTT from the WebRTC media streams at the RUE interface.  That means that the RTT is not bundled, can use ICE, can use SRTP.   It is interworked to RFC4103 by the RUE implementation, which is a gateway between real WebRTC and the RUE specification.  So as seen by the WebRTC client, the RTT may well be bundled, but that wouldn’t look the same at the RUE interface.   And, since all providers I know about anchor media, bundling at one end may look differently at the other, and the middle could be unbundled, or even bundled a different way, because the media is anchored, transported (sometimes between providers) and then possibly re-bundled at the far end media anchor.  Or not.  And we don’t care.  At the RUE interface, RTT is RFC4103.
>> 
>> So 8865 is not part of the RUE spec, although the RUE implementor would expect to see 8865 coming from the WebRTC client.  It would not use 8865 on the RUE interface.
> Since you already inform a bit about how to handle interworking with browser-based WebRTC implementations in 6.2, you could clarify that even further by including the text in 6.2 proposed above.
> 
> 
> Gunnar
> 
>> Brian
>> 
>>> On Sep 15, 2021, at 7:35 AM, Gunnar Hellström <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Ed,
>>> 
>>> Den 2021-09-15 kl. 11:53, skrev Ed Sayers:
>>>> Hi Gunnar,
>>>> 
>>>> I would suggest that RFC-8865 should not be a requirement as such, because only browser-based endpoints are limited by the need to support T140 over an SCTP data channel.
>>> 
>>> [GH] Yes of course. I had two options in my proposal, depending on what is decided for WebRTC.
>>> 
>>> Either go completely for WebRTC instead of the hybrid solution and then require RFC 8865, or describe how to make a WebRTC based alternative and then mention that RFC 8865 is then the transport alternative for RTT.
>>> 
>>>> 
>>>> Any non-browser-based T140 capable endpoint can already support RFC-4103 directly over UDP/RTP normally, as it does for audio or video media.
>>> [GH] Yes, I realize that, but don´t you think that it will be complex to implement all the WebRTC specialities with bundling etc and then add RFC 4103 in that environment. (e.g. decide if also RFC 4103 shall be included in bundled transport with other media or not. ( It can use ICE and SRTP without problems so maybe the bundling is also no problem). Will the implementation base for transport of video and audio easily allow addition of text media also?
>>>> 
>>>> Thus, I believe that RFC-8865 should only be required where T-140 over RTP/UDP cannot be supported directly a RUM endpoint.
>>>> 
>>>> This avoids the implicit requirement to pin all media to a gateway for all RUM endpoints, just to translate T140 over SCTP for some of those endpoints.
>>>> This would particularly affect the use-case of peer-to-peer calling where ICE may be able to find a more direct route between endpoints.
>>> 
>>> Yes, but for peer-to-peer with WebRTC clients, you would also go directly. It is only with mixed transports that you would need to convert.
>>> 
>>> On the other hand, WebRTC clients would need a good agreed way to be addressed and be called, so there is maybe not any straightforward way to move completely to WebRTC implementations.
>>> 
>>> Regards
>>> 
>>> Gunnar
>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> 
>>>> Ed Sayers
>>>> Endpoint SDK Team Lead
>>>> Purple, a Division of ZP Better Together, LLC
>>>> purplevrs.com <http://purplevrs.com/>
>>>> 
>>>> The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Rum <[e-mail]> <mailto:[e-mail]> On Behalf Of Gunnar Hellström
>>>> Sent: 15 September 2021 08:25
>>>> To: Paul Kyzivat <[e-mail]> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>>>> Subject: Re: [Rum] END of WGLC for draft-ietf-rum-rue-07
>>>> 
>>>> Paul,
>>>> 
>>>> I suggest that you add:
>>>> 
>>>> 9) Transport of RTT
>>>> 
>>>> RTT transport in WebRTC data channel is specified in RFC 8865, including advice for gateways to RFC 4103 for RTP transport. Include use of RFC
>>>> 8865 either as a requirement or as information for interop with WebRTC in sections 5.2.5, 6.2 and 6.6.
>>>> See point 4 in
>>>> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>
>>>> 
>>>> /Gunnar
>>>> 
>>>> Den 2021-09-14 kl. 22:20, skrev Paul Kyzivat:
>>>>> Group,
>>>>> 
>>>>> The WGLC for draft-ietf-rum-rue-07 ended yesterday Sept 13.
>>>>> 
>>>>> Here is my attempt at summarizing the actionable items from the list
>>>>> discussion that has occurred since the beginning of the last call. I
>>>>> am  giving a brief summary of each point and a reference to the email
>>>>> a key email message about it.
>>>>> 
>>>>> 1) Correct a dropped reference to [RFC6442]
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/toxdHe0D9x1kVPcZkRB_N8R9Ww4 <https://mailarchive.ietf.org/arch/msg/rum/toxdHe0D9x1kVPcZkRB_N8R9Ww4>
>>>>> 2) Add a section discussion video email management and a URL to the
>>>>> configuration that the RUE may invoke to retrieve/manage video mail.
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/TQfX2RpHYcM883O47FSqsetBsZM <https://mailarchive.ietf.org/arch/msg/rum/TQfX2RpHYcM883O47FSqsetBsZM>
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/TQfX2RpHYcM883O47FSqsetBsZM <https://mailarchive.ietf.org/arch/msg/rum/TQfX2RpHYcM883O47FSqsetBsZM>
>>>>> 3) In section 7.2 of this document, it still refers to the use of
>>>>> jCard. Should be xcard.
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/6dnvxHIJuTSzndf_35QG7OcYZOI <https://mailarchive.ietf.org/arch/msg/rum/6dnvxHIJuTSzndf_35QG7OcYZOI>
>>>>> 
>>>>> 4) Need to fix an unresolved reference to [FCC-VRS-GUIDE]
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4 <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>
>>>>> 5) A need was raised to add support for multiparty RTT (because it can
>>>>> arise in emergency calls)
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4 <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>
>>>>> 6) Jean Mahoney raised a number of editorial issues
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/FxaKh2k52jcB8yacoa7l5FBHgDA <https://mailarchive.ietf.org/arch/msg/rum/FxaKh2k52jcB8yacoa7l5FBHgDA>
>>>>> 7) Gunnar requested that the semantics of language support in the
>>>>> configuration.
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4 <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>
>>>>> 8) Support for IPv6
>>>>> <https://mailarchive.ietf.org/arch/msg/rum/t4SJcmr63rli0k-y1ClQQj39JBE <https://mailarchive.ietf.org/arch/msg/rum/t4SJcmr63rli0k-y1ClQQj39JBE>
>>>>> In the above message Brian says:
>>>>> "I would like to add that the proposed compromise actions on IPv6
>>>>> (adding the support mandate for the backwards compatibility RFCs) and
>>>>> SRTP (adding a requirement to support OSRTP) were very welcome, and I
>>>>> will add them to the document assuming Paul calls consensus on those
>>>>> items."
>>>>> 
>>>>> Yet I find no other mention of OSRTP in list email since well before
>>>>> the start of wglc, nor in the meeting minutes. I don't think there was
>>>>> anything like consensus on this.
>>>>> 
>>>>> If anyone thinks we have reached any new conclusion on IPv6, can you
>>>>> please post a reference that documents it?
>>>>> 
>>>>> If anyone disputes any of the above, or thinks there were other
>>>>> consensus points that need to be addressed, please post details no
>>>>> later than this coming Friday, Sept 17.
>>>>> 
>>>>> Meanwhile I request that Brian begin incorporating the above into a
>>>>> revised version.
>>>>> 
>>>>>     Thanks,
>>>>>     Paul
>>>>> 
>>>>> On 8/26/21 1:05 PM, Paul Kyzivat wrote:
>>>>>> [Speaking as a RUM WG chair]
>>>>>> 
>>>>>> This message announces the start of WGLC (Working Group Last Call)
>>>>>> for draft-ietf-rum-rue-07.
>>>>>> 
>>>>>> The end of this WGLC will be midnight UTC on September 12, 2021.
>>>>>> (That is roughly two weeks, rounded up to a week boundary.)
>>>>>> 
>>>>>> The energy level in the wg has been low. This WGLC is to help us move
>>>>>> to wrap things up. The comments that have been posted for the last
>>>>>> few days will be treated as WGLC comments. If you have made comments
>>>>>> recently please review to see if they are impacted by the changes in
>>>>>> -07 and if so update your comments. (I don't think any are.)
>>>>>> 
>>>>>> Starting on Monday morning September 13 we will assess where we stand
>>>>>> based on WGLC comments. If discussion has been robust but incomplete
>>>>>> we MAY further extend the WGLC.
>>>>>> 
>>>>>>      Thank you,
>>>>>>      Paul Kyzivat
>>>> --
>>>> Gunnar Hellström
>>>> GHAccess
>>>> [e-mail] <mailto:[e-mail]>
>>>> 
>>>> --
>>>> Rum mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
>>> 
>>> -- 
>>> Gunnar Hellström
>>> GHAccess
>>> [e-mail] <mailto:[e-mail]>
>>> 
>>> -- 
>>> Rum mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> -- 
> Gunnar Hellström
> GHAccess
> [e-mail] <mailto:[e-mail]>