Re: [Ecrit] country specific emergency URNs

[Henning Schulzrinne <[e-mail]>]

I agree that the naming should be chosen so that the routing behavior in
case of non-support is sensible. (After all, this was one reason for the
hierarchy.)

This can be a bit of a judgement call, but carriers have three options when
they find a non-supported label:

* route to the "next one up". I think in the US, there's probably a bias to
routing emergencies to 911, e.g., if a label sos.poison were to show up.
This should rarely happen - after all, there's no local short code for
this, so the only likely valid (non-buggy) case would be a roaming
international user who dials the home emergency number which gets
translated to a locally-not-supported service.

* explicitly route to some kind of IVR (e.g., for sos.gas in the US: "The
number you have dialed is not supported in your local area. If this is a
true emergency, dial 911. To report gas leaks, call your local utility.
Good luck finding a phone book.")

* fast busy or "no such number" recording or the SIP equivalent. Probably
the worst option.

Henning

On Wed, Jul 12, 2017 at 11:27 AM, Drage, Keith (Nokia - GB) <
[e-mail]> wrote:

> Yes, but the name is “sos.flowers”, not “flowers”.
>
>
>
> Further, if the receiving entity does not understand “sos.flowers” it will
> be treated as “sos”, and therefore any usage should correspond with the
> semantics of “sos”.
>
>
>
> Failure to do this will mean calls that are not emergency calls (thereby
> not requiring immediate response) will be sent to the PSAP, and at least
> certain regulators and emergency service providers get very upset with this
> happening.
>
>
>
> So any subtype meaning, in my view, must also complement the semantics of
> “sos”, rather than just replace it.
>
>
>
> Regards
>
>
>
> Keith
>
>
>
>
>