Subject: [Ecrit] URN: for people with hearing loss

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Jul 2017 18:37:07 -0400

Several countries have separate numbers (some short, some toll-free) where
people can send an SMS or fax for emergency assistance. (The US has made
the decision to use 911 for SMS as well, but that's not relevant for this
discussion. In those countries, such calls need to be routed separately and
you can't tell whether you are going to send a fax when dialing...)

One possibility is to use *sos.text *(with the understanding that this
includes fax; none of the countries I checked separate those), but I'm not
terribly happy with this label.

I want to avoid something like *sos.hearing-loss* since this assumes that
only people with hearing loss can use the service. Some countries do
require some kind of registration, but this does not seem like something we
want to encode in a URN.

Henning

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 12 Jul 2017 08:24:22 +0200

I doubt that the URN is the right mechanism for separating different 
technologies and media used for the emergency call. That gets in 
conflict with the specification of service type on the application level 
that was the original idea of using subtypes in the URN.  You cannot 
specify "coastguard" and "text" at the same time, or you need a 
complicated logic that allows to hang the technology specification as a 
sub-service on any of the other services ( "sos.coastguard.text" ).

The IETF SLIM WG is working with indication of desired language and 
modality.  Emergency service is one of the main applications. We have 
only identified spoken, written and signed modalities, but also briefly 
discussed if "message" would be needed, as would be the need for SMS and 
fax. (with written modality we mean real-time text declared as text 
media. )  Maybe that mechanism can be considered for your needs.

If you continue on the subtype track, I also agree that "hearing-loss" 
is not a good term to use, and also not "text".

Maybe "message" if that is what the subtype is intended to handle. Or 
did you intend to handle all mixes of modality that can occur:   sms, 
fax both ways, fax one way and speech the other, real-time text both 
ways, real-time text one way and speech the other, sign language both 
ways, instant messaging both ways, instant messaging combined with 
speech etc. ? How would the device  know for which modality preferences 
to use the service subtype and when to use the regular "sos".

Gunnar

Den 2017-07-12 kl. 00:37, skrev Henning Schulzrinne:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2017 11:03:23 -0400

Gunnar,

thanks for your comments.

I suspect we all agree that this is not a good way to handle things in a
clean-slate (or NG112/NG911) environment. Unfortunately, we have to work
within the constraints of the existing system, for now. As I mentioned, a
number of countries have a separate number for SMS and fax calls to
emergency services. The end system or first carrier device has to route the
call or message to the right place, translating that dialed number into a
URN (which in turn will get translated into a SIP URL which routes to some
kind of VoIP gateway device). At that point, it has no way of knowing
whether a fax transmission will take place - it's just connecting a voice
path to a destination that's distinct from the usual voice emergency call.

This is less of an issue for SMS. Indeed, one could argue that SMS to
emergency services should just use "sos" on the SIP side, i.e., after
exiting the traditional SMS realm. Thus, this case doesn't need a new URN.

All countries I looked at have exactly one such (short-code) number, not
separate numbers for different emergency services. Since this is, as you
mention, a transition mechanism (I hope we don't use faxes for emergency
"calling" in ten years!), I'm trying to keep this as simple as possible,
rather than inventing complex labeling.

Among your suggestions, "sos.*message*" seems like the most neutral and
simple term. I will update the slides accordingly.

Henning

On Wed, Jul 12, 2017 at 2:24 AM, Gunnar Hellström <
[email-masked]> wrote:

> technologies and media used for the emergency call. That gets in conflict
> with the specification of service type on the application level that was
> the original idea of using subtypes in the URN.  You cannot specify
> "coastguard" and "text" at the same time, or you need a complicated logic
> that allows to hang the technology specification as a sub-service on any of
> the other services ( "sos.coastguard.text" ).
>
> modality.  Emergency service is one of the main applications. We have only
> identified spoken, written and signed modalities, but also briefly
> fax. (with written modality we mean real-time text declared as text media.
> )  Maybe that mechanism can be considered for your needs.
>
> If you continue on the subtype track, I also agree that "hearing-loss" is
> not a good term to use, and also not "text".
>
> Maybe "message" if that is what the subtype is intended to handle. Or did
> you intend to handle all mixes of modality that can occur:   sms, fax both
> ways, fax one way and speech the other, real-time text both ways, real-time
> text one way and speech the other, sign language both ways, instant
> messaging both ways, instant messaging combined with speech etc. ? How
> would the device  know for which modality preferences to use the service
> subtype and when to use the regular "sos".
>
> Gunnar
>
> Ecrit mailing [email-masked]://www.ietf.org/mailman/listinfo/ecrit
>
>
> --
> [email-masked]
> +46 708 204 288
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 12 Jul 2017 20:39:54 +0200

Henning,

Yes, I agree that for the limited application you describe, when a 
country has a separate number for SMS and/or fax, and handle these calls 
in a separate PSAP, then they likely currently act as relays when the 
emergency case is for coastguard or any of the other subservices.

Under such circumstances sos.message would do.

It is just sad that it is not just one number for all emergencies 
because people cannot learn more than one and remember it in an 
emergency situation. But that is another story.

Gunnar

-----------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2017 14:50:13 -0400

Gunnar,

I found another case that's a bad idea, but reality: Australia uses 106 for
TTY (not SMS, no fax) calls. I'll still group it as sos.message, but it
shows the range of legacy solutions.

However, there do seem to be other options that are probably more
attractive, even if not completely integrated ("ask for 000"):

http://relayservice.gov.au/making-a-call/emergency-calls/

Henning

On Wed, Jul 12, 2017 at 2:39 PM, Gunnar Hellström <
[email-masked]> wrote:

> Henning,
>
> Yes, I agree that for the limited application you describe, when a country
> has a separate number for SMS and/or fax, and handle these calls in a
> separate PSAP, then they likely currently act as relays when the emergency
> case is for coastguard or any of the other subservices.
>
> It is just sad that it is not just one number for all emergencies because
> people cannot learn more than one and remember it in an emergency
> situation. But that is another story.
>
> Gunnar
>
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 19 Jul 2017 23:56:01 +0000

Replying to the thread as a whole, rather than just to the last message.

Firstly I think we should ignore SMS from a solution based on service URN for a number of reasons.

It has been specified by the regulator as an emergency service in the UK, but imposes no requirements on the mobile operators to treat it any different to a normal SMS, therefore it is formally still a store and forward service. My understanding is that this is regarded as a means to an end, rather than an ideal solution, and ultimately real time text would be the preferred solution.

3GPP does not define an emergency form of SMS, and SMS does not meet the service requirements for emergency call, primarily the need for an interactive communication.

In regard to obtaining a real time text service, surely there are two issues here – do I require routeing to a specialist endpoint, and how do I indicate to the remote endpoint that real time text is required. Surely we only require routeing to a specialist endpoint if either the technology at a normal endpoint cannot handle the service, or a specialist user is required. My understanding of the UK perspective on this is that when a move is made to IP PSAPs, the intention is that all 1st level PSAPs will be capable of handling real time text (in my understanding not a particularly expensive requirement), and that all PSAP attendants will be trained to handle such calls. If that is the case, then there is no special routeing requirement. In terms of indicating the need to the endpoint, then SDP is sufficient. Thus from the UK perspective, I am not understanding the need for anything beyond the existing SOS URN.

I would add that in adding .msg as a subtype, there would be considerable confusion as to its precedence with other subtypes, such as fire. Is sos.msg.fire the same as sos.fire.msg? Assuming those combinations are defined as legal in the first place. Note that if sos.fire.msg was used, and the responder did not understand .fire, then the result would only be understood as sos, and not as sos.msg. Therefore I see major issues of reuse of the URN to indicate this requirement.

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: 12 July 2017 19:50
To: Gunnar Hellström <[email-masked]>
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] URN: for people with hearing loss

