Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy

From: "Stastny Richard" <[email-masked]>
Date: Wed, 17 Aug 2005 18:14:35 +0200

I fully agree that there seems to be an issue here,
because the problem is currently discussed at voipeer
also.The format sip:[email-masked];user=phone 
gets very important especially for Carrier ENUM indicating
the destination providers (see below)
 
It also concerns the CLI and CLIR aspect not yet fully discussed
in voipeer. This is one issue definitely in scope of voipeer.

comments inline 
 
Jonathan wrote:

>I'll reply to some of the technical comments inline, but I want to step
>back a second here.

>All of this discussion is making it clear that there is a MUCH bigger
>mess here that needs attention, around phone number usage,
>interpretation and equivalence across tel and SIP URI. This is a common
>source of interop problems in the wild and it makes sense to address it.

I fully agree. At voipeer the question is raised what format to use
if E.164 or phone numbers in general are to be transmitted between peers.
also in the to: field

>However, the problem at hand is to complete the common policy document,
>and it seems to me a mistake to hold up common policy until that mess is
>sorted out. Furthermore, I would argue that the common policy spec is
>not the place where that mess should be sorted out.

Could this be done in voipeer ? Or at least partially
The problem is that only a special aspect of the semantic
of the usage of these URIs is under discussion;
namely the usage for signalling

>My suggestion therefore is to keep the "id" attribute as an NAI form,
>and make sure common policy is extensible to allow other ways of
>representing identities in the future. We then declare phone numbers out
>of scope for this version of common policy, finish that spec, sort out
>the tel/sip uri mess, and when thats done, we can issue an extension to
>common policy that adds phone number support.

>more inline.

>Paul Kyzivat wrote:

>>
>> Aki Niemi wrote:
>>
>>> Hi Paul,
>>
>>> ext Paul Kyzivat wrote:
>>>
>>>> Then what do you do with sip:[email-masked];user=phone ?
>>>>
>>>> I don't think you can convert it to:
>>>>
>>>>    4.3.2.1.5.5.5.2.3.2.1.foo.com
>>>>
>>>> and if you could then it it wouldn't match the e164.arpa form.
>>>
>>>

No you can't

>>>
>>> Well, 'sip:[email-masked];user=phone' is indeed a tricky
>>> identity to put into a From header in the first place. I'm not sure it
>>> is a telephone number at all. Why wouldn't the From include a tel URL?

This is an interesting point I have not considered yet. Thinking
about it, I would prefer a tel URI in this case. This is IMHO an
issue where voipeer could make a BCP.

>>
>>
>> Personally, I generally think it should. However I have run into many
>> people who don't seem to believe in tel URIs, and always use the sip
>> form. I would like to convince them of the error in their ways, but no
>> luck so far.

If one uses the sip URI, it has to be defined what the foo.bar is:
Is it the domain of the originating service provider or the domain of
the provious hop, being modified each time?

>I think the problem is that we've not made it clear what the semantic
>differences really are.

>>
>> The other case is when I really, definitely, only want to be contacted
>> via SIP.

In this case you should use a SIP alias and not a phone number,
because sip:[email-masked];user=phone is the equivalent
to a phone number

>>
>>> I suppose that matching a SIP URI converted from a tel URL will be a
>>> problem regardless of the way in which we choose to represent them in
>>> common policy.

I do not think so. Especially if you use global numbers (E.164 numbers)
only you can map back and forth as much as you like, done properly, it
should always be the same number.
>>
>
>> I am relaxing my theoretical objections in favor of pragmatism, and
>> suggesting that for purposes of determining what authorization policy to
>> apply it will be ok to treat this as a phone number.

>Stepping back for a sec, I think there are real differences between the
>tel URI and the sip version. The way to think about it is that the tel
>URI is a NAME, and you need to think of it as if it were a URN. A SIP
>URI is an address. Procedures like enum allow the resolution of a name
>to an address.

Hmm. We should not go down this path ;-? This is not so simple: 
This is also a terminology problem between differnent standard bodies

A phone number could also be a name and  an address, In ITU and
ETSI terms a sip AoR or email address is also a name. Only an IP-address
is an address.

Also with SIP URIs you may have:

A. A SIP AoR, which is a name
B. A SIP Contact Address, which is either a name or an (IP) address
C: A SIP URI with parm user=phone, which is a phone number (a name?)
D. A GRUU, which is ?

