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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Jan 2003 16:24:25 -0500

> 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.
There is a third possibility, which is that the dialing plan
is associated with the AOR.  I dial the same way on every
sipphone I register with, wherever I am.

We've been around this dilemma (do you want the dial string to remain
constant when you roam, or do you want the local context).  As you
seem to agree, there is no really right answer.  We've come to
the conclusion that it should be the local dialing plan for where
you are.  There seem to be fewer problems and it's the way the PSTN
and all PBXs work now.

I actually think we are best to standardize the behavior one way or
the other.  It is a standards issue, regardless of how we implement
it (if you substitute "dialing plan" for "context" your explanation
above makes the same argument).
> 
> 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.
I don't think so, or rather, I think there are too many problems to
make it be that way.  This whole thread is about problems with
context.

As yet another example, what is my context?  Is it "Marconi Pittsburgh".
Is that globally unique?  Or is it "+1724742"?  That's globally unique,
but may or may not be useable by my first hop proxy.

I think we either get rid of it, making the dialing plan the last word,
or make the dialing plan the job of the first hop proxy.  I fail to see
the advantage of dialing plan in the UA and first hop proxy interpreting
context.

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

...snip...

> 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.)
To me, that makes context even less interesting.  You require the
first hop proxy to understand all contexts that could be generated by
any UA it serves.  That would make it pretty hard for you to bring
your office phone home if your ISP provided your first hop proxy. 

I think it's best to either have the dialing plan have to make sense
to the first hop proxy (by making the local domain the source of
the dialing plan, your #2 above), or make the proxy responsible for
turning digit strings into routable numbers.  I don't see enough
utility in having the dialing plan associated with the phone itself.

Brian
_______________________________________________
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 18:03:11 -0500

> but may or may not be useable by my first hop proxy.

The point is that you and your first hop proxy better agree on 
something, choosing one of the mechanism in 2806bis, such as a prefix or 
a domain name. What you pick is immaterial - it is invisible to the user.

If you can't agree on that, it is very unlikely that you can agree on 
what actually happens in the translation. Once you have automated 
configuration (at the device, AOR or outbound proxy level), it doesn't 
matter what it is called, as long as you pick something that's unique. 
2806bis provides two reasonable mechanisms. I don't see this as an issue.

> the advantage of dialing plan in the UA and first hop proxy interpreting

You would never have both at the same time in the same installation, but 
I don't think we're in the business of picking architectures here. My 
proposal allows choice. If you don't like to run context in your 
products or installation, don't. I happen to think that UA-translation 
is best, as it is in the endsystem-is-smart spirit, but others seem to 
want proxy translation. Proxy translation without context is extremely 
brittle.

> utility in having the dialing plan associated with the phone itself.

The point is that I want to be warned if the translation is done by 
somebody that shouldn't. This becomes even more important when you put 
tel URIs on web pages.

Henning

---

From: [email-masked]
Date: Sat, 25 Jan 2003 10:40:39 +0200

> above makes the same argument).

i don't agree that is the task of a standards body to decide that a user
needs to always the local dial plan.  it should be up to the user to
decide if he/she wants local dialing or "home" dialing.  

one way of making this decision is by the phone's preloaded route
set.  en empty route set results in local dialing via the outbound proxy
and a route set that includes the user's home proxy results in "home"
dialing.

why would i need in addition to the preloaded route set specify the
context of the number in the tel uri?  looks to me that brian raised
the same issue.

-- juha