Subject: AW: [Iptel] comments on rfc2806bis - 800 numbers

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Nov 2002 02:40:33 +0100

Maybe for this problem the following may work:
 
As stated below, an national 800 number is always part of the E.164 numbering plan. Depending
on the accounting agreements between national operators, you may reach the 800 numbers in another country or not. If not, on the PSTN you are routed to an announcement.
 
So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, you may indicate
this with tel:800xxx,phonecontext=+1
 
Richard Stastny

	-----Ursprüngliche Nachricht----- 
	Von: [email-masked] [mailto:[email-masked]] 
	Gesendet: Di 19.11.2002 23:52 
	An: [email-masked]; [email-masked] 
	Cc: 
	Betreff: Re: [Iptel] comments on rfc2806bis - 800 numbers

	In a message dated 11/19/2002 1:17:27 AM Eastern Standard Time, [email-masked] writes: 

		> National freephone numbers SHOULD be represented with a local prefix. 
		
		what is a local prefix? The text above defines global prefix and domain 
		name

	Freephone numbers (e.g., 800 in the US) present a problem for this tel:uri which, IMHO, has not been resolved. While they can easily be represented in the format of a full E.164 number, they can normally only be dialed within some local context (usually a country). Some implications in the draft are that either the global of the local representation would be correct. (See statement that "All phone numbers MUST use the global form unless they cannot be represented as such." which would seem to contradict the above statement.) 
	
	It seems that it should be sufficient to say that any number which can be represented as a E.164 number MUST be represented this way. This would include all "800" numbers. And it needs to be made clear that the representation is unrelated to where it can be reached from (matter for local/national policy). Therefore, a Freephone number would never have a "local prefix" or a "local-anything". It never requires a "context" to be understood. 
	
	Mike Pierce 
	Artel 

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Nov 2002 18:02:51 -0800

It may work sometimes, but not always. For example, a number may be valid in
the US but not in Canada (this is very common, perhaps even the most common
case). 
These countries however both share the same +1 country code. 

I guess one could argue that the area code of the originator could be listed
as phone-context
(phone-context=+1-408). The proxy would have to figure out that 408 is part
of the US not
Canada, and if it is valid or not for this 1-800 number (it would be
impractical to list
ALL the area codes where the 1-800 is valid). 