>As such, it really makes no sense to compare a name and an address. Just
>because I work at 600 Lanidex Plaza in Parsippany, does that make
>"Jonathan Rosenberg" (a name) equivalent to "600 Lanidex Plaza,
>Parsippany, NJ 07054"? Definitely not. So, I would argue that the tel
>URI and SIP URL are NEVER equivalent; you need to convert the name to an
>address for comparison.

I cannot fully follow this argument:

Lets try it in another way. There is other usages for URIs

A. You put it on a webpage to be clicked on:
In this case you would either use a plain tel URI to indicate a phone number
or a sip URI in the format sip:[email-masked] to indicate rachability via sip
In the first case the client linked to the tel URI may even chose to use a dialler
in the second case it wold indicate to use a sip-client. If you use
sip:[email-masked];user=phone , this would indicate also to use
the sip client?

B: in ENUM. (now we are finallyat the point ;-)
If one queries ENUM for the phone number +1-232-555-1234
it would be completely useless to get back the same 
number in tel:+1-232-555-1234

we need here sip:[email-masked];user=phone with
the same number to indicate the foo.com domain of the carrier
This is basically the essential information

Of course one could also put in sip:[email-masked], but only
in User ENUM, in Carrier ENUM this will not be possible for privacy reasons.

C: the nect, yet undicided question is what you use in case B within signalling
now in the to field: the tel URI or the sip URI returned by ENUM.
Current practice here is to use the SIP URI.

>Givne this, the meaning of sip:<phone-number>@domain;user=phone means
>that the domain is asserting ownership of the identity in the user part,
>in this case a global phone number. As such, its appropriate to use this
>form only when it is authoritatively known that the domain in question
>"owns" that phone number.

This is a very interesting aspect, leading to the CLI and CLIR problem
not yet discussed fully in voipeer.

The CLI problem is IMHO definitely in scope of voipeer. CLI is required
for call-back (especially if gatewaying to the PSTN), for MCI to emergency services
and also requires CLIR support for anonymous calls.

>-Jonathan R.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Aug 2005 23:04:24 -0400

inline.

> if E.164 or phone numbers in general are to be transmitted between peers.

I see this probably as having little to do with peering. Its a problem 
in general for SIP, and confusion on the interpretation exists between 
clients and there proxies, proxies and proxies, and so on.

> namely the usage for signalling

Per above, I think that is a mistake. Sorting out the differences 
between tel URI, SIP uri with and without user=phone, and so on, are 
general sip problems.

> ETSI terms a sip AoR or email address is also a name. Only an IP-address

There are addresses at all layers in the stack. We have IP addresses, 
but also MAC addresses. You translate from one to the other. Something 
is an address when it identifies an object by its location. In that 
sense, the SIP URI is fundamentally an address, in that the presence of 
the domain part indicates that we are identifying something by its 
location.

> C: A SIP URI with parm user=phone, which is a phone number (a name?)

Actually based on the definitions above, all are addresses, even an AoR. 
  After all, the A in AoR stands for "address".

> sip:[email-masked];user=phone , this would indicate also to use

The usage of a URI for different applications is quite separate from 
whehter a URI represents a name or an address, and separate still from 
equality rules for these things.

My point is that I think it makes sense to consider the tel URI a URN, 
and that it is merely an accident of history that it wasn't a URN more 
properly. Now, as you and I both know phone numbers in the PSTN are 
abused to represent lots of things, but there is no reason to carry 
forward this confusion into voip. This is why I am proposing that when a 
phone number is in a tel URI, it represents a name. We don't know where 
it is on the network (indeed even if its on an IP network). To know 
that, we translate to an address. That address is a SIP URI. That SIP 
URI can contain a phone number, i.e. 
sip:[email-masked];user=phone, however in this format the 
phone number has been resolved to an address. The act of porting a 
number is a change in the translation of the phone number as a name (the 
tel URI) to the phone number as an address (the SIP URI).

> number in tel:+1-232-555-1234

Agree. My point is exactly this; had tel URI been a URN proper, than 
enum would exactly be the resolution service for resolving that URN 
scheme to a SIP URI.

> This is basically the essential information

Right, and this is an address.

> not yet discussed fully in voipeer.

I don't follow what you are talking about here.

> and also requires CLIR support for anonymous calls.

We have numerous specs covering conveyance and assertion of identities. 
See in particular draft-rosenberg-sip-identity-privacy which talks about 
how to properly support anonymous calling with draft-ietf-sip-identity.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 18 Aug 2005 12:33:17 +0200

