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

From: Gunnar Hellström <[email-masked]>
Date: Sun, 12 Sep 2021 23:09:15 +0200

Hi,

I have reviewed rum-rue-07.

It looks mature. I have a few comments:

1. General: International applicability. There was a discussion about 
the international applicability of the draft in the beginning of the 
WGLC. I want to comment on that, without proposing any modification. I 
think the draft at least can be a source of inspiration in service 
deployment outside USA. But there are some items that make it less 
likely that it will be applied in its entirety.

- The draft is very focused around a structure with the speaking party 
in the call using a telephone service in the PSTN and being addressed 
through a phone number. The latest European regulations move away from 
telephone number based addressing, and requires relay services to be 
provided with all interpersonal electronic communications services 
regardless of the addressing format. That requires a new approach to the 
architecture of relay services. It is however still to be seen when that 
move starts, and some new implementations may still become inspired by 
the draft. So, my comment is: move on and get this work published.

2. Page 3, next to last paragraph in section 2. There is an unresolved 
reference to "FCC-VRS-GUIDE". I suggest to delete the sentence.

3. The WebRTC and traditional SIP hybrid specified in a number of 
sections, e.g. 5.5 and 6, looks hard to implement. There are a number of 
RFC:s implemented in the browsers that you suggest to be implemented 
outside a browser. And you require to add the m=text media with RTP 
transport as specified in RFC 4103 as an exception in that environment, 
where otherwise only m=audio, m=video and m=application are supported. 
Is that realistic? Do not implementors want to use the WebRTC support in 
the browsers and find obstacles both to make it a "non-browser endpoint" 
and to squeeze m=text support into that structure?

Would it not provide higher likelihood for realistic implementation 
efforts if you specified a true WebRTC interface with SIP based call 
control, and leave to the provider to arrange interworking with old 
style devices and emergency services? The note at the end of section 6.2 
indicates anyway that you imagine some interworking with "real" WebRTC 
endpoints.

It would also match the trends in interpersonal communication development.

4. Real-time text. Transport of T.140 real-time text in WebRTC is 
specified in RFC 8865, using the WebRTC data chanel. RFC 8865 also has 
some advice on how gateways between RFC 4103 and RFC 8865 should 
operate. I suggest that you at least inform about RFC 8865 or possibly 
require it  in section 6.2 and 6.6. If you accept to change the approach 
from the hybrid to WebRTC, I suggest that you require RFC 8865 support 
for real-time text in the RUE, and conversion to RFC 4103 by the 
provider for interoperability in section 6.2 and for emergency calls in 
section 5.2.5.

5. Emergency call support .
Section 5.2.5 requires support of RFC 6881 for emergency calls. RFC 6881 
requires quite straightforward media handling without bundle and other 
WebRTC specific actions. Can the RUE with its hybrid WebRTC 
implementation really have direct calls to RFC 6881 emergency services?
  Section 5.2.5 says that for some countries, the provider may need to 
adapt the call to match the emergency service interface in that country. 
Will that not always apply, even in USA?

6. Multiparty call support. At least in the emergency service calls, 
specified in section 5.2.5, there will be a need to support multiparty 
calls. Maybe also in other situations. At least real-time text requires 
specific support for proper presentation of multiparty contents. RFC 
4103 has an update for multiparty real-time text in RFC 9071. I suggest 
that you add requirements to support it in section 6.2. Or, if you 
accept to move to WebRTC, then RFC 8865 has support for multiparty 
real-time text, but then the requirement to support RFC 9071 should be 
placed in section 5.2.5 or where interoperability with traditional SIP 
is specified in 6.2.

7. Language support.
In section 9.2.1 you specify language tags for signup, dial around and 
helpdesk.

For helpdesk I assume that it is the language you can use with the 
helpdesk, e.g. American Sign Language ASL, but what are the other two 
languages? If it is the language support during the relay service calls, 
then it should be two languages; one spoken language and one signed 
language. And what if they support a range of languages. Should the 
parameter be a list of language subtags? Please clarify in 9.2.1.

