Subject: [Iptel] 2806bis: service numbers

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Dec 2002 22:05:37 -0500

One of the open issues in 2806bis is the treatment of service numbers. 
There seem to be two basic classes, with some subcases:

1) Nationally uniform numbers, with the same treatment

For example, in most countries, emergency numbers like 999, 112 or 911 
fall in this category. They might ring in different locations, but 
that's not fundamentally different than a PizzaHut number.

nanpa.com says:

"In the U.S., the FCC administers N11 codes, and recognizes only 211, 
311, 511, and 711 as nationally assigned. Other codes have traditional 
uses as shown in the table below."

My perception is that other countries don't use service numbers as much, 
beyond emergency calling and that if they do, they designate the same 
service within a country code, but I'm sure other have a better 
perspective on this.

2) Regionally diverse numbers

Apparently, some x11 numbers are used differently in different regions. 
  (Examples?)

3) Carrier-specific services

This seems to be common for #NN numbers on cell phones (e.g., to call 
for assistance or to get traffic help)

What are the options for tel URIs:

(A) punt - explicitly exclude them; I don't think that's a good idea as 
people will put these on web pages

(B) use the same scheme as for other 'private'/'local' numbers

(Here, private doesn't really apply; local is probably closer to the mark.)

For carrier-specific numbers, use a domain name context, for national 
numbers the country code (as in tel:911;phone-context=+1; this assumes 
that 911 is not used for something else in the Carribean). 
State-specific numbers are painful, but one could imagine a convention 
such as

tel:211;phone-context=nj.us

(C) Make them look like E.164 numbers, as in tel:+1-911

Ugly and not likely to be intuitive.

There may well be other options, such as logical names that get mapped 
to the local service representation ("telsvc:traffic", "telsvc:repair"), 
but the list of registrations seems long. We'd probably want to get 
NANPA to vet such assignments.

I think the least bad option is (B), with regional designations 
(;phone-context=us).

Comments?

Henning

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 13 Dec 2002 10:58:13 -0500

Henning,

Your telsvc:411 or telsvc:directory probably hits closest to what these 
numbers really are, service codes.

For option B, if the user is mobile and dials 911, would his terminal know 
the phone-context, or would this be added by the outbound proxy that 
receives the call?

Mike

At 10:05 PM 12/12/2002 -0500, Henning Schulzrinne wrote:
>fall in this category. They might ring in different locations, but that's 
>not fundamentally different than a PizzaHut number.
>
>nanpa.com says:
>
>"In the U.S., the FCC administers N11 codes, and recognizes only 211, 311, 
>511, and 711 as nationally assigned. Other codes have traditional uses as 
>shown in the table below."
>
>Apparently, some x11 numbers are used differently in different 
>regions.  (Examples?)
>
>This seems to be common for #NN numbers on cell phones (e.g., to call for 
>assistance or to get traffic help)
>
>that 911 is not used for something else in the Carribean). State-specific 
>numbers are painful, but one could imagine a convention such as
>
>There may well be other options, such as logical names that get mapped to 
>the local service representation ("telsvc:traffic", "telsvc:repair"), but 
>the list of registrations seems long. We'd probably want to get NANPA to 
>vet such assignments.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Dec 2002 11:27:18 -0500

> numbers really are, service codes.

The problem with telsvc:411 is that this could mean different things in 
different places, which is not exactly "universal". (Yes, that's true 
for file URLs, too, but those are, to me, an example of something to be 
avoided, not replicated.)

Thus, I would much prefer a symbolic registration in the URN spirit 
which is then mapped to the locally appropriate mechanism. The only 
drawback is that adding new services is a bit harder. Gateways have to 
know lots of service names, which change, rather than very few context 
names, which do not change (or very infrequently).

We have something like service names in the SLP URI, by the way. But 
they imply a certain protocol mechanism to resolve them.

> 
> For option B, if the user is mobile and dials 911, would his terminal 
> know the phone-context, or would this be added by the outbound proxy 
> that receives the call?

