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

[Henning Schulzrinne <[e-mail]>]

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

> 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:
>
> 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
>
>
>
>
> _______________________________________________
> Ecrit mailing [e-mail]://www.ietf.org/mailman/listinfo/ecrit
>
>
> --
> -----------------------------------------
> Gunnar Hellström
> [e-mail]
> [phone]
>
>