Regards

Gunnar

Den 2021-08-26 kl. 19:05, skrev Paul Kyzivat:
> [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
>
> On 8/26/21 12:09 PM, Brian Rosen wrote:
>> This version:
>> Changes jCard to xCard
>> Says ICE candidates with specific IP versions is allowed
>> Doesn’t require MWI support if voicemail is not supported (actually, 
>> 06 said that).
>>
>> I think the document is ready for work group last call.
>>
>> Brian
>>
>>
>>> On Aug 26, 2021, at 12:05 PM, [email-masked] wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Relay User Machine WG of the IETF.
>>>
>>>         Title           : Interoperability Profile for Relay User 
>>> Equipment
>>>         Author          : Brian Rosen
>>>     Filename        : draft-ietf-rum-rue-07.txt
>>>     Pages           : 33
>>>     Date            : 2021-08-26
>>>
>>> Abstract:
>>>    Video Relay Service (VRS) is a term used to describe a method by
>>>    which a hearing persons can communicate with deaf/Hard of Hearing
>>>    user using an interpreter ("Communications Assistant") connected via
>>>    a videophone to the deaf/HoH user and an audio telephone call to the
>>>    hearing user.  The CA interprets using sign language on the
>>>    videophone link and voice on the telephone link.  Often the
>>>    interpreters may be supplied by a company or agency termed a
>>>    "provider" in this document.  The provider also provides a video
>>>    service that allows users to connect video devices to their service,
>>>    and subsequently to CAs and other deaf/HoH users.  It is desirable
>>>    that the videophones used by the deaf/HoH/H-I user conform to a
>>>    standard so that any device may be used with any provider and that
>>>    video calls direct between deaf/HoH users work.  This document
>>>    describes the interface between a videophone and a provider.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-07
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>
-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Sep 2021 10:30:48 -0400

Gunnar,

You cover a number of distinct points. I'm going to make separate 
replies to them, and leave some of them to Brian.

On 9/12/21 5:09 PM, Gunnar Hellström wrote:
> deployment outside USA.

When the larger VRS work began many years ago we tried to make it 
applicable internationally. But it became apparent at the time that 
expectations and requirements varied widely between countries. At least 
in the US, FCC regulations dominate the service. So we focused on 
something that met US needs.

Superficially the RUM work is supposed to be international, but 
practically speaking I think it is probably only applicable to the US 
and perhaps a few other countries that are closely allied.

So I appreciate your willingness to not push this issue too much at this 
time.

BUT, once we get this draft on its way, we certainly can consider 
rechartering for additional work.

> But there are some items that make it less 

I'm pleased to see you bring this up. For several years I have been 
thinking along similar lines.

The current architecture, where the VRS providers are telephony 
providers, made sense when VRS service was first rolled out, and when 
internet capabilities were much more limited.

My thought is that VRS service could be treated as simply a remote 
transcoder service, that an and user device could dynamically pull into 
a real-time communication session when needed.

This would not qualify for subsidy in the US under current FCC 
regulations. But having an architecture for such a service is probably a 
prerequisite for changes in those rules.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Sep 2021 16:20:04 -0400

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>

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>

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>

4) Need to fix an unresolved reference to [FCC-VRS-GUIDE]
<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>

6) Jean Mahoney raised a number of editorial issues
<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>

8) Support for IPv6
<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:
> 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.)
> 
> based on WGLC comments. If discussion has been robust but incomplete we 
> MAY further extend the WGLC.
> 
>      Thank you,
>      Paul Kyzivat

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Sep 2021 09:24:41 +0200

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>

/Gunnar

