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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 27 Jan 2003 14:06:08 -0500

I can see including a context token as a confirmation, or even selection
of the dial plan domain to be interpreted by a proxy.  I see the value.  
The text in 2806bis can get considerably smaller and more focused, right?
It would seem that most of the confusion on context then goes away.

So, summarizing:
 a) The preferred mechanism is UA has dialing plan.  We will standardize
	a notation, and a method to learn it
 b) We support a proxy translation of dial string to routable numbers.  
	We should choose ONE way to send a dial string.  
	I personally like sip:dialsting@domain, with or without user=phone.

	It could have the context parameter.
	If we use a tel uri, then text in 2806bis about dial strings must
change
 c) The context is either learned from the environment (DHCP?), 
	or provisioned.  It is always included in the URI when the number
	is not known to be directly routable (not correct to say global)

A UAC either expands dialstrings to routable numbers and emits a tel uri,
or it sends dialstrings with a context.  A proxy server either routes
a tel uri without a context, or expands a dialstring to a routable uri
from the dialstring+context.

Contexts need to be unique within the domain of a proxy server and all
the UAs that might get service from it.  I think that if you allow
contexts to be provisioned in the phone, that we should have some kind
of naming convention or something.  If they were always learned, then
they would just have to be unique within the domain they were learned
from.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, January 24, 2003 6:03 PM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: Re: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers
> 
> 
> > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> 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.
> 
> 
> > 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.
> 
> 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
> 
_______________________________________________
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: Michael Hammer <[email-masked]>
Date: Mon, 27 Jan 2003 14:29:42 -0500

Brian,

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

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.

Mike

At 02:06 PM 1/27/2003 -0500, Rosen, Brian wrote:

I can see including a context token as a
confirmation, or even selection

of the dial plan domain to be interpreted by a proxy.  I see the
value.

The text in 2806bis can get considerably smaller and more focused,
right?

So, summarizing:

a) The preferred mechanism is UA has dialing plan.  We will
standardize

a
notation, and a method to learn it

b) We support a proxy translation of dial string to routable
numbers.

We should
choose ONE way to send a dial string.

I
personally like sip:dialsting@domain, with or without user=phone.

It could
have the context parameter.

If we use
a tel uri, then text in 2806bis about dial strings must

change

or
provisioned.  It is always included in the URI when the number

is not
known to be directly routable (not correct to say global)

A UAC either expands dialstrings to routable numbers and emits a tel
uri,

or it sends dialstrings with a context.  A proxy server either
routes

a tel uri without a context, or expands a dialstring to a routable
uri

Contexts need to be unique within the domain of a proxy server and
all

the UAs that might get service from it.  I think that if you
allow

contexts to be provisioned in the phone, that we should have some
kind

of naming convention or something.  If they were always learned,
then

they would just have to be unique within the domain they were
learned

from.

Brian

Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping

---

From: Michael Hammer <[email-masked]>
Date: Mon, 27 Jan 2003 16:43:15 -0500

Brian,

I'm following you now.  Part of my problem was reading the statements 
within the context of "how to handle non-global tel: URI."  I was reading 
it as forwarding on to an arbitrary server with a non-global URI without 
context.  The onward routing with global URI or full context is now 
clear.  Your example option of configuration to route by exception handling 
to another proxy that is expected to figure it out shows that this will be 
implementation dependent.

Mike

At 04:23 PM 1/27/2003 -0500, Rosen, Brian wrote:
> >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.
>
>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

---

From: "Dusan Mudric" <[email-masked]>
Date: Tue, 28 Jan 2003 10:23:46 -0500

With introduction of a new technology, VoIP, legacy attributes should stay at the edge. By introducing Tel routing in IP, unnecessary dimension is used. IP already has a clean way to route. 

Why not just keep tel numbers in PSTN and names and IP's in IP? Every tel number has its owner with a name. It would be straightforward to route from IP to PSTN edge based on the name and at the edge translate that name into a tel number. From PSTN to IP, translate a virtual tel number into a name and get to the IP UA. In the near future, when everybody switches to IP (I wish :-) ), we will call friends by names only.

Dusan Mudric

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 8:32 AM
To: 'Paul Kyzivat'
Cc: 'Michael Hammer'; 'Henning Schulzrinne'; [email-masked]'
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers

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

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, January 27, 2003 6:06 PM
> To: Rosen, Brian
> Cc: 'Michael Hammer'; 'Henning Schulzrinne'; [email-masked]'
> Rosen, Brian wrote:
> 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.
> 
> 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
>

---

From: "Dusan Mudric" <[email-masked]>
Date: Tue, 28 Jan 2003 11:39:27 -0500

There are translators at the IP-PSTN edges. Existing tel number subscribers get registered at the PSTN-IP edge device with {name, tel_number}, which we already have in telephone books. Their names are visible from the edge device to the rest of the IP world. When an IP UA-A calls a party B in a PSTN by name, the call gets routed to the edge device that registered a PSTN subscriber B. From there on, a PSTN routs the call to a party B based on its tel number.

Dusan

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 10:34 AM
To: Dusan Mudric
Subject: RE: [Sipping] Re: [Iptel] Re: [Sip] TEL-URL local numbers

How would you route to someone who has only a telephone number and no SIP 
address?

The SIP network is only useful if it can route to everyone on the PSTN.

Mike

At 10:23 AM 1/28/2003 -0500, you wrote:
>With introduction of a new technology, VoIP, legacy attributes should stay 
>at the edge. By introducing Tel routing in IP, unnecessary dimension is 
>used. IP already has a clean way to route.
>
>Why not just keep tel numbers in PSTN and names and IP's in IP? Every tel 
>number has its owner with a name. It would be straightforward to route 
>from IP to PSTN edge based on the name and at the edge translate that name 
>into a tel number. From PSTN to IP, translate a virtual tel number into a 
>name and get to the IP UA. In the near future, when everybody switches to 
>IP (I wish :-) ), we will call friends by names only.
>
>Dusan Mudric
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 28 Jan 2003 13:06:34 -0500

The assumption you are making is that every person who does not
have a sipphone is in a database that the gateway can access.

I think that's pretty tough to arrange.

Also has the small problem of multiple people with the same name.

Brian

> From: Dusan Mudric [mailto:[email-masked]]
> Sent: Tuesday, January 28, 2003 11:39 AM
> To: Michael Hammer
> Cc: [email-masked]
> There are translators at the IP-PSTN edges. Existing tel 
> number subscribers get registered at the PSTN-IP edge device 
> with {name, tel_number}, which we already have in telephone 
> books. Their names are visible from the edge device to the 
> rest of the IP world. When an IP UA-A calls a party B in a 
> PSTN by name, the call gets routed to the edge device that 
> registered a PSTN subscriber B. From there on, a PSTN routs 
> the call to a party B based on its tel number.
> 
> Dusan
>

---

From: "Dusan Mudric" <[email-masked]>
Date: Tue, 28 Jan 2003 14:04:51 -0500

>I think that's pretty tough to arrange.

It's feasible. It will be even tougher to introduce, maintain and phase out another (telephone number based) routing schema in IP.

>Also has the small problem of multiple people with the same name.

That was just an example. A globally unique or unique name within a domain is what everybody got accustomed to using emails.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 28 Jan 2003 14:08:46 -0500

Actually, every UAC would need to be able to access such a directory of 
every PSTN phone number in the world and a map to a SIP address to avoid 
sending a tel: URI into the SIP network.  And it would have to change every 
time a new person gets a new phone number or a phone number changes.  Why 
should the SIP community set up a directory to create and manage SIP 
addresses which map to PSTN phone numbers for non-SIP users?

Mike