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

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

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, [e-mail] 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
>>> [e-mail]
>>> 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
[e-mail]