Changes to clause 13.2: Access to relay services (from clause 13.9.1 of TR 103 708)

added RTT label

marked this issue as related to #56 (closed)

marked this issue as related to #260 (closed)

The current wording in TR 103 708 is

13.2 Access to relay services
Where ICT systems support two-way communication, and the system is specified for use with relay services,
access to those relay services shall be supported for outgoing and incoming calls relative to the relay service user involving: voice, RTT, or video, either individually or in combinations supported by both the relay service and the ICT system.

NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access by persons with disabilities.

NOTE 2: The system may be specified as needing to work with relay services by, for example: procurers, regulators, or product specifications.

A wording improvement proposal is:

13.2 Access to relay services

13.2.1 Relay service basic access
Where ICT is or contains a communication system supporting continuous bidirectional communication, and the system is specified for use with relay services,
access to those relay services shall be supported for outgoing and incoming communications involving: voice, RTT, and video, either individually or in combinations supported by both the relay service and the ICT system.

NOTE 1: The purpose of this requirement is to achieve functionally equivalent communication access by persons with disabilities.
NOTE 2: The system may be specified as needing to work with relay services by, for example: procurers, regulators, or product specifications.

13.2.2 One step connection of outgoing communications
Where ICT is or contains a communication system supporting relay service use,
invocation of a relay service in an outgoing communication establishment from the relay service user shall be supported to be done in a single user operation including providing the identification (number or address) of the communication target.

13.2.3 One step connection of incoming communications
Where ICT is or contains a communications system supporting relay service use,
invocation of a relay service in an incoming communication establishment to the relay service user shall be supported to be done in a single user operation, where the communications user who want to reach the relay service user makes use of an identifier (number or address) referring to the relay service user.

13.2.4 Establishment of modality, language and action directions in relay service communications
Where ICT is or contains a communications system supporting relay service use,
the communication system shall support methods for automatic negotiation of preferred modality and language of the relay service user, including detailing this information for production versus perception of communication contents including indications of on which modalities the relay service actions are wanted.

13.2.5 Relay service support in conference communications
Where ICT is or contains a conference communication system,
the system shall enable connection of relay or modality transcoding services providing translation or transcoding of the conference contents to sign language, RTT and voice.

marked this issue as related to #311 (closed)

added Relay services label

removed RTT label

I have removed the RTT label as the primary scope is entirely about relay services, not RTT.

Formatted headings to bold in the proposal above and added a couple of words in 13.2.1 explaining incoming and outgoing directions.

I propose an editorial change to 13.2.1, to add "communication" to system in the second precondition (highlighted below in bold).

13.2.1 Relay service basic access

Where ICT is or contains a communication system supporting continuous bidirectional communication, and the communication system is specified for use with relay services,
access to those relay services shall be supported for outgoing and incoming communications involving: voice, RTT, and video, either individually or in combinations supported by both the relay service and the ICT system.

I agree with 13.2.2 and 13.2.3 as proposed.

I'm not sure about 13.2.4. In my view requiring "automatic negotiation" is too much of a requirement, given that it implies that there is a standardized way to store and expose user preferences for modality and language, that can then be used for negotiation. For me the user need is to be able to setup modality and language, and the "automatic" part could be considered a best practice.

My proposal would be:

To reword the requirement so it mandates only setting up modality and language. For instance, "... shall enable the user to define the preferred modality and language of the relay service".
To add a note explaining that it is best practice if the communication system provides automatic negotiation based on the user's profile.

I agree with @martineznorm that the requirement should be simplified to require a negotiation of the needed modality and language.

This negotiation should be done using the settings in user profile specifying the preferences regarding the preferred communication modality and language.

However, those preferences should not be specific to relay services. They are also needed for delivery of accessible emergency communications.

I agree with 13.2.5 as proposed.

mentioned in issue #311 (closed)

marked this issue as related to #376 (closed)

There is a standard for negotiation of modality and language when setting up a communication. It is IETF RFC 8373 " Negotiating Human Language in Real-Time Communications" https://datatracker.ietf.org/doc/html/rfc8373