Another alternative would be a phone-context describing differently the
applicability 
domain (something.ca or something.us).

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Tuesday, November 19, 2002 5:41 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [Iptel] comments on rfc2806bis - 800 numbers
> 
> 
> As stated below, an national 800 number is always part of the 
> E.164 numbering plan. Depending on the accounting agreements 
> between national operators, you may reach the 800 numbers in 
> another country or not. If not, on the PSTN you are routed to 
> an announcement.
>  
> So if yes, you may use e.g. tel:+1800xxx for an NANP 800 
> number, if not, you may indicate this with tel:800xxx,phonecontext=+1
>  
> Richard Stastny
> 
> 	In a message dated 11/19/2002 1:17:27 AM Eastern 
> Standard Time, [email-masked] writes: 
> 	
> 	
> 	
> 
> 	Freephone numbers (e.g., 800 in the US) present a 
> problem for this tel:uri which, IMHO, has not been resolved. 
> While they can easily be represented in the format of a full 
> E.164 number, they can normally only be dialed within some 
> local context (usually a country). Some implications in the 
> draft are that either the global of the local representation 
> would be correct. (See statement that "All phone numbers MUST 
> use the global form unless they cannot be represented as 
> such." which would seem to contradict the above statement.) 
> 	
> 	It seems that it should be sufficient to say that any 
> number which can be represented as a E.164 number MUST be 
> represented this way. This would include all "800" numbers. 
> And it needs to be made clear that the representation is 
> unrelated to where it can be reached from (matter for 
> local/national policy). Therefore, a Freephone number would 
> never have a "local prefix" or a "local-anything". It never 
> requires a "context" to be understood. 
> 	
> 	Mike Pierce 
> 	Artel 
> 	
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Nov 2002 03:22:02 +0100

Comments inline:

	-----Ursprüngliche Nachricht----- 
	Von: Francois Audet [mailto:[email-masked]] 
	Gesendet: Mi 20.11.2002 03:02 
	An: Stastny Richard; [email-masked]'; [email-masked]'; [email-masked]' 
	Cc: 
	Betreff: RE: [Iptel] comments on rfc2806bis - 800 numbers

	It may work sometimes, but not always. For example, a number may be valid in 
	the US but not in Canada (this is very common, perhaps even the most common case). 
	These countries however both share the same +1 country code. 

	Richard: this is correct

	I guess one could argue that the area code of the originator could be listed as phone-context 
	(phone-context=+1-408). The proxy would have to figure out that 408 is part of the US not 
	Canada, and if it is valid or not for this 1-800 number (it would be impractical to list 
	ALL the area codes where the 1-800 is valid). 

	Another alternative would be a phone-context describing differently the applicability 
	domain (something.ca or something.us). 

	Richard: Good point. This may be a good example for the usability of the DNS context.

	Discussing this in the Sportsbar, Lawrence and I found another good reason for the 

	DNS context. With mobile number portability and in the case of network-specific numbers 

	-that are numbers only valid within the given (mobile) network (non E.164 numbers), 

	the "prefix-context" does not work. If you are a mobile operator

	with say context=+43664 and you have a number ported in with context=+43676, you may

	get a problem if a network-specific number is requested. But if you use a DNS context

	like t-mobile.net, you know whats going on:

	Question: is there a way to use both the "prefix" and DNS conetxt at the same time?

	Richard

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Nov 2002 18:48:41 -0800

> DNS conetxt at the same time?

I guess so. I imagine you could technically have multiple descriptors
in the phone-context (phone-context=+43664, t-mobile.net). Or you could
use whatever domain was used in the From URI (instead of the context),
or the authenticated user, or whatever other criteria is applicable. 

I don't think we need to standardize any of this.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Nov 2002 13:41:52 -0800

Sounds reasonable to me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 20, 2002 10:31 AM
To: [email-masked]; Audet, Francois [SC100:4K02:EXCH];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers

There have been several comments related to the format/use of freephone
(e.g., 800) numbers in the tel:uri. 

In a message dated 11/19/2002 8:39:53 PM Eastern Standard Time,
[email-masked] writes: 

As stated below, an national 800 number is always part of the E.164
numbering plan. Depending 
on the accounting agreements between national operators, you may reach the
800 numbers in another country or not. If not, on the PSTN you are routed to
an announcement. 

So if yes, you may use e.g. tel:+1800xxx for an NANP 800 number, if not, you
may indicate 
this with tel:800xxx,phonecontext=+1 

In a message dated 11/19/2002 9:03:39 PM Eastern Standard Time,
[email-masked] writes: 

as phone-context 

In a message dated 11/19/2002 8:59:19 PM Eastern Standard Time,
[email-masked] writes: 

the unfortunate fact that E.164 numbers in the +1-800 domain cannot be 
successfully reached from anywhere does not in any way affect their 
validity as global tel: URL numbers. 

[MAP] I think one needs to look at the intended use of this tel:uri. I think
of the best example (certainly one of the valid ones) is that the tel:uri is
the real information to dial a call that is "behind" a link on a web page.
In this case, anyone anywhere in the world may try to place a call by
clicking on this link. Therefore, the contents/format of the tel:uri should
not depend on whether or not your local national agreements allows the call
to be made. The format needs to be one single global format (E.164-type
format works well) and the local user agent/device needs to be able to
figure out from the information in the tel:uri as well as knowledge of where
it is to decide whether or not the call can be made (or even how to make
it). 

The fact that an 800 number can be represented as an E.164 number is not
unfortunate - I think it is a big help here. 

I suggest that the rule is that any number that can be represented in the
E.164 format MUST be done this way. (A slight strengthening/clarification of
the current text.) This means that an "800" number would never have a
context included, just as no other E.164 number needs one. This removes some
of the difficulties with the current definition. 

What I would really expect on a simple web page is something like the
following: 

If in Germany, click here (the tel:uri behind it contains Germany country
code and the 800 number) 
If in Austria, click here (the tel:uri behind it contains Austria country
code and the 800 number) 
If in Italy click here (the tel:uri behind it contains Italy country code
and the 800 number) 
If in Maryland, click here 
etc. 

If the 800 numbers in multiple places happen to be the same string of
numbers, that is not important.) 

