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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 28 Jan 2003 08:31:59 -0500

I observe that if you know a context name you (can) know the domain that
the context is valid in.  That is true however the UA learns the
context.  

If we make a naming convention on contexts that includes the domain
(ie. contextname@domain), then a proxy can, if it does not understand
that context, forward to a proxy in the domain which would. 

I'll note that I really dislike putting parameters in the 'user' part
of a uri.  URI parameters are inexpensive, we should use them.
On the other hand, I'd prefer ONE way to do things.  So, a tel uri,
with a uri parameter of context, might be the best one way to go,
rather than putting more stuff into sip:... ;user=phone.
The contrary point of view is that the sip form has a domain,
which makes it more easily routable by intermediaries, most of whom
won't know how to route a generic tel uri.

It might be interesting to document somewhere that redirect should
be used when a proxy interprets a context where the call did not
originate in the domain of the proxy that does the interpretation.
Might be best if that was only if the translated number is globally
routable (otherwise you could have a translated number that
is a different destination in the originating domain than in the
translating domain).  If it's not globally routable, then the
translating domain is probably best to just route the call rather
than redirecting it.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, January 27, 2003 6:06 PM
> To: Rosen, Brian
> Cc: 'Michael Hammer'; 'Henning Schulzrinne'; [email-masked]'
> Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> 
> 
> Rosen, Brian wrote:
> > 
> > Actually, it's not clear to me that we have to be quite so 
> > restrictive. It is possible that the rule is actually that 
> the proxy 
> > has to be able to either translate to a fully routable tel 
> uri OR that 
> > it has to forward it to a proxy that can do that.  If, for example, 
> > I send [email-masked]; context="coventry-marconi", the local 
> > (roaming) proxy at pit could forward the call to 
> coventry.marconi.com 
> > for processing using the coventry-marconi context.  The pitt proxy
> > would need routing rules to be able to do that.
> 
> Detail: I can't quite figure out what you intend. I think you are 
> proposing sending to
> 
> sip:8977;phone-context=[email-masked];user=phone
> 
> but that isn't quite legal. Things that would be are:
> 
> tel:8977;phone-context=coventry.marconi.com
> sip:8977;phone-context=[email-masked];u
> ser=phone
> 
> There there isn't necessarily any relationship between the 
> proxy names 
> and the context names, but I have made them the same to suggest there 
> might be a meaningful relationship in this case.
> 
> > Having said that, if my home is pitt, I roam to coventry and invite
> > someone in coventry, I don't want pitt's routing to send the call to
> > a gateway in Pittsburgh!  If pitt expands the number to a globally
> > routable number and redirects the call, coventry can "least cost
> > route" it.
> 
> There are several possibilities here. (I assume when you roam to 
> coventry your outbound calls transit the coventry.marconi.com 
> proxy first.)
> 
> 1) if you use the tel: form above, the proxy naturally 
> understands the 
> context and routes the call directly. Your home proxy isn't 
> involved at all.
> 
> 2) if you use the sip form above, the coventry proxy is supposed to 
> honor the domain, and forward the call to the pitt.marconi.com proxy.
> 
> 2a) the pitt proxy might use a pitt gateway - your worst fear 
> confirmed
> 
> 2b) the pitt proxy might redirect to some global number (e.g. 
> tel:+445558977) and then the local proxy would use a local gateway to 
> get there.
> 
> Now instead, assume that you had roamed to coventry and are trying to 
> dial a number 1234 in pitt:
> 
> 3) you might use tel:1234;phone-context=pitt.marconi.com and 
> send it to 
> the coventry proxy.
> 
> 3a) the coventry proxy might know the context and know that 
> the best way 
> to get the call there. For instance it might by default 
> forward the call 
> to the pitt.marconi.com proxy, but if that fails it could 
> also know to 
> translate the address and use a local GW.
> 
> 3b) the coventry proxy might not know the context, but might have a 
> convention to automatically route calls to unknown FQDN style 
> contexts 
> to a sip proxy with that name.
> 
> 4) you might use 
> sip:1234;phone-context=[email-masked] and 
> send it to 
> the coventry proxy. In this case the coventry proxy must 
> forward to the 
> pitt proxy which will then probably use a local gw.  This is 
> almost as 
> good as (3a) except with the sip path is down between 
> convenry and pitt.
> 
> 
> My conclusion is that using a tel: gives the most options to 
> do things well.
> 
> 	Paul
> 
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jan 2003 16:46:51 -0500

> the context is valid in.  That is true however the UA learns the

No. At least all I suggested is that if you know the context name you 
may be able to guess *a* (not *the*) domain the context is valid in. The 
context may be valid in many domains. (In fact, I gave an example where 
a context was valid in two domains.)

> that context, forward to a proxy in the domain which would.

Well, that particular convention won't work, but yes I was suggesting a 
convention with this property - if the context is in FQDN format, try 
using that as a next hop domain name.

> of a uri. 

Why? The sip representation of a tel: url uses them. Life is tough.

 > URI parameters are inexpensive, we should use them.

Parsing is parsing. What does it matter which part of the url you parse 
to get them?

If you use a tel: url directly, then they are url parameters. Does that 
make you happier?

> won't know how to route a generic tel uri.

Its ok to switch to the sip: form once you are in a position to 
intelligently decide what domain to use. From then on intermediaries 
don't need to understand tel:

This decision can even be made in the UAC if its smart enough. But this 
still leaves the To in tel: form. It isn't used in routing so it can and 
should stay that way.

> translating domain is probably best to just route the call rather

It might take a lot of talking to come to agreement on the details. But 
perhaps we could agree that when a proxy decides a translation is 
something the caller would like to know it should use a redirect, and 
when the UAC receives such a redirect is should display the action to 
the caller.

	Paul