Den 2021-09-14 kl. 22:20, skrev Paul Kyzivat:
> 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.
>
> 3) In section 7.2 of this document, it still refers to the use of 
> jCard. Should be xcard.
> 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 
> consensus points that need to be addressed, please post details no 
> later than this coming Friday, Sept 17.
>
>> This message announces the start of WGLC (Working Group Last Call) 
>> for draft-ietf-rum-rue-07.
>>
>> 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

---

From: Ed Sayers <[email-masked]>
Date: Wed, 15 Sep 2021 09:53:00 +0000

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.

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.

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.

Cheers,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
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 <[email-masked]> On Behalf Of Gunnar Hellström
Sent: 15 September 2021 08:25
To: Paul Kyzivat <[email-masked]>; [email-masked]
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>

/Gunnar

Den 2021-09-14 kl. 22:20, skrev Paul Kyzivat:
> <https://mailarchive.ietf.org/arch/msg/rum/toxdHe0D9x1kVPcZkRB_N8R9Ww4
> >
>
> <https://mailarchive.ietf.org/arch/msg/rum/TQfX2RpHYcM883O47FSqsetBsZM
> > 
> <https://mailarchive.ietf.org/arch/msg/rum/TQfX2RpHYcM883O47FSqsetBsZM
> >
>
> <https://mailarchive.ietf.org/arch/msg/rum/6dnvxHIJuTSzndf_35QG7OcYZOI
> >
>
>
> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4
> >
>
> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4
> >
>
> <https://mailarchive.ietf.org/arch/msg/rum/FxaKh2k52jcB8yacoa7l5FBHgDA
> >
>
> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4
> >
>
> 8) Support for IPv6
> <https://mailarchive.ietf.org/arch/msg/rum/t4SJcmr63rli0k-y1ClQQj39JBE
> >
>

--
Rum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rum

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Sep 2021 13:35:29 +0200

Hi Ed,

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

---

From: Ed Sayers <[email-masked]>
Date: Wed, 15 Sep 2021 12:28:40 +0000

Hi Gunnar,

Comments inline..

Ed Sayers
Endpoint SDK Team Lead

-----Original Message-----
From: Gunnar Hellström <[email-masked]> 
Sent: 15 September 2021 12:35
To: Ed Sayers <[email-masked]>; [email-masked]
Subject: Re: [Rum] END of WGLC for draft-ietf-rum-rue-07

Hi Ed,

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

[ES] I don't see why we would want to switch all existing endpoints over to send T140 over SCTP when the vast majority are not Browser-based and not limited this restriction.
T140 over and SCTP data channel is after all a work-around to not yet having the 'text' media type added to the WebRTC specification.

[ES] We already have some clients capable of using Bundle with audio, video and text. Adding text media to Bundle is trivial once Bundle itself has been implemented. This is regardless of whether SRTP-DTLS is used or not. T140 requires no special treatment in this regard - It is just another RTP stream on the same transport.

[ES] Yes - in the very specific case of two browser-based WebRTC clients, media could go directly. But, the RUM specification does not require a browser-based endpoint, so it should not code in requirements based on that limitation alone.
There are a large number of existing non-browser endpoints in the US VRS market that support audio, video and T140 text be conventional media types, which means that this would be a minority case.

In regards to receiving calls, the gateway could offer both text and application media options in the SDP.
These means that the endpoint can easily reject one and accept the other according to its limitations.

Regards

Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Sep 2021 08:32:00 -0400

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.

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.

Brian

