Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[New requirement] for 3.10 Video relay services (VRS) and remote interpretation (VRI) - 12d #1

Open
RealJoshue108 opened this issue Apr 15, 2021 · 9 comments
Assignees
Labels

Comments

@RealJoshue108
Copy link
Contributor

RealJoshue108 commented Apr 15, 2021

Based on input from @gunnarhm I think we have a new requirement for '3.10 Video relay services (VRS) and remote interpretation (VRI)'.

"12d: Ensure WebRTC supports integration of traditional mobile telephony and relay services."

What do you all think?

@RealJoshue108 RealJoshue108 self-assigned this Apr 15, 2021
@JWJPaton
Copy link

Hi Josh,

I don't think I was too clear on the call (at least not in my own head). There is maybe a requirement here for Text Relay as far as the UK goes but not Video Relay which is not integrated into the PSTN as such.

Accommodating Text relay in the UK would require allowing for the 5 digit prefix which some systems manage to break by not allowing users to input numbers that long or doing some input validation that doesn’t recognise the longer number as valid.
This may be a genuine requirement but not in the VRS/VI User need and only if the system needs to work with the users number (which may not be the case if everyone dials in). One potential use case is if security is performed by only allowing particular numbers to dial in but by that point we're dealing with PSTN which may be out of scope of user requirements for WebRTC.

https://www.relayuk.bt.com/how-to-use-relay-uk/relay-uk-for-hearing-people.html has more info on the prefix (for going from voice to text).

@RealJoshue108
Copy link
Contributor Author

Thanks for the update @JWJPaton - thats totally fine - please do review the text in main and make sure that it reflects your thinking. If these are useful requirements/notes or whatever, I'm fine with including them as long as we are clear of what we are potentially asking WebRTC to support.

@RealJoshue108
Copy link
Contributor Author

@JWJPaton We need to discuss this tomorrow on the call - as I'm not sure how to frame the issue clearly.

@jasonjgw
Copy link
Contributor

Does this apply to Web-only RTC applications? Do we propose to require that they all connect to the PSTN (i.e., "traditional telephony" networks)? That seems unreasonable to me, but if they do connect to the PSTN at all, then this should bring with it accessibility requirements.

@RealJoshue108
Copy link
Contributor Author

It would only be for WebRTC apps. I'm thinking we may drop this, and am increasingly not convinced that we have specified it correctly. I'd be happy to drop this until we work out the detail for a future version of the RAUR.

I'm going to suggest today that drop the 12d req - and leave the note to flag the issue of a 'complex set of user actions should not be required to connect relay services'. So something like:

"To successfully connect relay services should not require a complicated sequence of user actions. Currently, in the UK to successfully receive a relay call using a mobile app, a deaf user needs to toggle between the relay app and the built-in telephony app. If the incoming call is a relay call, the user must immediately activate an app, otherwise the call may be lost. The party calling the deaf user provides a prefix to connect to the relay center. If the calling party does not use a prefix for the relay call, then the call with not have text relay assistance. This is different in the US for example, where the users of captioned phones have access to captioning on the go, for both incoming and outgoing calls. In this case, the other party just handles a regular call without requiring a prefix."

Do you think this new note is clearer?

@gunnarhm
Copy link

It would be quite natural for relay services of all kinds to have connection with the user by WebRTC.
Then, it would be a matter for the WebRTC app to link the relay call leg with the call that needs relaying.

(this is not the way it is done now in most countries. In most cases, the call to be relayed is routed through the relay service, and that is causing all problems with special prefixes or number series etc, and limitations to only handle PSTN and traditional mobile calls. That is a rapidly vanishing part of the calls that requires relaying, so it would be more accessible to let the user device handle the link between the call and the relay service.

The problems with that is what made the UK connection to text relay a bit complex for the user. I think the traditional phone calls in mobile phones have limitations in how well they can be integrated with apps.

It is maybe not so relevant to describe the current situation in UK and USA, but merely have the first sentence of the Note as the requirement and drop the specific information about how it is done today.

So, my proposal is that the topic is text and video relay services, and the requirement is: "To successfully connect video or text relay services should not require a complicated sequence of user actions."

@WDannels
Copy link

WDannels commented Apr 28, 2021

the word "functional equivalent" come to my mind... i am not familiar with the PSTN... suggest anyone to read the paragraph under "instant connection to telephone service"... (as well as reading the whole web page may be helpful when drafting...) https://www.nad.org/about-us/position-statements/position-statement-on-functionally-equivalent-telecommunications-for-deaf-and-hard-of-hearing-people/

@RealJoshue108
Copy link
Contributor Author

Discussed by RQTF in April https://www.w3.org/2021/04/28-rqtf-minutes.html

@RealJoshue108
Copy link
Contributor Author

RealJoshue108 commented May 5, 2021

Those changes are now in main.

@ruoxiran ruoxiran transferred this issue from w3c/apa Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants