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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 27 Jan 2003 16:23:54 -0500

>You use context in singular fashion as though the UAC only has one.  
>Could it not be operating within multiple contexts?  I can imagine 
>that it may have to learn and store more than one, depending on who
>is intended to consume the URI.  (such as a home and visited context)
I don't know.  I guess I'm not opposed if it doesn't make things
a lot more complicated.  

I think as a practical matter, it's pretty hard to manage more than one.
You would need some kind of UI that let you choose, so that your
dial string could be interpreted differently.  That's an 
implementation issue.

From a standards perspective, you can only get one from something like
DHCP.  You could get one each for every AOR if you had more than one,
if instead of learning through DHCP it was, say, PUBLISHED as a 
consequence of registration.  I've thought of that.  You also get one 
per phone if it's provisioned in the phone.

On the other hand, there is no reason to restrict the UA from having
more than one.

>I would hope that "A proxy server either routes a tel uri without a 
>context" means that a proxy can accept such a tel uri as an incoming 
>value, but never as an outgoing value.
Confusion.  A tel uri without a context means it's either global or 
at least routable with no further expansion.  So, a proxy server would
definitely put such a uri as an outgoing value.

>Wouldn't the context need to be globally unique, so that a tel uri 
>that leaves the domain can be understood.  Did you mean that the 
>tel: value must be only unique within the identified context?  Or 
>did you mean to say that there are multiple contexts passed out by 
>a proxy server that will make all addresses unique before exiting 
>the domain of that proxy?  Not sure I followed that last paragraph fully.
I thought that contexts needed to be globally unique but Henning
asserted otherwise.   As long as the UA and the interpreting proxy
agree on a naming, it's okay.  How it figures that out is not
specified.  I think that's okay; if Marconi's domain has a convention
that, say, contexts are of the form "<location>-marconi", and
all contexts the UA learns/provisioned are in that form, all is well.

So, the requirement is that the proxy understand the context, or it
will return an error.  The proxy has to output a routable (which could
be global) tel uri for the combination of dial string and context,
for all contexts it implements.

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.

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.

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: Mon, 27 Jan 2003 16:39:31 -0500

> asserted otherwise.   As long as the UA and the interpreting proxy

Wait - where did I say that the context identifier is not globally 
unique? That's the whole point of the identifier... It may not be 
uniquely determined in the sense that a single context could have 
several different possible names (all unique), so there is way of just 
guessing the right name. For example, you can name your context 
marconi.com, your global phone prefix or some other DNS-based identifier 
that's yours.

> would need routing rules to be able to do that.

I agree it shouldn't be outlawed, but it will always be manual 
configuration, with the attendant problems.

> routable number and redirects the call, coventry can "least cost

Once you get through all the complexity, I suspect that it's easier to 
just use SIP URIs with phone user parts. However, since the point is to 
document all the variations and this is certainly one of them.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jan 2003 18:06:07 -0500

> 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];user=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.

> routable number and redirects the call, coventry can "least cost

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