> On Sep 15, 2021, at 7:35 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> Hi Ed,
> 
> [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?
>> 
> 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
> [email-masked] <mailto:[email-masked]>
> 
> -- 
> Rum mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Ed Sayers <[email-masked]>
Date: Wed, 15 Sep 2021 12:37:12 +0000

Hi Brian,

I would just add that while it is generally true that media is anchored today, US VRS Providers have included ICE into the latest version of the US Inter-Provider Profile, and thus over time that statement could become less true.

Cheers,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<https://purplevrs.com/>

[Purple is DEI certified!]
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.

From: Brian Rosen <[email-masked]>
Sent: 15 September 2021 13:32
To: Gunnar Hellström <[email-masked]>
Cc: Ed Sayers <[email-masked]>; [email-masked]
Subject: Re: [Rum] END of WGLC for draft-ietf-rum-rue-07

Gunnar

Brian

On Sep 15, 2021, at 7:35 AM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ed,

Hi Gunnar,

Regards

Gunnar

Cheers,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<http://purplevrs.com>

-----Original Message-----
From: Rum <[email-masked]<mailto:[email-masked]>> On Behalf Of Gunnar Hellström
Sent: 15 September 2021 08:25
To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] END of WGLC for draft-ietf-rum-rue-07

Paul,

I suggest that you add:

9) Transport of RTT

/Gunnar

Group,

    Thanks,
    Paul

     Thank you,
     Paul Kyzivat
--
Gunnar Hellström
GHAccess
[email-masked]<mailto:[email-masked]>

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

--
Gunnar Hellström
GHAccess
[email-masked]<mailto:[email-masked]>

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Sep 2021 08:52:25 -0400

Thanks for that.  I also see that I was too strong in saying “RTT is unbundled”.  Could be unbundled, could be bundled.  If it came bundled in the data channel, that bundling would have to be undone, but then it could get rebundled with other RTP media.

Brian

> On Sep 15, 2021, at 8:37 AM, Ed Sayers <[email-masked]> wrote:
> 
> Hi Brian,
>  
> purplevrs.com <https://purplevrs.com/>	
>  
> On Sep 15, 2021, at 7:35 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Ed,
> 
> purplevrs.com <http://purplevrs.com/>
> 
> From: Rum <[email-masked] <mailto:[email-masked]>> On Behalf Of Gunnar Hellström
> To: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4 <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>>
> 
> /Gunnar
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 15 Sep 2021 14:55:09 +0200

Out of curiousity: are there any requirements on legal intercept for VRS providers in the US?

/O

> On 15 Sep 2021, at 14:52, Brian Rosen <[email-masked]> wrote:
> 
>> On Sep 15, 2021, at 8:37 AM, Ed Sayers <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Brian,
>>  
>> From: Brian Rosen <[email-masked] <mailto:[email-masked]>> 
>> To: Gunnar Hellström <[email-masked] <mailto:[email-masked]>>
>> Cc: Ed Sayers <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> <https://mailarchive.ietf.org/arch/msg/rum/toxdHe0D9x1kVPcZkRB_N8R9Ww4 <https://mailarchive.ietf.org/arch/msg/rum/toxdHe0D9x1kVPcZkRB_N8R9Ww4>
>> <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>
>> <https://mailarchive.ietf.org/arch/msg/rum/6dnvxHIJuTSzndf_35QG7OcYZOI <https://mailarchive.ietf.org/arch/msg/rum/6dnvxHIJuTSzndf_35QG7OcYZOI>
>> 
>> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4 <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>
>> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4 <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>
>> <https://mailarchive.ietf.org/arch/msg/rum/FxaKh2k52jcB8yacoa7l5FBHgDA <https://mailarchive.ietf.org/arch/msg/rum/FxaKh2k52jcB8yacoa7l5FBHgDA>
>> <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>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Sep 2021 09:05:35 -0400

Surprisingly, none to my knowledge.  Since classical VRS had one leg in the PSTN, and VRS providers aren’t carriers, I doubt it even was considered. 

Brian

> On Sep 15, 2021, at 8:55 AM, Olle E. Johansson <[email-masked]> wrote:
> 
>> On 15 Sep 2021, at 14:52, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "gunnar.hellstrom" <[email-masked]>
Date: Thu, 16 Sep 2021 20:42:28 +0200

