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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Jan 2003 13:53:43 -0500

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.

Brian

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, January 24, 2003 1:36 PM
> To: Rosen, Brian
> Cc: [email-masked]'; Henning Schulzrinne; Conroy, 
> Lawrence (SMTP);
> [email-masked]'
> Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> 
> Hi,
> 
> > [I put this on sipping because it's a sip issue.  When we 
> settle what
> > we want in a tel uri, we can go to IPTEL to get it]
> >
> > We just went through a thread on dial string expansion.
> > This is just more of the same issue.
> >
> > At this point, I think we should take a step back and figure
> > out where we want to end up, because it seems to me that
> > we are going to have to make something non-backwards-compatible.
> >
> > I think there are only two reasonable endpoints:
> > 1. The UA does it all.  UAs never send anything that can't be
> > sent to the right gateway and succeed.  Proxies can route to the
> > appropriate gateway, but they never add (or subtract) anything
> > from a tel uri (or any other header) - the UA always sends
> > a full phone number (of course, redirect is still possible).
> 
> [CHH] I don't think that is true. Proxies can replace the 
> Request-URI, and
> who says that the replacement can't be the same header as 
> received, but with
> some additional parameters?
> 
> > This means that the UA has a dialing plan, which it must learn
> > from the local environment, so that it can translate from
> > something the user enters into a full address.  It also
> > means context disappears as a concept (it's in the dialing plan).
> 
> [CHH] I don't think the UAC has to send something which can 
> be routed all
> the way to the UAS. Intermediate proxies can take the Request-URI,  do
> whatever lookups to find where to route the message, and, 
> again, replace the
> received Request-URI value with a new value if needed.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> >
> >
> > 2. The UA sends a dialing string and downstream proxies
> > translate to routable numbers.  We can argue what tel URIs
> > and headers look like to do this.  It's possible a proxy
> > adds a context if it knows some of the expansion rules.
> > but not all of them.
> >
> > It doesn't seem reasonable to me to try to walk a tightrope
> > between these two extremes.  We keep getting tripped by
> > reality.
> >
> > 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 14:35:04 -0500

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.

> 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.

---

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

Henning Schulzrinne wrote:
> translate dialed digits into an E.164 number. ...  It also allows inspection

There is a solution to this problem when using proxy expansion: The 
proxy can do the expansion and then return the result as a redirect 
(probably 301). The phone will then retry, but can display the new number.

But this doesn't work for From. The calling phone had better know an 
expanded form of its own address.

	Paul