> tel URI) to the phone number as an address (the SIP URI).

This is a very sensible notion.

Based on this thinking the dialing of a number on a VoIP-phone
goes through the following conceptual stages:

1) User enters a (potentially partial) number on his phone.
   The phone appends its default domain and sends the invite to its proxy:
   e.g. 	sip:[email-masked]

2) The SIP proxy applies the local dialplan to translate the 
   SIP address to an E.164 number:

   e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416
   -> We now have a URN: tel:+4315056416

3) The SIP proxy now tries to route the call. In this example,
   user ENUM finds:
   "E2U+sip" "!^.*$!sip:[email-masked]!"

   or it could map to the local PSTN gateway with an URI like
   sip:[email-masked]

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 18 Aug 2005 09:35:48 -0400

In step 1, if the phone does not do dialplan interpretation, then what the
user entered is a dialstring, and not a telephone number.  This could be
encoded, as you show, as a SIP uri, but might be better encoded as a
dialstring, per draft-rosen-iptel-dialstring-02.txt.  A tel uri is
explicitly NOT used to carry a dialstring.

I think it would be better labeled as a dialstring, and not something that
could be confused as a telephone number.  It remains true that the user-part
of sip:[email-masked] can only be interpreted by the
my-voip-provider.at domain, so your flow definitely can work.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Otmar Lendl
Sent: Thursday, August 18, 2005 6:33 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
commonpolicy

/ol

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Aug 2005 11:12:42 -0400

I agree. There is a two step process, fundamentally:

dial string ----> name -----> address

The translation steps themselves can be done entirely in the UA, 
entirely in a proxy, or split. When one step is done in a UA, and the 
other in a proxy, there is a need to convey the dial string, the name, 
or the address on the wire (proxy to proxy is the same). The formats 
here are:

1. dial strings would be represented using Brian's dial string draft, i.e.:

    sip:<dial-string>@domain;user=dialstring

2. names are represented as tel URI, and is obtained by applying the 
dial string to the dial plan.

3. addresses are represented as a SIP URI with user=phone, and is 
obtained by performing enum, or through any other suitable translation 
service that can convert a name to an address. For example, a provider's 
databases may definitively say that a particular name is its own, and 
thus it can convert tel:number to sip:[email-masked];user=phone

In many cases, once a tel URI/name is determined, a provider can't 
obtain a sip URI for it. All it knows is that the number lives on the 
PSTN. In that case, it needs to go to a PSTN gateway. How to do this? I 
would argue further that the PSTN gateway represents a ROUTE to get to 
somewhere (the pstn) that can resolve the name to an address and route 
it there (all within the PSTN). In SIP, the way we do routing is via 
loose routes. So, to send a call to a pstn gateway:

INVITE tel:+1973952500 SIP/2.0
Route: sip:<whatever-you-want>@gateway.provider.com

The URI in the route header could contain a phone number in the user 
part, but the resource being identified for the route is not the phone 
number itself, but a piece of routing and gateway logic, and thus it 
makes no sense to have user=phone there.

BTW, I had mentioned in the enum session while at the mic that I was 
working on a doc that talked about phone numbers in SIP and the 
difference between tel and sip URI; that doc basically says the above.

-Jonathan R.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 21 Aug 2005 11:56:38 -0500

Folks,

I have followed the discussions on dial plans for a while, and it has been
going on actually for several years. Since the dial plan topic is so complex
even for the experts in the IETF, how can anyone hope that developers or
even more, users will get it right?

KISS and use only one of the three:

1. E.164 numbers for the Internet challenged,
2. SIP URIs for everyone else, or the best of all
3. Hide any type of CA in the AO and use Presence. Just click to call.

Thanks, Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Thursday, August 18, 2005 5:33 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 22 Aug 2005 10:18:35 -0400

Henry

You've been around enough to know that what you said is not the issue.
Dialplans, and dialstrings, arise because you don't generally know how long
a dialstring is, and phones don't know how to render a dialstring into a
telephone number or service indication.  Either you allow dialstrings in
which case some entity, the phone or a proxy, interprets digits according to
a dial plan to know when the terminal digit has been entered, adding
appropriate prefixes, or you use the wireless mechanism of not having "dial
tone", entering digits, and having a key press that indicates end of dialed
number and forcing the user to put in all the prefixes, or some combination.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Sunday, August 21, 2005 12:57 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
commonpolicy

Folks,

Thanks, Henry