Clicking on the wrong link for the location would simply result in a call
failing, just as if you read off the wrong number from a list and dialed it
on your PSTN phone. 

On the other hand, a more complex web page/user agent may include logic
(Java Script?) to provide a single point to click, and the user agent/device
would know where it is (within the numbering plans) or the user would have
told it and the UA would figure out which one of many internal numbers to
use to place the call. Each of these internal numbers would be in the form
of a tel:uri. 

Mike Pierce 
Artel

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Nov 2002 23:41:20 +0100

Sounds resonable to me too.
BTW, I have only full E.164 numbers in my mobile phone.
One should consider also, that most switches and also many PBX recognise a local number
even if given in E.164 format (given the number is reachable from outside with E.164)
Since you normally on mobile phones and other inelligent terminal do not dial the number, but
click on a link or on a name, the lenght does not matter.
Richard

	-----Ursprüngliche Nachricht----- 
	Von: [email-masked] [mailto:[email-masked]] 
	Gesendet: Mi 20.11.2002 19:31 
	An: Stastny Richard; [email-masked]; [email-masked]; [email-masked]; [email-masked] 
	Cc: 
	Betreff: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers

	There have been several comments related to the format/use of freephone (e.g., 800) numbers in the tel:uri. 
	
	In a message dated 11/19/2002 8:39:53 PM Eastern Standard Time, [email-masked] writes: 

		

	In a message dated 11/19/2002 9:03:39 PM Eastern Standard Time, [email-masked] writes: 

		

	In a message dated 11/19/2002 8:59:19 PM Eastern Standard Time, [email-masked] writes: 

	[MAP] I think one needs to look at the intended use of this tel:uri. I think of the best example (certainly one of the valid ones) is that the tel:uri is the real information to dial a call that is "behind" a link on a web page. In this case, anyone anywhere in the world may try to place a call by clicking on this link. Therefore, the contents/format of the tel:uri should not depend on whether or not your local national agreements allows the call to be made. The format needs to be one single global format (E.164-type format works well) and the local user agent/device needs to be able to figure out from the information in the tel:uri as well as knowledge of where it is to decide whether or not the call can be made (or even how to make it). 
	
	The fact that an 800 number can be represented as an E.164 number is not unfortunate - I think it is a big help here. 
	
	I suggest that the rule is that any number that can be represented in the E.164 format MUST be done this way. (A slight strengthening/clarification of the current text.) This means that an "800" number would never have a context included, just as no other E.164 number needs one. This removes some of the difficulties with the current definition. 
	
	What I would really expect on a simple web page is something like the following: 
	
	If in Germany, click here (the tel:uri behind it contains Germany country code and the 800 number) 
	If in Austria, click here (the tel:uri behind it contains Austria country code and the 800 number) 
	If in Italy click here (the tel:uri behind it contains Italy country code and the 800 number) 
	If in Maryland, click here 
	etc. 
	
	If the 800 numbers in multiple places happen to be the same string of numbers, that is not important.) 
	
	Clicking on the wrong link for the location would simply result in a call failing, just as if you read off the wrong number from a list and dialed it on your PSTN phone. 
	
	On the other hand, a more complex web page/user agent may include logic (Java Script?) to provide a single point to click, and the user agent/device would know where it is (within the numbering plans) or the user would have told it and the UA would figure out which one of many internal numbers to use to place the call. Each of these internal numbers would be in the form of a tel:uri. 
	
	Mike Pierce 
	Artel

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 22 Nov 2002 10:28:00 -0800

In other words, if 1-800 numbers are unique they can be tought of 
as E.164.