I'm hoping that they wouldn't dial 911, but rather something like 
sos@their-aor, but leaving that aside, the caller would have to add the 
context, since the URI could be misinterpreted otherwise. Let's say 611 
means repair in one place and directory assistance in another. The proxy 
can't know what you meant and blindly dialing the digits is going to 
lead to rather nasty surprises. Or, for the 911 example, I'd much rather 
have the Japanese proxy say "sorry, 911 is only valid in context +1; 
you're in some other context" than get a voice message in Japanese 
saying the equivalent of "the number you have dialed is not in service".

>> to the local service representation ("telsvc:traffic", 
>> "telsvc:repair"), but the list of registrations seems long. We'd 
>> probably want to get NANPA to vet such assignments.
>>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 13 Dec 2002 11:47:56 -0500

Henning,

Understood.  That form merely replicates the existing problem.  You would 
probably need something like:

telsvc:411;service-context:nj.us

Is the intent to provide a globally unique hierarchy of services that any 
server could look up and treat accordingly?  For example, if the mobile 
user dials 911 and it is rendered as (tel: or telsvc: whichever):

telsvc:911;service-context:us

could it then translate that to:

telsvc:211;service-context:country-x

which is local to that country where the call originates.  Or more 
directly, translate to the actual tel: or sip: URI that is the number of 
the local emergency service.

Mike

At 11:27 AM 12/13/2002 -0500, Henning Schulzrinne wrote:
>different places, which is not exactly "universal". (Yes, that's true for 
>file URLs, too, but those are, to me, an example of something to be 
>Thus, I would much prefer a symbolic registration in the URN spirit which 
>is then mapped to the locally appropriate mechanism. The only drawback is 
>that adding new services is a bit harder. Gateways have to know lots of 
>service names, which change, rather than very few context names, which do 
>not change (or very infrequently).
>
>We have something like service names in the SLP URI, by the way. But they 
>imply a certain protocol mechanism to resolve them.
>
>>know the phone-context, or would this be added by the outbound proxy that 
>>receives the call?
>
>can't know what you meant and blindly dialing the digits is going to lead 
>to rather nasty surprises. Or, for the 911 example, I'd much rather have 
>the Japanese proxy say "sorry, 911 is only valid in context +1; you're in 
>some other context" than get a voice message in Japanese saying the 
>equivalent of "the number you have dialed is not in service".
>
>>Mike
>
>>>State-specific numbers are painful, but one could imagine a convention such as
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Dec 2002 14:15:48 -0500

> Understood.  That form merely replicates the existing problem.  You 
> would probably need something like:
> 

Yes, although at that point, it's unclear what the benefit is compared to

tel:411;phone-context=nj.us

> 
> Is the intent to provide a globally unique hierarchy of services that 
> any server could look up and treat accordingly?  For example, if the 
> mobile user dials 911 and it is rendered as (tel: or telsvc: whichever):
> 

I think the idea would be to translate this into either an E.164 number 
(e.g., for out-of-area 911 numbers), possibly expressed as a tel URI, or 
a SIP URI. The E.164 tel URI would presumably be useful only if this 
translation is delegated to some third party. I don't know if an 
ENUM-like directory would work here, since you would not query for a 
number, but a range of numbers. You would query "I'm at 212 555 1234, 
what's the repair service number for me?", but the answer would be the 
same for all 212 numbers, in most cases.

---

From: Michael Hammer <[email-masked]>
Date: Fri, 13 Dec 2002 16:20:10 -0500

That would only provide a distinction between a name and an address.  Not 
sure if it is worth the trouble though.

Mike

At 02:15 PM 12/13/2002 -0500, Henning Schulzrinne wrote:
>(e.g., for out-of-area 911 numbers), possibly expressed as a tel URI, or a 
>SIP URI. The E.164 tel URI would presumably be useful only if this 
>translation is delegated to some third party. I don't know if an ENUM-like 
>directory would work here, since you would not query for a number, but a 
>range of numbers. You would query "I'm at 212 555 1234, what's the repair 
>service number for me?", but the answer would be the same for all 212 
>numbers, in most cases.
>
>
>>Mike