Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Jan 2003 15:32:36 -0500

Okay, let's get specific, because it's hard on my head to deal
with too many abstractions.

Around here, I can dial 7844 to get a local extension,
9-1-703-559-2348 to reach a colleague in one of our outlying offices,
or 304-2349 to reach the same colleague using our internal network.
Just for the moment, ignore the possibility that some entity could
recognize that 9-1-703-559-2348 could be translated into 304-2348.
The point is that in my domain, 304-2348 is a routable number,
but not a global number.  We in fact do have numbers that are
routable, but not accessible as E.164s.

We have a gateway to our PBX.  If you send it a uri of the
form tel:3042348, it will dial it correctly.  However, if you
send that uri to a gateway in my home, it won't dial my colleague.
Until a year ago, it would have connected you to 724-304-2349,
but today you would just get an intercept.

So, what is my "context"? And how do I use it?
Right now, my sipphone is dumb, it sends dial strings.  My proxy
has a dial plan, and it expands dial strings to numbers.
You are advocating that we move the dial plan processing into
the UA.  I'll agree that that would work.

What I don't understand is what I can then do with context.  
If I have the dial plan in the UA, then what it emits is a legal 
number in the domain represented by that dial plan. 
Subsequent proxies should be able to route it.  
They might even substitute the number in the Request-URI 
(doing the translation from 9-1-703-559-2348 to 304-2348 
for example).  I might indeed know that the local context
is "Marconi Pittsburgh", but what would any downstream entity do
with that?  Any call within the domain has that context, and 
if the call got outside the domain, the number is probably wrong.
For example, the "304" doesn't work in Marconi, UK, they have a 
different prefix.  The only way that the call can get outside 
the domain is to have some routing error.  If I had the context,
I could return an error if I didn't understand it. I think we get
into heaps of trouble when the routing sends you through a domain
that doesn't know the context, but can route the number 
none-the-less, to a domain that does understand the context
(Marconi Pittsburgh -> WorldCom -> Marconi UK)

The same problem can happen with a sip uri, and we don't do anything 
to detect or repair damage in that case, why would we do so in 
this case?  Not all sip uri's are globally routable!

