Subject: Re: [Slim] Translation Quality or type - or service provider

From: Eric Burger <[email-masked]>
Date: Tue, 07 Jul 2015 16:20:31 -0400

I don't see how either way is enforceable. If we say the PSAP has to take the caller's translation service, any sensible PSAP will feel free to ignore it, whether due to cost, liability, or protecting against the PSAP being the source of a DoS attack. Conversely, if a particular PSAP could use a hint for a translation service, it would be handy for the caller to provide one. 

Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade

-------- Original message --------
From: Brian Rosen <[email-masked]> 
Date: 07/07/2015  2:20 PM  (GMT-05:00) 
To: Randall Gellens <[email-masked]> 
Cc: Eric Burger <[email-masked]>, [email-masked] 
Subject: Re: [Slim] Translation Quality or type - or service provider 

In general, the PSAP wants to use it’s bridge, and NOT have the translation service use its bridge.  There are clearly circumstances where the PSAP bridge cannot be used and we need a way to make sure the translation service’s bridge can be used.

Brian

> On Jul 7, 2015, at 1:56 PM, Randall Gellens <[email-masked]> wrote:
> 
> At 4:43 AM -0400 7/6/15, Eric Burger wrote:
> 
>>  > On Jul 6, 2015, at 3:24 AM, Gunnar Hellström <[email-masked]> wrote:
>>> 
>>> One reason for the need to convey a translation service provider URI is that the emergency service RFCs 6443 and 6881 forbids the calling user to invoke three-party calling.
> 
> The text there is saying that the best practice for a device initiating an emergency call is to disable services that could interrupt the call, such as call waiting and third-party calling.  If the third-party call is initiated before or in parallel with the emergency call, the text wouldn't apply anyway, and if the third-party call is initiated during the emergency call in order to better serve the user's needs, then this is exactly why the text uses "SHOULD" instead of "MUST."  The word "SHOULD" means that a client is supposed to follow the direction unless there is an overriding reason not to, and the consequences of doing so are understood.  Both of those apply in the case under discussion.
> 
> 
>> 
>> 6443 is informational and 6881 is a BCP. No problem to do something that works that is 'forbidden.'
>> 
>>> For example RFC 6443, chapter 13 says "Services such as call waiting, call transfer, three-way calling, and hold should be disabled."
>> 
>> Note the use of 'should.'  I do not think anyone will complain if one interprets this as, "Should be disabled, unless the user will die if she does not setup a three-way call with her translation service."
>> 
>>> If then the user is in a foreign language environment where the PSAP barely can have a clue on how to find the right relay service, and the user has a good relay service URI configured, well capable of handling the user's language and modality, what is then best?
>>> 
>>> 1) Break against RFC 6881 and 6443 and have the user terminal invoke the three-party call? The wording in these RFCs may be interpreted to have some room for such deviations.
>> 
>> Beyond the wording in the RFCs, there is a reason the IETF is not the protocol police. In retrospect, it may be safe to say the RFCs' suggestions are wrong.
>> 
>>> 2) Or convey the relay service URI to the PSAP for invocation.
>> 
>> Why not?
>> 
>>> 
>>> The discussion so far leads towards conclusion 1. It is ok for me, I just wanted it confirmed by showing the whole situation.
>>> 
>>> (there will always be complementing slow manual procedures, when the PSAP needs to figure out a reasonable way to handle the call, but this discussion is for the rapid automated way that should handle most cases.)
>>> 
>>> /Gunnar
>>> 
>>> Gunnar Hellström skrev den 2015-07-05 22:35:
>>>> Paul,
>>>> Yes, I agree that for most cases it is best that the party, who knows a service that will do the translation, does the invocation.
>>>> 
>>>> And, yes ,in that scenario the 3PCC method seems suitable.
>>>> 
>>>> My proposal to send the service provider URI together with the modality indications was for the case when there are strong policy reasons why one party would do the invocation, but little chance that that party would have access to an up-to-date information on available translation providers.
>>>> That could be the case for the emergency service calling in a multi-language environment, also including support for sign language users.
>>>> 
>>>> Since both you and Randall think it is not doable, we can try to use the principle that the party, who knows a service that will do the translation, does the invocation.
>>  >>
>>>> That brings us back to a need for more stringent language/modality negotiation in order to avoid both double invocation of services when one or none is required, and also avoid no invocation when one is needed.
>>>> 
>>>> Paul Kyzivat skrev den 2015-07-05 18:20:
>>>>> Gunnar,
>>>>> 
>>>>> I understand what you are suggesting, but I don't believe it is workable. This seems to mean that the caller would select the service while the callee would engage the service in the call if needed. Yet it is likely to be the caller who has a business relationship with the service, while the callee does not. Gets complicated quickly.
>>  >>>
>>>>> ISTM it makes more sense to first figure out what is/isn't possible without translation, and then for a party that finds a translation service beneficial to engage one. Then the only concern is that both parties don't independently try to introduce equivalent translation services.
>>>>> 
>>>>> For instance, a deaf caller might offer video media marked for sign language, and audio media on hold. If the answer doesn't accept the video, or doesn't indicate support for sign language, the caller could then conference in translation service, using the 3pcc transcoding model specified in rfc5369. (If that will take time, the deaf caller's UA could stream recorded media over the audio channel in the meantime.)
>>>>> 
>>>>> Or, to get fancier, it would be possible to use preconditions to defer alerting the callee until this is all sorted out.
>>>>> 
>>>>> My point is to let the participant who wants translation handle to setup of translation rather than depending on the other party to do something.
>>>> OK, it might be likely that both parties "want" translation, but one has better knowledge about how to get the required service and has business relations with the service. So then it is preferred that that party invokes.
>>>> 
>>>> Good
>>>> /Gunnar
>>>>> 
>>>>>    Thanks,
>>>>>    Paul
>>>>> 
>>>>> On 7/5/15 2:48 AM, Gunnar Hellström wrote:
>>>>>> Another opportunity would be to convey a URI to the service provider who
>>>>>> did (for mail) or can do(for real-time) the translation.
>>>>>> Then experience with different service provider's production could give
>>>>>> some idea of the expected quality.
>>>>>> I can see great value in that for the real-time case, when the calling
>>>>>> user has a favourite translator (e.g. relay service), and provides that
>>>>>> as a hint if languages or modalities in the call does not match. Then
>>>>>> the callee do not need to just take a service provider by chance that
>>>>>> seem to match the language/modality profile but can take the one
>>>>>> proposed by the caller.
>>>>>> 
>>>>>> After working with the needs for emergency services to work across
>>>>>> Europe for some time now, I think this is one of the few workable
>>>>>> solutions. The user expresses both the language/modality needs and
>>>>>> provides a URI to a favourite translation service provider, and the
>>>>>> callee tries to fulfill the language/modality needs either by a matching
>>>>>> original call taker or by invoking the proposed translation provider.
>>>>>> 
>>>>>> /Gunnar
>>>>>> 
>>>>>> 
>>>>>> Randall Gellens skrev den 2015-07-05 03:49:
>>>>>>> My recollection is that this was discussed in email prior to Dallas,
>>>>>>> but that's not important.
>>>>>>> 
>>>>>>> I am a strong proponent of keeping things as simple as possible,
>>>>>>> provided there is a way to extend them if experience shows that it is
>>>>>>> needed.  So, I think we should stick with the original suggestion of
>>>>>>> three values ("original", "human", "automated"). This is simple enough
>>>>>>> to be implementable and functional enough to be useful in providing a
>>>>>>> hint that may help the client choose the best version for the user. If
>>>>>>> we try and capture the various nuances of quality we will end up with
>>>>>>> a very complex mechanism that is unlikely to be any more useful in
>>>>>>> real life. Let's go with the simple approach now.  If, after some
>>>>>>> deployment experience we realize that we really do need extra
>>>>>>> complexity, we can extend the mechanism then.
>>>>>>> 
>>>>>>> At 4:29 PM +0100 7/3/15, Nik Tomkinson wrote:
>>  >>>>>
>>>>>>>> Thanks for the responses.
>>>>>>>> 
>>>>>>>> To deal with the issue with having only original/human/automated,
>>>>>>>> what about the following?:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> translation-type := type-token[ ";" "q" "=" qvalue ]
>>>>>>>> type-token :="human" / "automated"
>>>>>>>> 
>>>>>>>> where qvalue is a value between 0 and 1 with a default of 0.5 if
>>>>>>>> missing
>>>>>>>> 
>>>>>>>> for example:
>>>>>>>> 
>>>>>>>> Translation-Type: human;q=0.8
>>>>>>>> Translation-Type: automated;q=0.4
>>>>>>>> Translation-Type: human
>>>>>>>> 
>>>>>>>> The Translation-Type SHOULD NOT appear in the original
>>>>>>>> (untranslated) part but it SHOULD appear in translated content.
>>  >>>>>>
>>>>>>>> Having this missing from the original text helps identify which is
>>>>>>>> the source to be translated into further languages if the user mail
>>>>>>>> client allows.
>>>>>>>> 
>>>>>>>> This enables us to dispose of the 'original' value which didn't lend
>>>>>>>> itself well to being graded on quality.
>>>>>>>> 
>>>>>>>> The qvalue can be set by the sender or provided by the translation
>>>>>>>> service.
>>>>>>>> 
>>>>>>>> The draft suggests that:
>>>>>>>> 
>>>>>>>> "Additionally, interactive implementations MAY offer the user a
>>>>>>>> choice from among the available languages." so the qvalue may not
>>>>>>>> need to be bulletproof.
>>>>>>>> 
>>>>>>>> Comments?
>>>>>>>> 
>>>>>>>> Nik.
>>>>>>>> 
>>>>>>>> On 3 July 2015 at 09:46, Gunnar Hellström
>>>>>>>> <<mailto:[email-masked]>[email-masked]> wrote:
>>>>>>>> 
>>>>>>>> I see some value of this kind of parameter also for the real-time case.
>>>>>>>> The time is here when it can be possible in some situations to
>>>>>>>> select between using a low-cost automatic speech-to-text generation
>>>>>>>> and a higher cost captioned telephony or text-relay service (higher
>>>>>>>> cost for someone, not always the end-user).
>>>>>>>> 
>>>>>>>> But I agree that it is very hard to set good understandable values
>>>>>>>> on a parameter expressing the type or quality of this kind of service.
>>>>>>>> 
>>>>>>>> Gunnar
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Stephane Bortzmeyer skrev den 2015-07-03 08:49:
>>>>>>>> 
>>>>>>>> On Thu, Jul 02, 2015 at 11:09:30PM +0100,
>>>>>>>>   Nik Tomkinson
>>>>>>>> <<mailto:[email-masked]>[email-masked]> wrote
>>>>>>>>   a message of 109 lines which said:
>>>>>>>> 
>>>>>>>> type-token := "original" / "human" / "automated"
>>>>>>>> 
>>>>>>>> In many IETF working groups, when there is such a proposal, there is a
>>>>>>>> big discussion between the registryfull and the registryless
>>>>>>>> people. The first ones say there must be an authoritative list of
>>>>>>>> values (in the RFC or, better because more evolving, in an IANA
>>>>>>>> registry) so we can be sure of the interpretation of values. The
>>>>>>>> second ones say we can never capture all the nuances and subtleties of
>>>>>>>> the world in a fixed list.
>>>>>>>> 
>>>>>>>> Here, I am not sure that the only meaningful distinction is between
>>>>>>>> "human" and "automated". Some humans do a very poor job, too. One
>>>>>>>> could suggest:
>>>>>>>> 
>>>>>>>> type-token := "original" / "professional-human" / "amateur-human" /
>>>>>>>> "automated-first-generation" / "automated-artificial-intelligence" /
>>>>>>>> "automated-the-robot-in-hollywood-movies"
>>>>>>>> 
>>>>>>>> Or decide that it will be too complicated and we should instead
>>>>>>>> accept:
>>>>>>>> 
>>>>>>>> type-token := "original" / <free text>
>>>>>>>> 
>>>>>>>> Toughts?
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> SLIM mailing list
>>>>>>>> <mailto:[email-masked]>[email-masked]
>>>>>>>> 
>>>>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> SLIM mailing list
>>>>>>>> <mailto:[email-masked]>[email-masked]
>>>>>>>> 
>>>>>>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> Multiple Language Content Type Internet Draft:
>>>>>>>> 
>>>>>>>> <http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/
>>  >>>>>>
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> SLIM mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> SLIM mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>> 
>>> 
>>> --
>>> -----------------------------------------
>>> Gunnar Hellström
>>> Omnitor
>>> [email-masked]
>>> +46 708 204 288
>>> 
>>> _______________________________________________
>>  > SLIM mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/slim
>> 
>> 
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: attachment; filename="signature.asc"
>> Content-Type: application/pgp-signature;
>> 	name=signature.asc
>> Content-Description: Message signed with OpenPGP using GPGMail
>> 
>> Attachment converted: TiLand:signature 415.asc (    /    ) (028C4061)
>> _______________________________________________
>> SLIM mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/slim
> 
> 
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Progress is made on alternate Fridays.
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Jul 2015 17:00:34 -0400

Of course it’s not enforceable, but since there are a finite number of VRS providers, the PSAP community can prevail upon them to do the right thing.  The worst case, where there are two bridges, is annoying but not fatal.

What we need is clear labeling of what is requested, something we don’t have now, but slim will provide.

The current NENA documents say that the outgoing proxy server adds a Referred-By header to the call.  The PSAP may use the URI of the Referred-by to bridge in the referring party, which is the CA at the outgoing proxy of the VRS provider.  This works exactly the way the current U.S. regulations say it should work, where first a two way is established between the CA and the caller and then the call is extended as a 9-1-1 call.  It wouldn’t work as well in Gunnar’s environment where the SIP service provider isn’t the relay provider, but something similar could work.

For “direct routing”, where you don’t get the 2-way before a 3-way is established, the VRS provider (in the US) can still add the Referred-by, which would allow the PSAP to either use it, or it’s own choice of relay provider.  It’s a bit weird, in that there is no actual referral, it’s more of a “if you want me, here is how to get me”, but it would clearly work.

We might be better off with another mechanism that expressly states “A translation service is available at this URI”, which is the idea Gunnar has.  I think that is additive, not replacing the current proposed language tag mechanism.  You could imagine various forms of that which would include the source and destination language tags.  An out of country visitor might request translation to French, but if he is in Brazil, his preferred English to French service might not be helpful.

Brian

> On Jul 7, 2015, at 4:20 PM, Eric Burger <[email-masked]> wrote:
> 
> >>  > On Jul 6, 2015, at 3:24 AM, Gunnar Hellström <[email-masked]> wrote:
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2015 17:35:31 -0400

> For “direct routing”, where you don’t get the 2-way before a 3-way is established, the VRS provider (in the US) can still add the Referred-by, which would allow the PSAP to either use it, or it’s o…

ISTM that a problem with the NG911 approach is that the mechanism for 
setting up the relay call is entirely different from the way it is done 
for other relay calls. So it becomes a path-less-used and hence less 
tested. It would be nice if the same technique was used for everyday 
calls and emergency calls, so that it was a well tested path.

> We might be better off with another mechanism that expressly states “A translation service is available at this URI”, which is the idea Gunnar has.  I think that is additive, not replacing the curr…

I can see how that might work if limited to US VRS service, especially 
if only for emergency calls. In that case a common law/contract can be 
in place to ensure that the translation service will accept the call.

In the more general case, possibly where clients of the service have to 
establish a business relationship with each provider, it won't work very 
well.

It is also necessary that the invocation of the translation service be 
standardized so the entity invoking it knows how to do so. We hopefully 
will soon have something for VRS service in the US, but it doesn't work 
this way. And it is a long way from there to having a standard for all 
the different sorts of translation (relay) service.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Jul 2015 18:10:37 -0400

inline
> On Jul 7, 2015, at 5:35 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> ISTM that a problem with the NG911 approach is that the mechanism for setting up the relay call is entirely different from the way it is done for other relay calls. So it becomes a path-less-used and hence less tested. It would be nice if the same technique was used for everyday calls and emergency calls, so that it was a well tested path.
Yeah, but it IS very special.  There is often a separate queue of call takers (trained for 9-1-1), and they have to route based on location of caller, not of CA, so they need to REFER the call to 9-1-1.

> I can see how that might work if limited to US VRS service, especially if only for emergency calls. In that case a common law/contract can be in place to ensure that the translation service will accept the call.
> 
> In the more general case, possibly where clients of the service have to establish a business relationship with each provider, it won't work very well.
Why?  If you contract with Language Line, for example, they can handle n to m translation as long as English is either m or n for a significant number of n/ms.  I’m sure there are equivalents elsewhere.  So an English speaking caller could contract with LL to get what he needed, wherever he traveled.  If the caller supplies a URI, then it’s up to him to arrange contracts.  If the called party decides to use someone else, then it’s their contract.

> 
> It is also necessary that the invocation of the translation service be standardized so the entity invoking it knows how to do so. We hopefully will soon have something for VRS service in the US, but it doesn't work this way. And it is a long way from there to having a standard for all the different sorts of translation (relay) service.
Yeah, I agree we should have some kind of signaling standard, but that’s beyond what our current goals for slim.
When we finish, we can either recharter, or form another group to handle generalized “transcoder” signaling

Brian
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 08 Jul 2015 00:15:32 +0200

> Of course it’s not enforceable, but since there are a finite number of VRS providers, the PSAP community can prevail upon them to do the right thing.  The worst case, where there are two bridges, i…
We have a more complicated situation in Europe with all different sign 
languages and all different spoken languages, and usually, if there is 
any  VRS , they usually only translate between one sing language and one 
spoken language.
You are right, they are a finite number, but the correct selection must 
be done.
> The current NENA documents say that the outgoing proxy server adds a Referred-By header to the call.  The PSAP may use the URI of the Referred-by to bridge in the referring party, which is the CA at the outgoing proxy of the VRS provider.
Yes, I have seen that, and wondered how that step in the procedure 
works. Is it an application convention in NENA and EENA PSAPS to use the 
Referred-by information in that way, or is it a common SIP convention?
>    This works exactly the way the current U.S. regulations say it should work, where first a two way is established between the CA and the caller and then the call is extended as a 9-1-1 call.  It wouldn’t work as well in Gunnar’s environment where the SIP service provider isn’t the relay provider, but something similar could work.
The procedures should not assume that the user terminal is 
SIP-registered in the relay service. That makes it impossible to move to 
use of something that can be called mainstream terminals for users of 
relay services. There may be European services also, where the users 
seem to be SIP-registered in the relay service. We just must not 
document the proccedures as if that is a prerequisite. Rather view such 
relay services who also have registered terminals as if they are 
composed of a communications service part and a translation provider 
part. They are separate functions anyway.

The mechanism from chapter 9 in EENA/NENA specifications would work also 
for the separated architecture, with SIP provider and relay provider 
separate. The user might make a regular call that the SIP provider 
detects should go to the relay service. The relay servicedetects that it 
should be an emergency call and refers it back to the user to call 
urn:service:sos instead.

Hopefully, in most cases the terminal will instead be able to make the 
emergency call directly together with indications of languages and 
modalities and possibly the assisting service, so that that first Refer 
step is avoided.
> We might be better off with another mechanism that expressly states “A translation service is available at this URI”, which is the idea Gunnar has.  I think that is additive, not replacing the curr…
Right. The language tag is needed to try to match the live service in 
the PSAP, but if not successful, the service at the URI can at least 
help to get the call translated to a spoken language. In worst case 
there will also be a need for another translation between two spoken 
languages.

But I also had the other example of when I supposed that an URI would be 
needed, or that the call comes with a relay service ready invoked. That 
was for the cases when it is hard to express the needs in modality 
preferences. I think the speech-to-speech need is the most apparent. 
Someone said that we should develop tags for that kind of needs as well.
How can that be coded? Can we have a try to define it now?

Should it be an addition to the SLIM codes in SDP for audio? something 
like   humintlang-send=fr,type:sts   That should be interpreted as 
speaking french but with the type of speaking that usually requires a 
speech-to-speech service to support.
And the service would in its audio declaration  have something like 
humintlang-receive=fr,type:sts

Or should it go into a sip level field, including a URI to the service?

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Wed, 8 Jul 2015 17:02:20 -0700

At 12:15 AM +0200 7/8/15, Gunnar Hellström wrote:

>  The user might make a regular call that the SIP 
> provider detects should go to the relay 
> service. The relay servicedetects that it 
> should be an emergency call and refers it back 
> to the user to call urn:service:sos instead.

Ideally, the call from the user should be 
initiated as an emergency call.  Depending on the 
region, this provides priority call treatment, 
permits calls to be placed without an 
account/SIM, tells the originating client to 
include the various forms of additional data, and 
triggers various location functions.  If the call 
from the user is initiated as a normal 
(non-emergency) call, none of this happens in 
most environments.

-------------- Randomly selected tag: ---------------
To iterate is human; to recurse, divine.  --Robert Heller

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 09 Jul 2015 06:53:10 +0200

Randall Gellens skrev den 2015-07-09 02:02:
>>  The user might make a regular call that the SIP provider detects 
>> should go to the relay service. The relay servicedetects that it 
> Ideally, the call from the user should be initiated as an emergency 
> call.  Depending on the region, this provides priority call treatment, 
> permits calls to be placed without an account/SIM, tells the 
> originating client to include the various forms of additional data, 
> and triggers various location functions.  If the call from the user is 
> initiated as a normal (non-emergency) call, none of this happens in 
> most environments.
Yes of course the direct calling when the terminal detects the emergency 
number from the beginning is the preferred method.

But many relay services today sadly work with two-step dialling. First 
the user calls a number or URI to reach the relay service and then 
discusses with the communication agent what the final destination of the 
call is. If that is the emergency number, then the described procedure 
can turn the call back to the user terminal and refer it to do the 
urn:service:sos call instead and prepare for the relay service to be 
reinvoked automatically from the PSAP.

This situation can happen also with relay services who support one-step 
dialling. The relay services usually have a number or URI of their own, 
so that users can call that address and make the two-step procedure 
anyway, maybe because they are used to it and have not yet learned that 
the one-step is possible. Or in the emergency situation they fall back 
into the way of calling with relay that they used so many years even if 
they were informed that they can now just dial 9-1-1 or 112. They can 
also think: "can they really communicate with me at 9-1-1, no, for 
safety sake I bring the relay into the call as well the usual way."

In USA, one step dialing with relay service is implemented, but still 
the procedure with the normal call turned into an emergency call after 
the refer from the relay service is specified by NENA (i3 chapter 9). I 
think the idea behind that is that the call gets an interpreter assigned 
and gets the AdditionalData already from the relay service, so that the 
connection can be made rapidly when the call converted to an emergency 
call gets to the PSAP.

I have many times said that that procedure looks too complicated and 
risky and that I want a direct method documented that invokes PSAP and 
relay rapidly, and also enables the PSAP to handle the call themselves 
for the case when they have the right capabilities.

Still there might be use of the procedure above for the reasons 
mentioned ( and others).

I think that the reason that the user does not behave as we hoped is the 
most important one. Even if we design good modern ways to do emergency 
and relay calling efficiently, there will be users who make it some 
other way, and we should try to have ways for them at least to not have 
the calls dropped.

Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Thu, 9 Jul 2015 08:35:07 -0400

The NENA mechanism is that the call is placed per 6881.  That says that the call urn:service:sos is sent to the normal outbound proxy service.  That would be the relay service’s proxy.
It would add a Referred-By header, and forward the call per 6881.  Since it is an emergency call from the user device, it has location.  The LoST query can be done, as in 6881, by the device or the proxy.  The relay service can hold the call until a CA is available. or it can forward the call immediately.  The PSAP, when it gets the call, is going to REFER immediately to a bridge (assuming it will use the user’s relay service.  It won’t want to answer, then REFER, or it will delay the call.  Referred-By indicated 3rd party request, so the call should be set up on the PSAP bridge immediately.  The participants join as they can, in any order.   Of course, if there was a queue at the PSAP, the call would be held in queue before the bridge is established.

This is a direct call, it follows the same path any direct dialed emergency call would, and traverses the same path any emergency call would until it reaches the PSAP.  At the PSAP, it’s slightly different in that a bridge is instantiated immediately.  In some NG9-1-1 implementations, all calls are answered at a bridge, and in those implementations, there is NO difference.

If you have ever seen a call handled with a translation service at a PSAP, you will know that you don’t want that process.   Because there is cost involved, there is paperwork, and that delays the call.  Also, since the CA does not have access to any information, they have to learn everything from the caller via sign language.  When the caller supplies the relay service, they have the service information.  So they know name/address/telephone number, etc.  

AFAIK, dial-around emergency service is not implemented in the U.S.  Not sure what would happen if you tried it, but the “default” VRS provider must provide emergency calling service, and the dial around provider is not required to.  “Two-step” dialing, in the U.S., means you are using a relay provider other than your default provider.  We call that “dial-around”, since it’s similar to how long distance (LD) providers work on landline phones - if you direct dial, your default LD provider serves the call, but you can call an access number, dial a destination telephone number, and get service from another (“dial-around”) LD provider for any call.

Brian

> On Jul 9, 2015, at 12:53 AM, Gunnar Hellström <[email-masked]> wrote:
> 
>>> The user might make a regular call that the SIP provider detects should go to the relay service. The relay servicedetects that it should be an emergency call and refers it back to the user to call urn:service:sos instead.
>> 
>> Ideally, the call from the user should be initiated as an emergency call.  Depending on the region, this provides priority call treatment, permits calls to be placed without an account/SIM, tells the originating client to include the various forms of additional data, and triggers various location functions.  If the call from the user is initiated as a normal (non-emergency) call, none of this happens in most environments.
> Yes of course the direct calling when the terminal detects the emergency number from the beginning is the preferred method.
> 
> But many relay services today sadly work with two-step dialling. First the user calls a number or URI to reach the relay service and then discusses with the communication agent what the final destination of the call is. If that is the emergency number, then the described procedure can turn the call back to the user terminal and refer it to do the urn:service:sos call instead and prepare for the relay service to be reinvoked automatically from the PSAP.
> 
> This situation can happen also with relay services who support one-step dialling. The relay services usually have a number or URI of their own, so that users can call that address and make the two-step procedure anyway, maybe because they are used to it and have not yet learned that the one-step is possible. Or in the emergency situation they fall back into the way of calling with relay that they used so many years even if they were informed that they can now just dial 9-1-1 or 112. They can also think: "can they really communicate with me at 9-1-1, no, for safety sake I bring the relay into the call as well the usual way."
> 
> In USA, one step dialing with relay service is implemented, but still the procedure with the normal call turned into an emergency call after the refer from the relay service is specified by NENA (i3 chapter 9). I think the idea behind that is that the call gets an interpreter assigned and gets the AdditionalData already from the relay service, so that the connection can be made rapidly when the call converted to an emergency call gets to the PSAP.
> 
> I have many times said that that procedure looks too complicated and risky and that I want a direct method documented that invokes PSAP and relay rapidly, and also enables the PSAP to handle the call themselves for the case when they have the right capabilities.
> 
> Still there might be use of the procedure above for the reasons mentioned ( and others).
> 
> I think that the reason that the user does not behave as we hoped is the most important one. Even if we design good modern ways to do emergency and relay calling efficiently, there will be users who make it some other way, and we should try to have ways for them at least to not have the calls dropped.
> 
> Gunnar
> 
> --

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 09 Jul 2015 15:34:02 +0200

Brian,
Right.

You say: "Referred-By indicated 3rd party request, so the call should be 
set up on the PSAP bridge immediately."
Is that a NENA convention, or is it specified in any RFC that getting a 
Referred-By means that I am supposed to set up a 3-party call?
Is there any more parameter accompanying the Referred-by and its address 
saying that the bridge shall reconnect to this address?

> The NENA mechanism is that the call is placed per 6881.  That says that the call urn:service:sos is sent to the normal outbound proxy service.  That would be the relay service’s proxy.
In NENA i3 chapter 9 it starts with a call that can be anything. It does 
not tell. Then there is a Refer back to the user terminal to call 
urn:service:sos
As I see it, and the procedure comments, the normal 9-1-1 calling starts 
with the user terminal acting on that Refer.
> If you have ever seen a call handled with a translation service at a PSAP, you will know that you don’t want that process.   Because there is cost involved, there is paperwork, and that delays the…
This is one reason why we need total conversation, and work on that in 
ETSI. If any procedure fails, then at least some dialogue can take place 
in real-time text to sort it out.
> AFAIK, dial-around emergency service is not implemented in the U.S.  Not sure what would happen if you tried it, but the “default” VRS provider must provide emergency calling service, and the dial…
Maybe not important here, but can you not call your default VRS by their 
number, and discuss with them where you want to call, and then they make 
the call?   I think also serial calls are still possible in the US. 
After finishing one call, you keep the interpreter and request another 
call. That looks as two-step dialing with your default relay provider.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Jul 2015 10:08:01 -0400

With the NENA mechanism the deaf user has first contacted the provider, 
and the provider has been able to validate that the user is eligible for 
service. I expect the Referred-By could be encoded some way so that it 
can be correlated with the user when a call is made to it by the PSAP.

That is different from a user making a call to somebody, simply 
inserting a URL of a preferred service, and the called user using that 
to request relay service. In *that* scenario there isn't an obvious way 
for the relay service to authorize the usage.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 9 Jul 2015 12:39:23 -0400

True.  We could invent some mechanism, but it would be a new mechanism.

Brian
 
> On Jul 9, 2015, at 10:08 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> With the NENA mechanism the deaf user has first contacted the provider, and the provider has been able to validate that the user is eligible for service. I expect the Referred-By could be encoded some way so that it can be correlated with the user when a call is made to it by the PSAP.
> 
> That is different from a user making a call to somebody, simply inserting a URL of a preferred service, and the called user using that to request relay service. In *that* scenario there isn't an obvious way for the relay service to authorize the usage.
> 
> 	Thanks,
> 	Paul
>