If they are not unique, then they need to be tought of as local
number with an associated context.

I might be wrong, but I believe that the first case is the right one.

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Thursday, November 21, 2002 1:38 PM
> To: [email-masked]
> Cc: [email-masked]
> M. Pierce wrote:
> > [MAP] I think one needs to look at the intended use of this 
> tel:uri. I
> > think of the best example (certainly one of the valid ones) 
> is that the 
> > tel:uri is the real information to dial a call that is 
> "behind" a link 
> > on a web page. In this case, anyone anywhere in the world 
> may try to 
> > place a call by clicking on this link. Therefore, the 
> contents/format of 
> > the tel:uri should not depend on whether or not your local national 
> > agreements allows the call to be made. The format needs to 
> be one single 
> > global format (E.164-type format works well) and the local user 
> > agent/device needs to be able to figure out from the 
> information in the 
> > tel:uri as well as knowledge of where it is to decide 
> whether or not the 
> > call can be made (or even how to make it).
> > 
> > The fact that an 800 number can be represented as an E.164 
> number is 
> > not
> > I suggest that the rule is that any number that can be 
> represented in
> > the E.164 format MUST be done this way. (A slight 
> > strengthening/clarification of the current text.) This 
> means that an 
> > "800" number would never have a context included, just as 
> no other E.164 
> > number needs one. This removes some of the difficulties 
> with the current 
> > definition.
> 
> I think treating tel URIs consistently as identifiers ("URN") helps 
> conceptually. After all, if I specify an ISBN number (another 
> URN), it 
> is globally unique, but there is no guarantee that my local 
> book store 
> can order the book or that the library carries it.
> 
> Similarly, there are any number of reasons that a non-800 
> E.164 number 
> can fail: administrative prohibition, number disconnected, invalid 
> number, local outbound call filtering, etc.
> 
> Thus, the important consideration is only "is this number 
> unique without 
> a context"? Thus, a context would be needed if 
> +1-800-something refers 
> to two logically different entities in Canada and the US. 
> (Obviously, an 
> 800 number may end up in many different locations depending on the 
> source of the call, but that's not the problem.) I don't know 
> if that's 
> possible. To put it more concretely: will the same 800# ever 
> be assigned 
> to two different entities, as in
> 
> 1-800-123-4567 reaches PizzaHut if dialed in New York
> and
> 1-800-123-4567 reaches Domino's if dialed in New Jersey
> and
> 1-800-123-4567 reaches WeightWatchers if dialed in Canada
> 
> > (Java Script?) to provide a single point to click, and the user 
> > agent/device would know where it is (within the numbering 
> plans) or the 
> > user would have told it and the UA would figure out which 
> one of many 
> > internal numbers to use to place the call. Each of these internal 
> > numbers would be in the form of a tel:uri.
> 
> We need a DHCP option that conveys the local area code! 
> (Sorry, inside 
> joke for the Geopriv crowd.)
> 
> 
> > 
> > Mike Pierce
> > Artel
> 
>

---

From: "Crizza, Roberto" <[email-masked]>
Date: Mon, 25 Nov 2002 05:17:56 -0600

Team

We don't have this kind of prblem in my country Brazil, the toll free number
here
is "0800" but it is unique for the hole country, the carrier never assign
the same number to different company the string is 0800 xxx yyyy.

Roberto Crizza
EDS do Brasil
----- Original Message -----
From: Crizza, Roberto <[email-masked]>
To: Ieee (E-mail) <[email-masked]>
Sent: Friday, November 22, 2002 3:13 PM
Subject: FW: AW: [Iptel] comments on rfc2806bis - 800 numbers

> Sent: Thursday, November 21, 2002 19:38
> To: [email-masked]
> Cc: [email-masked]
> > [MAP] I think one needs to look at the intended use of this tel:uri. I
> > think of the best example (certainly one of the valid ones) is that the
> > tel:uri is the real information to dial a call that is "behind" a link
> > on a web page. In this case, anyone anywhere in the world may try to
> > place a call by clicking on this link. Therefore, the contents/format of
> > agreements allows the call to be made. The format needs to be one single
> > agent/device needs to be able to figure out from the information in the
> > tel:uri as well as knowledge of where it is to decide whether or not the
> > I suggest that the rule is that any number that can be represented in
> > strengthening/clarification of the current text.) This means that an
> > "800" number would never have a context included, just as no other E.164
> > number needs one. This removes some of the difficulties with the current
> > definition.
>
> conceptually. After all, if I specify an ISBN number (another URN), it
> is globally unique, but there is no guarantee that my local book store
> Similarly, there are any number of reasons that a non-800 E.164 number
> Thus, the important consideration is only "is this number unique without
> a context"? Thus, a context would be needed if +1-800-something refers
> to two logically different entities in Canada and the US. (Obviously, an
> source of the call, but that's not the problem.) I don't know if that's
> possible. To put it more concretely: will the same 800# ever be assigned
> > agent/device would know where it is (within the numbering plans) or the
> > user would have told it and the UA would figure out which one of many
> We need a DHCP option that conveys the local area code! (Sorry, inside

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Nov 2002 16:21:59 +0100

If we talk about the context of the tel: URI scheme, we first need to
talk
about the "context" in which we will use this URI:
 
e.g. 
used as a tel URI in an Enumservice
used as a tel URI in a SIP message 
used on a webpage to click on.
 
Lets take the following scenario (derived from a normal 800 IN service)
If you see dial 800 xxx to get a Pizza
what happens is (simplified): 
you dial the 800 xxx number,
your network is querying the IN service to get the service provider
hosting the 800 service to get a CIC
the call is routed according to the CIC to the service provider
The service provider network is again making an IN query to find out
to which PSTN number the call should be routed:
this is now the tricky part: this routing may be dependant on your
origination (context), time-of-day, date, etc.
So what happens is, that your context is matched to the context 
of the PSTN number.
 
Back again to the tel: URI
 
If you click on w webpage on a tel URI, it will be always be IMHO
without
context (for Pizza dial 800 xxx). We do not IN services with webpages.
 
In a sip proxy querying an IN services or ENUM this may be different.
 
In ENUM I may have 10 NAPTRs with PSTN tel URIs
for the same 800 number with different context.
 
the SIP proxy querying ENUM may now match the context of the
Tel URIs in the NAPTRs with the context retreived from your origination.
 
The problem here is: how is the context of your origination defined?
By your number (does work anymore if you can have IP phones ion DSL
in Montana with a New Work area code), the context of the sip proxy? (
could be anywhere), or what you configure (could be wrong).
 
So in this scenario we are not using the context with the 800 number at
all, but with the PSTN numbers associated.
 
The other way would be to really let the user do the IN service:
if in Montana click this
if in New York click this
 
In this case the context of the 800 number need to be on the
webpage, the context need to be transferred in SIP and then matched
to the context in ENUM.
 
regards
Richard Stastny

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: Monday, November 25, 2002 3:48 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers

	In a message dated 11/22/2002 8:19:59 AM Eastern Standard Time,
[email-masked] writes: 

		Thus, the important consideration is only "is this
number unique without 
		a context"? Thus, a context would be needed if
+1-800-something refers 
		to two logically different entities in Canada and the
US. (Obviously, an 
		800 number may end up in many different locations
depending on the 
		source of the call, but that's not the problem.) I don't
know if that's 
		possible. To put it more concretely: will the same 800#
ever be assigned 
		to two different entities, as in 
		
		1-800-123-4567 reaches PizzaHut if dialed in New York 
		and 
		1-800-123-4567 reaches Domino's if dialed in New Jersey 
		and 
		1-800-123-4567 reaches WeightWatchers if dialed in
Canada 

	
	[MAP] A long, long time ago in the history of telephony (about
20 years ago), Intra-state WATS numbers were indicated by the digit 2 in
the 6th position (800-nn2-), so presumably the same number could be
assigned in multiple places. (Ads would often say "In New York, dial
1-800-452-1234, elsewhere dial 1-800-678-1234.") I don't know if this is
still possible, but it seems likely. There is no reason why the actual
routing of any telephone number can't be dependent on the location of
the originator. (911 certainly works this way.) 
	
	I believe the case above (a single number reaching different
Pizza Huts depending on where you are) is possible. If so, it's not just
a function of which state you're in. I wouldn't want the store in NYC to
deliver a pizza to me in Albany:>) 
	
	I think this issue brings us back to the question of what the
"context" is for. The current draft describes its use to "provide a
unique identifier that lets a client know whether it can interpet the
local number or not". It then states "It has not [sic] other meaning or
function." The problem is that other implied uses seem to be to
influence the routing of a call. 
	
	The "context" included in the tel:uri is really just an extra
check that the receiver can use to verify that it should be able to
understand the number when it is not a globally defined one like E.164.
However, I would still believe that, in the proper case, all the routing
that was done to get it there should be correct (and should not use
"context"). In this case of 800 numbers, the routing itself can not be
dependent on an additional "context" that the originator puts with the
number, which they think represents the intended destination. The
originator doesn't know this. The "context" for routing is the
orginator's location. 
	
	Now, if we want to solve the bigger problem of not knowing where
the originator of a call is by requiring them to enter some information
to identify where they are, that's another issue, but I don't think
anyone would want to do that. 
	
	Mike Pierce 
	Artel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 25 Nov 2002 11:19:29 -0800

Right, it wouldn't matter as long as they both are willing
to share the same number (which may not be typical today, but 
it is certainly possible). I guess one could call this
sub-leasing of phone numbers.

Again, to me this is no different than having, say, an
alias in SIP for [email-masked] which sends 
request to various vendors depending on geography (or
any other criteria such as time-of-day). 

> From: Scott Bradner [mailto:[email-masked]] 
> Sent: Monday, November 25, 2002 11:07 AM
> To: Audet, Francois [SC100:4K02:EXCH]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: AW: [Iptel] comments on rfc2806bis - 800 numbers
> 
> 
> > I believe that the
> > 1-800 are in fact E.164 numbers, and that they can not be assigned 
> > twice to different entities
> 
> would that not be just a matter of populating the backroom 
> databases? having geographicly-specific data in the mapping 
> database is already there so it would seem to me that it does 
> not matter if the entries represent the same or different 
> organizations
> 
> Scott
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 29 Nov 2002 12:07:36 -0800

Agreed with what you said.
 
I think the core of the problem is no one seems sure if 1-800 in North
America are uniquely assigned. We do know that there are restrictions on
where the number can be reached from. We also know that the call can
terminate on different end-use depending on things like call origination
location, time of day, etc.
 
But we can't seem to get a definitive answer to the question of can a 1-800
be assigned to more than one entity, and thus not to be unique. We thus
still don't know if 1-800 numbers are E.164 numbers (and thus unique) or an
artifact of the dialling plans used in North America (and thus requiring a
context). We are certainly getting conflicting information.
 
I wonder if somebody from the NANP administrator could help us...

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Friday, November 29, 2002 11:27 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Audet, Francois [SC100:4K02:EXCH];
[email-masked]; [email-masked]
Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers

Hi, 

So far, everyone seems to agree that as long as numbers are unique, they
don/t require the context parameter. I don't think anything in your mail
contradicts that. Comments inline. 

thanks, 

-rohan 

On Friday, November 29, 2002, at 10:08 AM, [email-masked] wrote: 

In a message dated 11/27/2002 4:23:11 PM Eastern Standard Time,
[email-masked] writes: 

By saying same number assigned in multiple areas, do you mean numbers 

without country code prefixes? 

[MAP] I think there have been several different concepts mentioned related
to free-phone (e.g. 800) numbers: 

1. In the US (and Canada), 800 numbers have often been applicable for calls
originating only from certain areas, i.e., only US, a group of states, a
single state, etc. This (theoretically) allows the same number to be
assigned in different areas to completely different users with completely
separate routing. I suspect this is still allowed. 

Can someone provide a definitive answer on this question? In my (fairly
limited) experience, numbers which are assigned to a specific region play an
error message, rather than being routed to orthogonal organizations. If this
is indeed the case, it is totally reasonable to refer to these numbers as
ordinary tel:+1800nnnnnnn URIs with no additional context. Reachability is
not a concern for a URI, only uniqueness. 

For example, most folks cannot reach: http://wwwin.cisco.com even though it
is a valid URI. 

2. An 800 number (in the US/Canada) can be assigned which uses "Intelligent
Network" capabilities with a data base lookup so that the actual routing is
a function of the originator's location (i.e., calling party number).
(Example: route to nearest Pizza Hut.) 

It is useful to use a URI to refer to such a number "in general", or to
refer to a specific instance. I think it is perfectly legitimate to publish
both of the following URIs: 

tel:+18002224357 

tel:+18002224357;context=+1831452 

the first is a URI for roadside assistance for the American Automobile
Association (1-800-AAA-HELP for those stateside). I can publish this URI on
a web page with the disclaimer that it is only reachable in the US. Even
though it will reach different instances of AAA for different callers, it
still refers to a specific thing (it is still unique) 

The second refers to the the specific AAA call center that handles calls for
my (unported) prefix. I don't see much need for this usage, but I see no
reason to prohibit its use either. 

Please note also, that I can call some +1 800 numbers from outside North
America. I have called American Express from a random variety of countries
in Europe and Asia by just dialing the equivalent of +18008014941. This
number is not only globally unique, but also reachable from a variety of
countries outside any describable context. 

3. The same 800 number may be allocated to the same company for use in
multiple countries. I'm looking for examples. The use of the number depends
on the location of the calling party. It is normally called only when in one
of those countries (without dialing a Country Code). Dialing from outside
the country, using the Country Code, is theoretically possible, if allowed
by agreements between the countries. 

we don't really care much about countries, we care about prefixes. If
someone has the same number in multiple prefixes, then they are free to
publish as few or as many of these URIs as they would like. They are all
unique. 

4. The "International Freephone Service" uses the "800" in place of the
Country Code followed by 8 digits, that is, the assigned "IFS" number is
truly "global", however there is certainly still no guarantee that it can be
called from everywhere in the globe. ITU-T only requires that it be used
"between two or more countries". Use of these numbers requires that the user
be located within the assigned countries. 

As long as +800xxxxxxxx is unique, then this is a totally valid URI. as I
said 

Of course, all of these uses are based on knowing the originator's location
(or more precisely, the location of the equipment handling the call set-up).

Mapping this to the Internet case where there is no knowledge of the
location of the caller is a real challenge. I think that one reason for the
"context" being applied with such "800" numbers in 2806bis was to get around
this problem - that is - for the originator to indicate more information
about their location or the desired destination. 

For example, a user who is in US (or who doesn't even care where they are)
wants to call an "800-234-567" number in Germany. They put in the "800"
number and separately code the "49" country code for Germany in "context".
They could just as well represent the desired number as +49-800-234-567
(One could apply the same reasoning to a regular number in the US and put in
only the final 7 digits, and code +1 and area code in "context", but I
believe we agreed not to allow that.) 

Another example of the possible use of context: The user codes the
destination +49-800-234-567 (full number) and puts their own location (e.g.,
+1-410) in "context, meaning where they are physically located (independent
from their "identity"). The destination could use this "context" to decide
whether or not it should handle the call. This is similar to the use of
"context" when dealing with "private" numbers in which the originator codes
their own, and the other end can use it as a check. 

Another example of the use of "context" which is implied in the draft is the
ability to codes multiple "context" values, for example, the originator
codes the number as +49-800-234-567 and codes the "context" with both 49 for
Germany and 44 for UK. While it is certainly possible for the same number to
be assigned to the same company in both countries, it has never been clear
to me what function (multiple contexts) this would serve. Would an 800
number valid in the entire US then require the "context" to include every
possible area code? 

Mike Pierce 

Artel