The usual reaction is that legal intercept is a matter for the carriers the calls are passing, and not for the endpoints discussed in rum-rue and other relay service related specs.That view is still valid even if it is more complicated to implement it when ICE or WebRTC is applied.RegardsGunnarSkickat från min Galaxy
-------- Originalmeddelande --------Från: Brian Rosen <[email-masked]> Datum: 2021-09-15  15:06  (GMT+01:00) Till: "Olle E. Johansson" <[email-masked]> Kopia: [email-masked] Ämne: Re: [Rum] END of WGLC for draft-ietf-rum-rue-07 Surprisingly, none to my knowledge.  Since classical VRS had one leg in the PSTN, and VRS providers aren’t carriers, I doubt it even was considered. BrianOn Sep 15, 2021, at 8:55 AM, Olle E. Johansson <[email-masked]> wrote:Out of curiousity: are there any requirements on legal intercept for VRS providers in the US?/OOn 15 Sep 2021, at 14:52, Brian Rosen <[email-masked]> wrote:Thanks for that.  I also see that I was too strong in saying “RTT is unbundled”.  Could be unbundled, could be bundled.  If it came bundled in the data channel, that bundling would have to be undone, but then it could get rebundled with other RTP media.BrianOn Sep 15, 2021, at 8:37 AM, Ed Sayers <[email-masked]> wrote:Hi Brian, I would just add that while it is generally true that media is anchored today, US VRS Providers have included ICE into the latest version of the US Inter-Provider Profile, and thus over time that statement could become less true. Cheers,  Ed SayersEndpoint SDK Team LeadPurple, a Division of ZP Better Together, LLCpurplevrs.com <image001.jpg>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.    From: Brian Rosen <[email-masked]> Sent: 15 September 2021 13:32To: Gunnar Hellström <[email-masked]>Cc: Ed Sayers <[email-masked]>; [email-masked]: Re: [Rum] END of WGLC for draft-ietf-rum-rue-07 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. 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. BrianOn Sep 15, 2021, at 7:35 AM, Gunnar Hellström <[email-masked]> 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.RegardsGunnarCheers,Ed SayersEndpoint SDK Team LeadPurple, a Division of ZP Better Together, LLCpurplevrs.comThe 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 <[email-masked]> On Behalf Of Gunnar HellströmSent: 15 September 2021 08:25To: Paul Kyzivat <[email-masked]>; [email-masked]: Re: [Rum] END of WGLC for draft-ietf-rum-rue-07Paul,I suggest that you add:9) Transport of RTTRTT transport in WebRTC data channel is specified in RFC 8865, including advice for gateways to RFC 4103 for RTP transport. Include use of RFC8865 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>/GunnarDen 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 listdiscussion that has occurred since the beginning of the last call. Iam  giving a brief summary of each point and a reference to the emaila key email message about it.1) Correct a dropped reference to [RFC6442]<https://mailarchive.ietf.org/arch/msg/rum/toxdHe0D9x1kVPcZkRB_N8R9Ww42) Add a section discussion video email management and a URL to theconfiguration 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/TQfX2RpHYcM883O47FSqsetBsZM3) In section 7.2 of this document, it still refers to the use ofjCard. Should be xcard.<https://mailarchive.ietf.org/arch/msg/rum/6dnvxHIJuTSzndf_35QG7OcYZOI4) Need to fix an unresolved reference to [FCC-VRS-GUIDE]<https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg45) A need was raised to add support for multiparty RTT (because it canarise in emergency calls)<https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg46) Jean Mahoney raised a number of editorial issues<https://mailarchive.ietf.org/arch/msg/rum/FxaKh2k52jcB8yacoa7l5FBHgDA7) Gunnar requested that the semantics of language support in theconfiguration.<https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg48) Support for IPv6<https://mailarchive.ietf.org/arch/msg/rum/t4SJcmr63rli0k-y1ClQQj39JBEIn 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) andSRTP (adding a requirement to support OSRTP) were very welcome, and Iwill add them to the document assuming Paul calls consensus on thoseitems."Yet I find no other mention of OSRTP in list email since well beforethe start of wglc, nor in the meeting minutes. I don't think there wasanything like consensus on this.If anyone thinks we have reached any new conclusion on IPv6, can youplease post a reference that documents it?If anyone disputes any of the above, or thinks there were otherconsensus points that need to be addressed, please post details nolater than this coming Friday, Sept 17.Meanwhile I request that Brian begin incorporating the above into arevised version.    Thanks,    PaulOn 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 moveto wrap things up. The comments that have been posted for the lastfew days will be treated as WGLC comments. If you have made commentsrecently 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 standbased on WGLC comments. If discussion has been robust but incompletewe MAY further extend the WGLC.     Thank you,     Paul Kyzivat--Gunnar [email-masked] mailing [email-masked]://www.ietf.org/mailman/listinfo/rum-- Gunnar [email-masked] Rum mailing [email-masked]://www.ietf.org/mailman/listinfo/rum-- Rum mailing [email-masked]://www.ietf.org/mailman/listinfo/rum-- Rum mailing [email-masked]://www.ietf.org/mailman/listinfo/rum

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 16 Sep 2021 22:50:29 +0200