Gunnar,

I found another case that's a bad idea, but reality: Australia uses 106 for TTY (not SMS, no fax) calls. I'll still group it as sos.message, but it shows the range of legacy solutions.

However, there do seem to be other options that are probably more attractive, even if not completely integrated ("ask for 000"):

Henning

On Wed, Jul 12, 2017 at 2:39 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:
Henning,

Yes, I agree that for the limited application you describe, when a country has a separate number for SMS and/or fax, and handle these calls in a separate PSAP, then they likely currently act as relays when the emergency case is for coastguard or any of the other subservices.

It is just sad that it is not just one number for all emergencies because people cannot learn more than one and remember it in an emergency situation. But that is another story.

Gunnar

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jul 2017 23:52:21 -0400

Inline.

On Wed, Jul 19, 2017 at 7:56 PM, Drage, Keith (Nokia - GB) <
[email-masked]> wrote:

Replying to the thread as a whole, rather than just to the last message.
Firstly I think we should ignore SMS from a solution based on service URN
for a number of reasons.
It has been specified by the regulator as an emergency service in the UK,
but imposes no requirements on the mobile operators to treat it any
different to a normal SMS, therefore it is formally still a store and
forward service. My understanding is that this is regarded as a means to an
end, rather than an ideal solution, and ultimately real time text would be
the preferred solution.
3GPP does not define an emergency form of SMS, and SMS does not meet the
service requirements for emergency call, primarily the need for an
interactive communication.

This illustrates the problem of trying to define emergency too narrowly. By
US regulation (47 CFR 20.18), text-to-911 (currently, SMS) is indeed
mandatory to provide as an emergency service for US cellular carriers. (It
is naturally not a "call", but it is emergency communication.) However,
this may not matter unless such SMS gets converted to MSRP (say) and then
needs to be routed to a different location than service:sos voice or
multimedia calls. This does not currently appear to be the case, but could
be.

In regard to obtaining a real time text service, surely there are two
issues here – do I require routeing to a specialist endpoint, and how do I
indicate to the remote endpoint that real time text is required. Surely we
only require routeing to a specialist endpoint if either the technology at
a normal endpoint cannot handle the service, or a specialist user is
required. My understanding of the UK perspective on this is that when a
move is made to IP PSAPs, the intention is that all 1st level PSAPs will be
capable of handling real time text (in my understanding not a particularly
expensive requirement), and that all PSAP attendants will be trained to
handle such calls. If that is the case, then there is no special routeing
requirement. In terms of indicating the need to the endpoint, then SDP is
sufficient. Thus from the UK perspective, I am not understanding the need
for anything beyond the existing SOS URN.

I would add that in adding .msg as a subtype, there would be considerable
confusion as to its precedence with other subtypes, such as fire. Is
sos.msg.fire the same as sos.fire.msg? Assuming those combinations are
defined as legal in the first place. Note that if sos.fire.msg was used,
and the responder did not understand .fire, then the result would only be
understood as sos, and not as sos.msg. Therefore I see major issues of
reuse of the URN to indicate this requirement.

I did not suggest a message (.msg) suffix, for the reasons you mention and
since this seems unnecessary based on the services actually deployed. As a
stopgap, while there are mixed TDM-IP networks (with legacy customer
networks) that use special-purpose numbers, such as sos.message URN may be
needed to reach the right gateway (e.g., a TTY-to-RTT gateway). If a user
dials the special TTY (or fax) number, the network can't distinguish this
from a regular voice call, as you know, so either all PSAPs have to be able
to handle fax and TTY, or the call has to be initially directed to the
special-purpose gateway.

Naturally, if

Henning