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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Jan 2003 10:51:37 -0500

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

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 24, 2003 9:17 AM
> To: Henning Schulzrinne
> Cc: Christer Holmberg; Conroy, Lawrence (SMTP); [email-masked]
> Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> Henning Schulzrinne writes:
> 
>  > One of the underlying SIP assumptions is that we should treat each 
>  > terminal as mobile, i.e., you should be able to plug it in 
> anywhere in 
>  > the Internet and it should work (modulo NATs and firewalls).
> 
> even mobile terminals using local numbers would work ok w/o context
> configuration if the terminal is using a local proxy.  only in case
> where the terminal uses some non-local proxy and local numbers the
> context needs to be configured.  and if it does so, how does the user
> know what to put in to the local context?  are you suggesting 
> it learns
> it via dhcp or how?  where is the spec for that?
> 
>  > If I take my shiny IP phone home from work, my outbound 
> proxy changes. 
>  > If the phone has no context, I will likely get obscure 
> failures or, in 
>  > the worst case, reach the wrong destination.
> 
> we could say that the lack of explicit context means use the 
> context of
> the user's home proxy.  that would cause the call via a 
> foreign proxy to
> fail w/o context.
> 
>  > Nobody can keep you from omitting phone-context in a phone and 
>  > back-fixing this in a proxy. However, that does not mean 
> that the WG 
>  > should endorse such behavior in documents, particularly 
> given that the 
>  > cost of configuring IP devices with phone context is close to zero.
> 
> configuration complexity will certainly increase in many 
> common cases if
> the context is made mandatory.  and how about backwards compatibility
> with today's sip phones?  i don't know any that supports context
> configuration.
> 
> -- juha
> 
> 
> 
> _______________________________________________
> Iptel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iptel
> 
_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2003 20:35:46 +0200

Hi,

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

> 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