My home proxy would know that 304-2348 is not a legal number,
because the local (ie home) dialing plan wouldn't include it.
The closest I can come to having a use for context is that
if I had a contact database, I could have 304-2348 in it with
a context of "Marconi Pittsburgh".  Then, my UA could figure
out that it can't use that number unless I'm in that domain.
That is not something we could really say is part of our charter.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, January 24, 2003 2:35 PM
> To: Rosen, Brian
> Cc: 'Christer Holmberg'; [email-masked]'; Conroy, 
> Lawrence (SMTP);
> [email-masked]'
> Subject: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> There seem to be at least three scenarios:
> 
> (1) The end system has a dialplan, learned automatically, and 
> can easily 
> translate dialed digits into an E.164 number. We clearly need 
> this and I 
> should have a micro-draft on this shortly. This hinges on the 
> whole UA 
> configuration mess, which has not made much progress. I think this 
> solution has the greatest flexibility, as it allows users to 
> carry their 
> dialplans with them as well as get local ones. It also allows 
> inspection 
> - a device can easily display what will happen to a digit 
> string. If the 
> proxy does translation, you only find out when what you thought was a 
> local extension gets translated to dial-a-prayer. (Or, worse, doesn't 
> get answered at all, in which case one may not suspect 
> anything amiss.)
> 
> (2) However, there are apparently some numbers that are not 
> translatable 
> to E.164 numbers. Effectively, they are a different namespace that is 
> valid only locally. As I've mentioned before, IBM has two phone 
> namespaces internally, judging from their business cards. The 
> extension 
> is *not* directly related to the externally reachable number. 
> Thus, the 
> end system cannot produce an E.164 number without doing some kind of 
> directory lookup.
> 
> (3) The end system has no dialplan (e.g., because the current 
> products 
> don't support this). Then, the local proxy needs to do the 
> translation. 
> Here, there seem to be two options:
> 
> (3a) Allow this non-unique, non-global dialed number and effectively 
> declare it "whatever this happens to mean at the first proxy this 
> request meets - and good luck".
> 
> (3b) Mark with context, so that you can detect if expectation and 
> reality don't match.
> 
> In general, as 2806bis tries to express, globally unique URIs 
> are best 
> for everyone - no confusion, no ambiguity. The question is whether we 
> can get rid of the cases (2) and (3) above that don't work 
> that way. I 
> don't think just having (3a) is a viable option if we want to build 
> reliable and testable systems.
> 
> Rosen, Brian wrote:
> > Either we treat a tel URI like a sip URI, which means you can
> > do substitution on the Request-URI, but we have no concept of
> > "context" or we should implement dial strings and let the
> > proxies do the expansion.  It doesn't make any sense to me
> > to have the UA have some knowledge of translating dial strings
> > to fully routable numbers, but not all the knowledge.
> > 
> > This thread, and the dial string thread have yielded lots of
> > examples of why context is not a functional mechanism.  So,
> > I propose we get rid of it, one way or the other.
> 
> I have heard examples of why it might be inconvenient for current 
> shipping phones. I have not heard why it would not work.
> 
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 24 Jan 2003 15:53:31 -0500

> routable, but not accessible as E.164s.

Glad there's another example...

> with that?  Any call within the domain has that context, and 

Leaving aside that existing SIP phones aren't configured with this 
(which is presumably a fixable problem):

Your phone in your office would be configured with the context, just 
like it now gets configured with the local outbound proxy. This 
configuration can be part of the permanent device configuration or it 
can be acquired dynamically from the outbound proxy. Both approaches 
have value:

(1) Device-associated configuration of the context means that the dial 
strings have the same meaning (or no meaning) wherever you take the 
phone, but you'll never get a dial string that means something to mean 
something else in a different place.

(2) Proxy-associated configuration of the context has the opposite 
properties: you guarantee that the dial string is meant to be translated 
by it, but you might mistakenly dial your intra-office extension at home 
and get whatever the proxy makes it to be.

Both are valid and useful depending on the type of user interface 
characteristics you want, but you need the context to reliable detect 
what's going on, rather than having the proxy guess.

One way to think of the context is as a token that identifies the 
translation table ("dialing plan").

> (Marconi Pittsburgh -> WorldCom -> Marconi UK)

That was never the intent. All tel URIs are either resolved by the first 
proxy or they are ditched with an error response (404, presumably). The 
context intentionally does not have enough information to route it to 
some other entity. (It comes close in the DNS form, but I don't want to 
go there.)

> this case?  Not all sip uri's are globally routable!

They should be globally unique, even if they are not globally routable. 
A SIP URI should never mean Alice in one place and Bob in another.

> because the local (ie home) dialing plan wouldn't include it.

You are lucky in this case. For many dialing plans, the shape of the 
number may well be the same.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jan 2003 18:21:26 -0500

Brian,

I think you have provided some good questions to pursue, and I don't 
have the final answers on them. But I will venture an opinion:

If your phone had an internal dial plan, it should know the context it 
is in. So if from your phone you dial 304-2349, it could translate that 
to something like:

	tel:304-2349;phone-context=pittsburgh.marconi.com

This is then sent to your local proxy, which understands the context and 
knows how to route the call.

Now suppose that same phone calls me at sip:[email-masked]. It isn't 
a globally routable phone, so it puts that same address in the From 
header. My phone is smart and remembers the From address for future 
reference, in my address book.

I may eventually try to return the call using the saved url. Two things 
can happen:
1a) the proxy I use never heard of the context, and fails the call. 
(That would certainly be the case if I tried it from inside Cisco.

2a) maybe I was visiting a marconi facility and have plugged into the 
network there. With a great deal of luck and provisioning, I might find 
myself sending requests to a marconi proxy that understands the context 
and can route the call. This could even work if I was visiting marconi 
in the UK.

OTOH, suppose the phone doesn't bother with context and simply encodes 
the dial string as tel:3042349. Then different things happen in the 
cases above:
1b) if my local proxy uses the same sorts of conventions, it will try to 
interpret the number 3042349 in my local context. With luck it will just 
fail. It is also possible that it might work, which would be worse since 
it will be calling the wrong destination.

2b) if I happen to be visiting marconi pittsburg, the call will perhaps 
work. If I am visiting marconi uk I guess it will fail.

I think including the context in numbers helps. It ensures that numbers 
are at least universally unambiguous even when they aren't universally 
dialable.

	Paul