Brian,

Den 2021-09-15 kl. 14:32, skrev Brian Rosen:
> 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 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>> Hi Ed,
>>
>>> 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.
>>
>> 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.
>>
>> 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
>>> 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.
>>>
>>>
>>>
>>>
>>> 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
>> <https://www.ietf.org/mailman/listinfo/rum>
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 16 Sep 2021 17:17:53 -0400

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 <[email-masked]> wrote:
> 
> Brian,
> 
> 
> 
> 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.
> 
>    Transport of T.140 real-time text in WebRTC is specified in RFC 8865 [RFC8865], using
>    RFC 8865 is used for communication with browser-based WebRTC implementations.
> 
> 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
>> 
>>>> From: Rum <[email-masked]> <mailto:[email-masked]> On Behalf Of Gunnar Hellström
>>>> To: Paul Kyzivat <[email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>>>> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4> <https://mailarchive.ietf.org/arch/msg/rum/zV5_dCm-sAN8N7ewrcdDsLsiCg4>
>>>> 
>>>> /Gunnar
>>>>

---

From: Matthew H Garber <[email-masked]>
Date: Thu, 23 Sep 2021 11:20:48 +0000

Hi all,

While we agree with Gunnar’s assessment that multi-party RTT for emergency calls is an appropriate long term goal, due to technical limitations in browser technology and the open-source media gateway server we are using, our reference implementation will not be able to support multiparty RTT calls in the near term. We will continue to monitor this technology and will implement the functionality when practical.

-Matt

From: Rum <[email-masked]> on behalf of Brian Rosen <[email-masked]>
Date: Thursday, September 16, 2021 at 5:18 PM
To: Gunnar Hellström <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [EXT] Re: [Rum] END of WGLC for draft-ietf-rum-rue-07
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 <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

Gunnar
Brian

Hi Ed,

Hi Gunnar,

Regards

Gunnar

Cheers,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<http://purplevrs.com/>

-----Original Message-----
From: Rum <[email-masked]><mailto:[email-masked]> On Behalf Of Gunnar Hellström
Sent: 15 September 2021 08:25
To: Paul Kyzivat <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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

Group,

    Thanks,
    Paul

     Thank you,
     Paul Kyzivat

--

Gunnar Hellström

GHAccess

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Sep 2021 13:53:02 -0400

Matt,

On 9/23/21 7:20 AM, Matthew H Garber wrote:
> Hi all,
> 
> While we agree with Gunnar’s assessment that multi-party RTT for 
> emergency calls is an appropriate long term goal, due to technical 
> limitations in browser technology and the open-source media gateway 
> server we are using, our reference implementation will not be able to 
> support multiparty RTT calls in the near term. We will continue to 
> monitor this technology and will implement the functionality when practical.

(Speaking as individual, not chair.)

Thanks for the view from the trenches.

Has the multi-party RTT been adopted by ECRIT?
ISTM that the driver here is for emergency calls. So I would expect that 
ECRIT should lead the way on this.

	Thanks,
	Paul

> -Matt
> 
> *From: *Rum <[email-masked]> on behalf of Brian Rosen 
> <[email-masked]>
> *Date: *Thursday, September 16, 2021 at 5:18 PM
> *To: *Gunnar Hellström <[email-masked]>
> *Cc: [email-masked] <[email-masked]>
> *Subject: *[EXT] Re: [Rum] END of WGLC for draft-ietf-rum-rue-07
> 
>     On Sep 16, 2021, at 4:50 PM, Gunnar Hellström
>         videophone service, with middle boxes (SBCs and proxies), and
>         clients need to be able to connect to RUE and non-RUE clients.
> 
>     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.
> 
>         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.
> 
>     browser-based WebRTC implementations in 6.2, you could clarify that
>     even further by including the text in 6.2 proposed above.
> 
>     Gunnar
> 
>         Brian
> 
> 
> 
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
> 
>             Hi Ed,
> 
>                 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.
> 
> 
>             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
>                 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
>                 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.
> 
> 
> 
> 
>                 From: Rum<[email-masked]>
>                 <mailto:[email-masked]>On Behalf Of Gunnar Hellström
>                 To: Paul Kyzivat<[email-masked]>
>                 <mailto:[email-masked]>;[email-masked]
>                 <mailto:[email-masked]>
>                 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
>                 <mailto:[email-masked]>
> 
>                 --
>                 Rum mailing list
>             <mailto:[email-masked]>
> 
>             --
>             Rum mailing list

---

From: Brian Rosen <[email-masked]>
Date: Thu, 23 Sep 2021 13:55:15 -0400

It’s in the NENA STA-010 spec, and so part of US NG9-1-1 standards.  Not (yet) in ecrit.

> On Sep 23, 2021, at 1:53 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Matt,
> 
> ISTM that the driver here is for emergency calls. So I would expect that ECRIT should lead the way on this.
> 
> 	Thanks,
> 	Paul
> 
>> -Matt
>> *From: *Rum <[email-masked]> on behalf of Brian Rosen <[email-masked]>
>>    --     Gunnar Hellström

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Sep 2021 14:15:01 -0400

Brian,

>> On Sep 23, 2021, at 1:53 PM, Paul Kyzivat <[email-masked]> wrote:

Can you take off your draft author hat and instead put on your ecrit and 
NENA hat, and then give your thoughts about whether this feature should 
be in the RUM RUE spec?

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 23 Sep 2021 14:26:00 -0400

(As individual)

The results for people placing emergency calls (which are frequently transferred to a dispatcher) using RTT without multi-party are bad.   There isn’t any way to get a good result other than if all parties implement multi-party.  It’s my (personal) opinion that it MUST be included.  All it means on the client is supporting an SDP stream per participant, rather than one per conversation.  It doesn’t mean much more to the provider side, since they would otherwise have to do the mixing, which is a lot harder than maintaining the multiple streams, but recognizing that whenever you say “both” (which is implied), it’s more work.  If/when we update RFC6881, I’m sure we would require support for multi-party, for the above reason.

As I said, it’s required on the emergency call side in Canada starting next year.  It’s mandated in the NENA standard.  The US deployment will lag Canada, but is going to happen.

Brian

> On Sep 23, 2021, at 2:15 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Brian,
> 
> Can you take off your draft author hat and instead put on your ecrit and NENA hat, and then give your thoughts about whether this feature should be in the RUM RUE spec?
> 
> 	Thanks,
> 	Paul
> 
>>> Matt,
>>>