It is detailed with possibility for different preferences in the different directions.

I think though that it is also important for the relay user to be able to specify a service address for a favourite relay service, and then it would likely be best that that service address leads to one of the main types of relay services.

There are disabilities and corresponding relay services which are not covered by the language and modality negotiation. These are the speech-to-speech relay service, the cognitive support relay service and the lip-speaking service. I assume that they need to be invoked by the user by using a configured service address for the invocation, possibly with some additional parameter for the desired detailed type of service.

A proposal for both requirements and tests for relay services and their use is linked and attached here. To be used as a combination of 13.1 and 13.2 and their tests if accepted.

Relay service proposal for 13.1 and c.13.1 -Online file for adding comments and see latest status

13.1_on_relay_services.docx - For download the file as it was when publishing this comment

marked this issue as related to #310 (closed)

marked this issue as related to #306 (closed)

mentioned in issue #414 (closed)

I have added many comments to the document "Relay service proposal ..."

In summary, the proposal goes into the correct direction but needs many modifications and contains too many accessibility requirement. The document with my comments can be found in Teams: (https://etsihq.sharepoint.com/:w:/r/teams/STF614/Shared%20Documents/General/Working%20Documents/13.1_on_relay_services.docx?d=w284bd5feedbf4d3080f1231d7c3683b5&csf=1&web=1&e=BUDZUi)

13.1_on_relay_services.docx

The comments are now answered and modifications done. Two requirements about caller identification were questioned. I think they are among the essential accessibility requirements on use of relay services and therefore kept. The relay service clause may need an introduction explaining some assumptions done in the subclauses. Since the requirements are on a high functional level, a number of configurations can be imagined of the combination of communication system, relay service and communication client. It may be hard to follow the requirement clauses if the reader has one specific view of how a relay service is configured and operates. I think it is time to review the result now and check if the comments can be deleted and the changes accepted.

At least two topics are not covered in the current draft. We need to consider if they should also be added.

Queue information or continued calling tone until the relay service is invoked and ready to operate.
ES 202 975 is only mentioned in a note. Should it rather be a normative requirement to comply with ES 202 975 (which e.g. contains requirements on rapidity of answering and conversion)?

The proposal that is linked in the above comment is fatally flawed and has no prospect of being accepted! It fails to meet any of the three essentials that need to be present for all requirements in EN 301 549:

Containing no unclear terms used in the requirement which make the exact scope of the requirement unclear
Precise scoping that makes it clear who is expected to ensure that the ICT mentioned in the scope meets the requirement
The availability of well-established and accepted ways in which it is possible to meet the requirement. W3C looks for multiple examples where the requirement has been met in trial and deployed systems using different technologies before approving a new Success Criterion. Although we may not have any formal obligation to mimic the W3C approach, the lack of any known demonstrations of working systems that are able to meet the requirement is a fundamental weakness for such a new untried system behaviour.

Failing to meet the above pre-requisites leads to impossible-to-resolve uncertainties in the requirements and their tests. In none of the requirements is it clear who has to do what in order to achieve the expected behaviours. This immediately leads those providing user equipment, communications services, and relay services to wonder what, if anything, are they obliged to do to ensure that the behaviour described in the requirement is met. All three of these groups might believe that it is the sole responsibility of one or both of the other two groups to do something to ensure that the requirement is met. This could result in nobody doing anything! Alternatively, two or three groups might make changes to their product or service to attempt to meet the requirement. This could easily lead to the different approaches actually conflicting with each other, resulting in some potentially very undesirable outcomes!

To further illustrate the unsuitability of the proposal, there are endless examples of uncertainties that appear in the proposed tests for the requirements. These appear as soon as you look at the pre-conditions of some of the tests.

Example 1

One test says

Step 1: Make settings for the user of the relay service containing relay service address and type, and the preferred languages and modalities of the user including their directions.

This immediately exposes the first uncertainty – where are these user settings stored (and what entities are supposed to act on them). Are they settings stored in the phone, in which case what mechanisms exist to communicate those settings to the communication service so that the service can initiate a connection to the relay service when the desired single-step connection is attempted? Or is the phone itself supposed to take full control over the setting up of multiple connections in a multiparty call? Also, are there standards for how the user settings are formatted so that will be understood by services or do phones have to initiate special connection procedures to setup a multiparty call between the user, their designated relay service, and the person the caller is trying to reach. We, and those trying to carry out the tests, have none of the answers to these questions as there are no well-established ways in which such settings are stored and accessed from phones, and there are no examples where the desired behaviours have been demonstrated to work in an operational communication service/relay service environment. Perhaps the settings are in the communication service in a record associated with the user, or maybe they are in the relay service itself – we have no idea, and those trying to meet the requirement and those trying to carry out the test also have no idea where to look for the settings that they are supposed to set.

Example 2

In another test, Procedure step 1 says

Initiation: A communication session is initiated from communication client C2 to communication client C1 that is specified for use with relay services and the communication is answered so that the relay service is invoked Where does a monitoring authority go to find someone whose phone "is specified for use with relay services", so that they can get that person to agree to receive an incoming communication as part of the test? I would imagine that when someone signs up to use a relay service their phone becomes "specified for use with relay services", but typically that sensitive data would be private and not available to people undertaking accessibility testing for a monitoring authority.

I believe that the only type of requirements that it is realistic to make are:

that a person who is registered with, or in some other way entitled to use, a relay service is establish a call to that relay service (with that call meeting the accessibility requirements for RTT or total conversation calls as specified in the scenarios);
that a person who is in a call with another party is able to add their designated relay service to create a multiparty connection between the three parties (and possibly be allowed to terminate that connection to the relay service if that is a useful feature). Even this requirement is a little questionable as it relies on multiparty RTT, and it is not clear to me whether there are clear and well supported standard communication behaviours for multiparty communication that can be relied on always being available.

So, we need a new much less ambitious proposal for "Access to relay services" if we are to have any prospect of getting it accepted as suitable replacement for the requirement in EN 301 549 v.3.2.1.

A new simplified version of clauses 13.1 and 13.2 about relay services is available in the Teams area at
13.1-13.2 Relay service

The proposal is still very unclear regarding who or what is responsible for enabling the desired behaviours to happen - this needs to be known, or nobody will be able to determine what if anything they are responsible for.

13.1.2 says that a communication system "shall provide to primary users of the communication system the ability to specify that relay services are to be invoked in a communication" but where and how might that ability be exercised - triggering something that resides in a phone, or triggering something that resides in the service, or some combination of these things (or is it the relay services that have to take action)?

Right, it is by actions in the user equipment that the user can indicate how the communication shall be handled. But the communication system and the relay service acts on the selections. See the document for proposed changes and explanations.

Bunch of comments and edits left in the draft.

Thanks,
I have answered the comments and made changes in the document. A document in Teams provide more explanations.
Relay Service Explanations

Great

is ES 202 975 a voluntary standard or is it required throughout Europe by some legislation?

I notice that (although ES 202 975 is full of requirements (SHALLs) this provision about call invocation that you cite (6.13) auto connection is a SHOULD.

Would it be a should in EN 301 549 as well?

ES 202 975 is voluntary. Not even relay service provision is mandatory in Europe. It is a Should for them in EAA and EECC. ES 202 975 is going to be revised but a bit late for the EN. And M/587 requires us to require relay services to be accessible. They are not accessible without a proper invocation method - either automatic or manual - The formulations or the preconditions in the proposal show the weakness and say that if a user is provided with the right to access a relay service, then it shall be accessible. So the SHALLS are ok.

What do you mean by "a proper invocation method"? Without defining any special "invocation method", any user should be able to make a standard call to their chosen relay service. This is an accessible way to access the relay service, just as calling anyone else via RTT/total conversation is accessible.

I agree that it would be extremely beneficial if an automated method to simultaneously call the relay service and the person with whom you wish to communicate were available. This would make the process much more usable, but the manual way of calling a relay service is equally accessible.

No, what needs to be provided for a communication service to be accessible is that you can do what others do with the service.

They call destinations by user identifiers (often numbers) of the destinations.
Their caller identifier is presented to users they call, so that these users can call back.(if you do not select anonymous calling)
They can get incoming calls from other users using their user identifier.
They can communicate with real-time media
The user identifiers can be stored in contact lists and used from there.

These are the very basic functions included in what is a real-time communication service that also must be satisfied even if you need support by a relay service to convert the modality of the communication.

There has been so much suffering by relay service users who have been provided with just modality conversion and not the other parts of communication services.

A classical example of something that the limited three-step calling through relay services which is too common has caused is that many customer services and similar organisations are only reachable by a method where you call them and either leave a number to be called on, or just accept to be called on the number you call from. That is not possible for 3-step relay calling.

This has been the only way to reach Swedish health care in many regions, causing a lot of problems for relay service users.

There are also other functions which should be included in the list.

6. Be able to call premium rate calls and be charged for them.

7. Be able to use the supplementary services.

Have the same user identifier (number) for both relayed calls and not relayed calls.

USA, The Netherlands and Switzerland have in some of their relay services taken a first important step to be accessible. They have arranged something that looks as a separate communications provider for relay service users, which hands out numbers from a specific number series which can be used for calling and be called and be connected through relay service when the other party in the call is not a primary user of the same kind of relay service (when the users are expected to be able to communicate directly.

That model solves the requirements 1-5 above, and that is good. But 6,7, 8 and a couple of other functions provided to mainstream users are not provided through these types of systems. A bit more can be done to achieve accessibility to real-time communication services.

I do not think that your analysis exactly captures the underlying issues related to relay services. Users with disabilities can do all of the items 1 to 5 in exactly the same way that all other users can. So, in terms of setting up a communication channel, nothing special is needed for any category of user. The problem is that when the call is connected the people at each end are not communicating in a way that the other person at the other end can understand! The same problem might occur within a multi-lingual country when a person only speaks Catalan, and the other person only speaks Spanish, or one person only speaks Flemish and the other person only speaks French.

What relay services provide is a service that takes what one side communicates and present it in a way that the other side can understand. Deaf users will have their communication barrier removed by involving a relay service in the communication, however easy or difficult it is to do. I do not think a Catalan speaker will have the benefit of any (free) service that will enable them to communicate with a Spanish speaker!

I'm not trying to argue against having relay services be as easy as possible to access and use, but it is not really correct to try to argue that it is essential for this to be very easy to provide parity with other users - there is no real direct comparison other than where language barriers are encountered by users who would not be classified as disabled because of their limited language skills.

The method that you describe as being used in the USA, The Netherlands and Switzerland is one that I can understand and is one that I could see being possible to introduce without having to make unspecified modifications to call set-up procedures at the user and service levels. But even though this has been shown to work, I presume that all parties in the communication are all supporting a common and agreed underlying way of establishing each communication. At the moment, there is no agreed standardised way in which this can be done in Europe. So I still have major reservations about several of the requirements in clause 13.2.

For example, when the introduction says that:

"The primary users of an ICT communications system who are being provided with the possibility to communicate with support of relay services in one communication session may want to communicate without support of the relay service in another communication session involving the same ICT communications system.

this simple sounding option opens up the question how does the handset manufacturer handle those two options. The handset must issue two different types of call-setup requests to the connected communications service. In such cases:

How will they know how to formulate such requests in the absence of any agreed standard?
If the handset manufacturer decides what it will send in these two different scenarios, how can the service interpret these differently formulated requests in the absence of an agreed common standard?
If a communication service manages to interpret the meaning of the call request, what actions do they then invoke?
a) Multiple instances of point-to-point connections that they use for all other calls, or
b) some possibly specialised variant of a multi-party call that is not yet be well proven in deployed RTT communication services?

I really do not see how the ICT referenced in a pre-condition can, in the absence of any agreed standardised way of interacting, know whether it has done what is necessary to achieve the requested outcome when the outcome will be dependent on clearly specified interoperation between handsets, communications services, and relay services which currently does not exist.

I am sorry that right now, I am restructuring the proposal in the file 13.1-13.2 Relay service to clearly put requirements for the conversion on the relay services and for the access and invocation on a communication system.

And we may need to accept that that communications system is not in all cases a mainstream communications system, but one specifically made to handle the invocation of relay services, and possibly only having primary relay service users registered.

You say that any relay service primary user can get requirements 1-5 fulfilled with any mainstream communications system today. I see that requirement 5 needs to be modified to make it clear. So, here are the requirements again with the order of 4-5 swapped.

Users who have no or limited use of voice communication can get access to voice communication services when the following requirements are fulfilled for them, the primary users of relay services:

They call destinations by user identifiers (often numbers) of the destinations.
Their caller identifier is presented to users they call, so that these users can call back.(if you do not select anonymous calling)
They can get incoming calls from other users using their user identifier.
The user identifiers can be stored in contact lists and used from there.
They can communicate with real-time media and get conversion of modalities or communication support when needed by a relay service included in calls being set up by the features described in requirements 1-4

This has been implemented in a few countries in documented ways. In my view we can require it. Another issue is how far we can go with the requirements 6-8 above.

Certainly the first four items in the list describe the situation for all callers and all calls using a communication service. The involvement of a relay service during call setup and the ability of the relay service to convert between modalities is clearly not standard for all users and all communications services.

I'm aware that this has been implemented in a few countries, and this can only be done if all parties involved in the communication are following the same documented ways to do this. The problem is that, at this stage it is not certain:

whether the way that this has been implemented in different countries is identical;
what happens when calls are made to and from other countries that have not adopted the same, or any, way of supporting the setting-up of a three way call.

The sort of problems that will arise is that a handset manufacturer will not want to ship a phone that has the call initiation procedures for RTT-only and RTT + Relay service built-in to a country B where the capability of making such calls does not exist, or where the way in which this capability is implemented is different to the way that it is implemented in country A (which is the capability that the phone manufacturer supports). There could be similar incompatibilities between phones, service providers, and relay services throughout Europe in the absence of a single agreed way to implement those capabilities throughout Europe. Having a requirement that requires a device manufacturer, service provider, or relay service to support a capability that is not used in the country in which these things exist will lead to a wide range of failures to meet the EN 301 549 requirements, because the ICT referenced in the requirement does not have the possibility to independently do so.

The only way that the current proposed 13.2 requirements could be included in the EN would be to have each requirement scoped to only be applicable in cases where all device manufacturers, comms service providers, and relay services support a commonly agreed set of standards. This would mean that, if applied at the current time, these requirements would not be applicable in any countries outside those in which agreed ways of meeting these requirements have already been rolled out. Evan then, the desirable future that these requirments represent will only be fully realised when all of the involved parties implement the same Europe-wide, or preferably world-wide standards that ensure that these capabilities will always be met.

Loïc's earlier very simple proposal is one that all devices, services, and relay services should be able to meet. Re-scoped versions of all the currently proposed requirements could be included, but they would not have much impact until future agreements to implement a common set of technical standards that would define the means by which the required behaviours could be achieved.

I have edited the proposal further and divided the requirements per role in the chain of functional entities.

See 13.1-13.2 Relay service

I have introduced a functional element "Relay service communication system connecting primary users, secondary users and relay services" and placed the requirements for access support on that system. That reflects a conceptual structure that all systems allowing accessible use of relay services makes use of.

The idea is to keep the mainstream communication services clean from extra requirements for primary users if they do not get obligations from authorities to support primary users in their systems. They would only need to provide interoperability with the relay service communication system, and provide normal communication functions to the users.

For text relay services it will be a natural desire to be able to use the coming mainstream RTT functionality for relayed calls as well as for non-relayed calls. For that to be provided in a convenient way, it will be desirable to introduce some extra functions in all mainstream terminals so that they can be used conveniently by primary users. That can be seen as letting the · "Relay service communication system connecting primary users, secondary users and relay services." co-reside with the mainstream communications system.

What would be desirable as extra function in the clients would likely be a place for storing an address to a relay service and a possibility to enable a button for call or answer including a relay service. And an action of that button involving standard communication functions.

For video relay users, it will be natural that their clients must be tied to other than the mainstream systems as long as they do not support video. Then they will have functions to require relay in their communication with the "Relay service communication system connecting primary users, secondary users and relay services" and their calls will need to interoperate with the mainstream communications systems. As they do today where they exist.

I think it is not up to us to specify the exact technical procedures, but just know that what we require is realistic and within what can be said be to provide accessibility to voice communication services.

It strikes me that there are many situations where one party wants to involve a third party in a communication, and that it is not unique to relay services.

For example:

Including a spoken language interpreter (e.g. English to Chinese)
Including a lawyer

As such, invoking a third party into a call isn't really an Accessibility issue in itself. As Mike pointed out, calling to a relay is no harder than calling any other service, and no less accessible than it is for any other caller.

The goal of providing a relay service is to make communication services accessible to those who have no or limited use of its mainstream communication modality -speech. That implies to be allowed to use all or most features of the communication service in at least similar ways as other users. And it means possibilities to call and be called just as easy as others, and then communicate smoothly once connected.

It is not at all sufficient to say that it is possible to call the relay service. It is the intended destination of the call that needs to be nearly as simple to call as for calls between mainstream users.

This need has been specified in the relay service ES since 2008, but too few countries have implemented it. One of the first making an effort in that direction was UK, where the text relay service Typetalk was surrounded by network functionality that made calls with a specific prefix be routed to the relay service with an indication to the service about what the final destination number would be.

That required the mainstream users to include that prefix when calling, so it was a bit from the goal but anyway much better than the too common three-step-invocation method.

Is that a sufficient explanadion?

I still don't think that the latest proposals overcome some very fundamental issues:

Phone suppliers need to know how their UI that, that would be required to have alternative UI options to setup a simple call or a call that automatically connects a relay service can signal that user intention to the network.
Network providers need to know how to respond to requests to establish three-way calls that an attached phone signals.
Relay services also need to understand how to respond to three-party call-setup requests that are delivered to them from the network.

Phone suppliers, network providers, and relay service providers will all need to work to a common set of mutually agreed standards otherwise nothing will work and:

the phone UI might work on some networks, but not others,
some networks might be able to respond to the requests from some brands of phones, but not others, and - relay service providers wouldn’t know what to do!

As there are only very isolated implementations of these functionalities in Europe, and there is no certainty that these are compatible with each other, there would need to be extremely specific pre-conditions (about the existence of mutually agreed three-party call setup standards between end-user devices, services, and relay services). Having pre-conditions that, on day-one at least will not be met by 90% of phones, services, and relay services does throw into doubt what the value of such proposals might be.

Mike, when you say that you accept Loic's proposal above, do you then also include Loic's acceptance of 13.2.2 , 13.2.3 and 13.2.5 which make 13.2 contain the most important basic requirements for access to relay services?

If so, I think we can soon reach agreeable text proposals.

No, what I said was that I agreed with was a Loïc's replacement for the original requirement. I would see it as a 13.2 Relay service access, not a 13.2.1.

Loïc gave it a number and title that were consistent with your multi-part approach. I believe that the other parts are all highly questionable in terms of how they could be correctly scoped, but this single requirement has no equivalent problems.

Yes, 13.2.1 is a first good step. Here it is again with Loïc's wording:

13.2.1 Relay service basic access

Where ICT is or contains a communication system supporting continuous bidirectional communication, and the communication system is specified for use with relay services,
access to those relay services shall be supported for outgoing and incoming communications involving: voice, RTT, and video, either individually or in combinations supported by both the relay service and the ICT system.

. . . . . . . . . .

That was mainly intended to take care of the accessibility requirements during the human communication in different modalities. But that is just one part of the term "access". It mentions incoming and outgoing communications, but it does not clearly enough require that the communication establishment procedures used between users in the ICT in general shall also apply when a party is a primary relay service user. That part of the access requirements is needed and are included in the continuation of 13.2. in 13.2.2 and 13.2.3 in: #101 (comment 15106) above, and further elaborated in the document 13.1-13.2 Relay service

Maybe we can as a first step improve 13.2.1 to clarify that the communication establishment shall address the users. But that risks to have triple requirements in the same clause.

Here is anyway a proposal:

. . . . . . . .

13.2.1 Relay service basic access

Where ICT is or contains a communication system supporting continuous bidirectional communication, and the communication system is specified for use with relay services,

access to those relay services shall be supported for outgoing and incoming communication using the identifiers of the communication clients in the communication establishment procedures and involving: voice, RTT, and video, either individually or in combinations supported by both the relay service and the ICT system during the communication.

. . . . . . . . . . . . . .

I see two problems with this condensed requirement:

It does not really require the identifiers to be used directly in the communication establishment as usually done in communication services. They may still be conveyed in human communication with the relay service Communications Assistant and that was what we wanted to avoid. More rewording is needed.
The media handling requirement is more strict than what is needed in some services. Or it requires an unexpected solution: If you want to let a voice communication service A to be accessible to sign language users, these users need to have communication clients supporting video. But they cannot be directly supported by the communication service A. Therefore they must be subscribers of another communication service B supporting video and communicate in video with the relay service. Service A and Service B then need to have interoperability for voice communication so that the communication between the three parties can be established.

So the solution is that the requirement can only be fulfilled for the extra service B and service A just needs interoperability in speech with Service B.

The situation is different for text relay services when RTT is supported in mainstream communication services. Then the media requirements can be fulfilled by service A, but instead more communication establishment requirements are placed on service A to enable the relay service connection. So it may be easier to view that situation also as if the primary text relay service users were users of a service B embedded in service A.

In the document 13.1-13.2 Relay service , the intention is to amend these problems. #101 (comment 15106) only acts on problem 1.

We can try to get solution to problem 2 also into the wording of 13.2.1 above, but I think it is better to accept the complexity of this issue and go to the document 13.1-13.2 Relay service .

Anyway, taking the formulation of 13.2.1 above one step further can result in this proposal:

13.2.1 Relay service basic access

Where ICT is or contains a communication system supporting continuous bidirectional communication, and the communication system is specified for use with relay services,

access to those relay services shall be supported for outgoing and incoming communication relative to the primary users of the relay services using the identifiers of the secondary user communication client and the primary user directly in the communication establishment procedures and during the communication involving: voice, RTT, and video, either individually or in combinations as supported by the individual communication party combinations.

NOTE1: Using identifiers directly implies using them in the user interface of the communications client at the time of initial communication establishment

NOTE2: Situations where the primary user requires support of other media than the ICT communication system provides can appear and be solved by the primary users being users of another interoperating ICT communication system providing the extra media communication between the primary user and the relay service.

This "one step further" introduces a whole range of issues that relate to three-party communication that immediately introduces uncertainties about how the desired outcome is achieved and who is responsible for ensuring that it is achieved.

This is a completely different requirement that significantly extends the scope of the requirement into uncertain territory. The original proposed wording is a requirement that is capable of being met. The additional capabilities that are included in your steps further may well be highly desirable, but it is not obvious how such capabilities can be required as universal features of all communications systems that have compatible relay services.

Right. It extends the scope to require accessibility to not only the human communication in the communication but also to the other essential elements of communication services - the calling and being called in similar ways as other users. Without that very little is achieved.

The extended version is possible to meet. But the requirement gets clearer by dividing it in subclauses. And then it can be divided between the mainstream communication service and a relay invocation service. The relay invocation service can be separately provided as in the US relay service invocations system and the Swedish trial. It can also be embedded in the mainstream communication service. I have tried to express that in the separate document. 13.1-13.2 Relay service ,

Are relay services Assistive Technology? And if so, what does that mean to the relay service clauses?

I read the new assistive technology definition from #171 (closed) , saying:

"any item, piece of equipment, service or product system including software that is used to increase, maintain, substitute or improve functional capabilities of persons with disabilities or for, alleviation and compensation of impairments, activity limitations or participation restrictions"

and I found that it matches relay services by its inclusion of "service" and the purpose of substitution of functional capabilities. There is a mentioning that software must be included, but it is not clear that it is the software that does the substitution. So even human interpreters can likely be involved and be part of the Assistive Technology.

There is even a new note to the definition saying:

"Note 3: Where ICT does not support directly connected assistive technology, but which can be operated by a system connected over a network or other remote connection, such a separate system (with any included assistive technology) can also be considered assistive technology."

So from that it seemed quite clear that relay services are Assistive Technologies.

But then I checked the EN draft for how Assistive technologies are referenced. In most cases it is in situations where the preconditions exclude relay services, so, no problems with them.

But in 11.5.2.4, I saw nothing hindering that it apply to relay services, but the effect is confusing:

11.5.2.4 Assistive technology

Where ICT is or includes assistive technology,
the assistive technology shall use the documented platform accessibility services.

It does not seem relevant to force the relay services to use the documented platform accessibility services in its remote position.

Questions:

Shall we regard relay services to be assistive technologies as the definition seems to indicate?
Is there something in the preconditions to 11.5.2.4 that I have missed that makes it not apply to relay services?
Do we need to do something to exclude relay services and other network located assistive technology from 11.5.2.4?
What else is the effect of considering relay services to be assistive technology or not?

there is are commas missing in the definition that causes the confusion. The "including software" is supposed to relate to everything in the list -- not a condition on service. Here is the correct language.

"any item, piece of equipment, service, or product system, including software, that is used to increase, maintain, substitute or improve functional capabilities of persons with disabilities or for, alleviation and compensation of impairments, activity limitations or participation restrictions"

So I would say Yes - Relay services would fall into the definition of a technology that is assistive to people with disabilities -- or "an assistive technology".

I'm left wondering what is a "product system". "Product" I understand, but "product system" is an undefined and unclear concept to me.

I do not think that the comma is the cause of Gunnar's understandable confusion. I agree with you that a relays service should be considered to be an "assistive technology". Which leaves us unsure to what extent clause 11.5.2.4 applies, or should apply, to relay services. The key issue is that we don't explicitly define "documented platform accessibility services". The requirement was written primarily to apply to software that runs on a clearly define "platform", and that this platform will have clearly documented accessibility services. There have been ongoing questions about how this term should be interpreted.

A relay service is a rather complex entity. At one level it is a communication endpoint, in which case the relevant platform would be the whole communication infrastructure. To my knowledge communications services don't explicitly document accessibility services that can be used by entities that connect to those networks. At another level the relay service will have software applications within it and those software applications would need to meet 11.5.2.4 just like any other software application. At the highest level the relay service incorporates the humans that are usually involved in operating the service - it is hard to identify a "platform" that is relevant to this aspect of a relay service.

I think that what we need is a definition of "documented platform accessibility services" that makes it clear that we are primarily using the term in the context of software using the accessibility service of a software platform. If this is clearly done, then I think that Gunnar's concern about how 11.5.2.4 should be understood in terms of relay services may disappear.

We may also need to separately define what we mean by documented, as it is used infrequently in the EN when applied to things other than platform accessibility services.

marked this issue as related to #274 (closed)

Issue #274 (closed) makes a proposal for a definition of "documented accessibility services" which looks very promising. I have marked that proposal as "Proposed for approval".

A new clean and simplified version is available in 13.1 and 13.2 an C.13.1 and C.13.2 Relay Service - v2

added Included in EN label

All relay service-related issues raised by @hellstromgu should have been addressed in the latest edition of a completely revised clause 13.1 that will appear in ETSI EN 301 549v008.docx which will be linked to issue #219 by 1st February 2025.

This issue can be closed.

closed

Changes to clause 13.2: Access to relay services (from clause 13.9.1 of TR 103 708)

Designs

Child items ...

Activity

Example 1

Example 2

Changes to clause 13.2: Access to relay services (from clause 13.9.1 of TR 103 708)

Relates to

Activity

Example 1

Example 2