Subject: [Sipping] RE: [Iptel] New I-D on usage of phone numbers in SIP [DO NOT REPLY!]

From: "Yu, James" <[email-masked]>
Date: Thu, 19 Oct 2006 11:24:57 -0400

Jonathan,

A few points for discussion:

- E.164 numbers are globally unique so they are the best "names" that
identify the users.   Any sip URI with a service provider's domain name
in the host part won't be portable when the user changes the service
provider.   So storing the "tel" URIs in the contact list/address book
is better than storing the "sip" URIs when the phone numbers are in the
countries that support number portability.    Also, the "tel" URI in the
>From header is more "friendly" than the "sip" URI when the called party
is in the PSTN.

- In page 5 you said

  "However, this is secondary to its more important meaning - it is an

   identifier for the owner of the namespace from which the user part is
   selected."

  The statement is true when the owner of the namespace receives such an
incoming SIP request.  But during the routing of the SIP request, it is
possible that a non-owner's namespace appears in the domain part of the
"sip" URI that contains the phone number in the user part.   For
example, in some networks, certain servers may be designated to do ENUM
and/or NP queries.   In some implementations, the SIP request would be
routed (direct IP routing to that server's IP address) to one such
server while keeping the "tel" URI in the R-URI unchanged.   In other
implementations, the "tel" URI is converted to a "sip" URI where one
such server's domain name appears in the "sip" URI that contains the
phone number in the user part.  The server that receives such a SIP
request will then act upon the phone number retrieved from the "tel" URI
or the user part of the "sip" URI.   But eventually, yes, the domain
name in the "sip" URI would be the owner of the namespace from which the
user part is selected.

- You proposed to use the Route header to carry the "routing" number.
I do see a problem.   In your freephone example, a POTS/phone number
would be mapped from the freephone number and could be put in the Route
header in the "tel" URI (if no domain information is available) without
retrieving the "routing" number (if it is ported) first.   This means
that the Route header could carry either the phone number or "routing"
number.  There must be a way to differentiate them if both types are
allowed.   One way is to enforce that the Route header can only carry
the "routing" number in the "tel" URI.   In the freephone example, the
translated-to phone number would appear in the R-URI after the freephone
DB lookup (the originally dialed freephone number is in the To header).
Then another NP lookup by this node or another node can add the Route
header that contains the "routing number" in the "tel" URI.

James

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 5:43 PM
To: IETF SIP List; IETF Sipping List; [email-masked]; list iptel
Subject: [Iptel] New I-D on usage of phone numbers in SIP [DO NOT
REPLY!]

PLEASE DO NOT REPLY TO THIS POST.

My apologies for the cross post. I have submitted the following I-D:
http://www.ietf.org/internet-drafts/draft-rosenberg-rai-phone-names-numb
ers-00.txt

I gave it a -rai moniker since it touches on issues central to at least 
four working groups. If you are interested in discussion this document, 
please let us do so only on [email-masked].

The document proposes a framework and architecture for the usage of 
phone numbers with SIP. It tries to answer questions like the difference

between a tel URI and SIP URI with user=phone, when to use each, what 
the meaning of concepts like LNP and freephone are in a pure-SIP world, 
the architectural role of ENUM, and impacts on PSTN interoperability, 
and so on.

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

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.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: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Oct 2006 11:50:19 -0400

>>From header is more "friendly" than the "sip" URI when the called party

I'm not sure I want to engage in a number vs. URL debate here (or that 
the draft is the appropriate place for that). I'll only note that you 
assume carrier-provided URLs. In the future, one might imagine corporate 
and/or personal names. I can get a domain name for my whole family for 
$9/year or so, and I can port it to whoever I like. Maybe eventually 
godaddy will offer SIP redirection services, just like HTTP redirection...

I suspect that the answer is "both", i.e., for PSTN users, a number (or, 
more likely, a name) is a better choice. For the rest, names are far 
more descriptive. After all, there is a reason you are not using

[email-masked]

as your email address.

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 19 Oct 2006 19:21:13 +0300

Yu, James writes:

 > identify the users.   

anybody can register a domain, which makes sip:user@domain globally
unique, portable identity.

 > Any sip URI with a service provider's domain name
 > provider.   

false, see above.

 > So storing the "tel" URIs in the contact list/address book
 > countries that support number portability.

there are lots of problems using phone numbers as sip identities.  

in finland, for example, government does not allow me to use my cell
phone number in my office sip phone.  it can only be used in mobile sip
phones and only if all calls out to pstn from that sip phone go through
the mobile operator in whose network that number is currently
registered.

i could buy a personal phone number, but finnish government protects the
revenues of mobile operators by not allowing me to use that number in my
mobile phone.  further, government in finland protects phone companies
by not allowing me to register my phone number in enum unless the phone
company in whose network the number is currently registered agrees to
that (which is NOT the case with my current mobile operator).

also, if you move to another country for a year and want to save money
by discontinuing your phone service you will also loose your phone
number.

for these and many other reasons, it is very bad idea to use phone
numbers for any kind of identities.  the sooner we can migrate to normal
sip uris, the better.

 > From header is more "friendly" than the "sip" URI when the called party

this i agree, because if you put a domain there, there is no guarantee
that the callee can reply to the call using the same service provider's
pstn gateway than where the call came from.

-- juha

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Oct 2006 19:49:14 +0200

First I want to thank you for drafting this important memo.
IMO it is really useful and necessary to have such a document.

Some initial thoughts and comments:

1. Introduction
3rd para: RFC4248 is the telnet URI, I think you mean RFC 3966.
last para: Section 6 should also discuss non-E.164 (local) numbers
in general (including short codes), including location
indepenent and location dependent numbers and also
private numbers.
 
2. Names, Numbers and Routes
 
Numbered list:
 
You are speaking only about global numbers, you should
also include here SIP URIs containing dialstrings and
also tel: and sip: URIs containing local numbers.
 
Question: where are the user=... defined, what means
user=IP, who to treat user=IP and no user parameter,
and are there others. The text starting with 
Lack of the user=phone ... is a bit unclear
 
Thanx for clarifying at least the user=phone
 
3.1 dial string processing
 
thanx for the clarification

what is missing is a description of processing 
of non-E.164 (local) numbers
see the examples used in the next section
e.g. Tel:5000;phone-context=example.com
 
3.2 Identity Processing
 
Also no solution ;-)
 
3.3 Name to Address Translation
 
I do not fully understand why you need a new URI scheme here?
IMO the parameters defined in [15] should be sufficient,
or you let the PSTN do the work
 
>1.  The proxy has accessed a translation service, such as ENUM, which
>       has successfully produces an address (in the form of a SIP URI)
>       for that number.
 
ENUM may also produce Tel: URIs
 
I do not fully understand the last example with the ported
number, anyway this example belongs to Section 4.:
 
>INVITE tel:+19735551000  SIP/2.0
>   To: tel:+19735551000 
>   From: sip:[email-masked]
>   Route: tel:+19735559999 
 
could it be also
 
INVITE tel:+19735551000;rn=+19735551000  SIP/2.0
   To: tel:+19735551000 
   From: sip:[email-masked]
   Route: tel:+19735559999 
 
3.4 Route Determination
 
I do not understand you OPEN ISSUE, how will you
specify hops on the PSTN with non-SIP URIs?
>It is never necessary for the route to a PSTN gateway to contain the
>   desired number in the user part; this number will always be present
>   in either the next Route header field, or if there is none, the
>   Request URI.
 
No you lost me completely
 
4. Ported Numbers
 
Ok now here we have the explanation for the
question above in the OPEN ISSUE
 
Since you cannot change the format of the NAPTRs, you
may only change how the result is used.
 
5. Freephone numbers
 
>Freephone numbers in
>the U.S. are national numbers, only accessible from 
>within the U.S..
>Freephone numbers are also not considered part of the E.164 
>numbering plan
 
This is not true. Freephone numbers are E.164 numbers, they
may be accessible from other countries (depending on
agreements)

But - they may be location dependent
 
I agree that urn:servicefreephone option is a valid solution 
(also for other service numbers e.g. +900 numbers) and I
support you that we need to conclude on this. This may
also solve the location dependance
 
The CIC URN needs to be discussed and lacks internationality
There is no SPIDs defined internationally
 
6 Short codes
As already said, this section needs substantial work and
needs to be expanded
 
7. Carrier Selection
Do we really want to go down this path?
 
regards
Richard

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 12:04:03 +0200

> unique, portable identity.

as long anybody uses a different domain.
>  > in the host part won't be portable when the user changes the service

Why false? It is true. E.g. a@vsp1, b@vsp2. a can't port this URI to 
another service provider. Thus, every user needs a dedicated domain, 
e.g. a@a and b@b.

regards
klaus

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 20 Oct 2006 13:07:36 +0300

> another service provider. Thus, every user needs a dedicated domain, 

it was 'false' assuming what i suggested, i.e., get your own domain.

-- juha

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 12:13:50 +0200

> and/or personal names. I can get a domain name for my whole family for 

Thuse, the whole family has to change its service provider - it can't be 
done on a "per family member" basis.

regards
klaus

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 12:18:09 +0200

> Also no solution ;-)

One solution for signing From: headers with tel: URIs:
Signing with domainkeys and publishing the public key in the ENUM domain

regards
klaus

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 20 Oct 2006 13:00:06 +0200

> more descriptive. After all, there is a reason you are not using

I agree with the points raised here and want to expand them a bit:

IMHO we have two different types of SIP URIs in use today:

a) the provider-supplied one, e.g. sip:[email-masked] is
   one I got from a SIP provider here in Austria. (I think you can
   guess what the associated E.164 number is :-).

b) a user-supplied one. If I ever get around to configure the
   Asterisk on my private server, then sip:[email-masked]
   will work and forward to call to wherever it want to.
   (Regrettably, right now I don't know any commercial SIP services which
   is willing to host your sip domain. After all, that's very common
   for email and the web.)

What are the applications for these two types or URIs?

* In User-ENUM, I'd use b).

* In Infrastructure ENUM, fairytel as the current telco serving
  +43720345XXX will use a).

* On my business card, I'd either print tel:+43720345XXX or
  sip:[email-masked], but definitely not a).

* If I change service provider, then a) will change, b) won't.

* If I change my name, b) might change but a) not.

To come back to the Name / Address / Route definitions that Jonathan
uses in his draft: 

a) is definitely an Address.

I am not so sure about b): To me it looks like is has properties of a
Name than that of an Address.

To summarize: The classification of SIP URIs as "Addresses" is too simple.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Oct 2006 08:29:09 -0400

On Oct 20, 2006, at 6:13 AM, Klaus Darilion wrote:

>> I'm not sure I want to engage in a number vs. URL debate here (or  
>> that the draft is the appropriate place for that). I'll only note  
>> that you assume carrier-provided URLs. In the future, one might  
>> imagine corporate and/or personal names. I can get a domain name  
>> for my whole family for
>
> Thuse, the whole family has to change its service provider - it  
> can't be done on a "per family member" basis.

Depends on how you define "service provider". One can easily have a  
two-level system, where the proxy for darilion.org only proxies calls  
to the per-person service provider of choice and provides no further  
services. As long as everyone can agree on this minimal level of  
service provider, which isn't fundamentally different from a DNS  
provider, everyone in the family can choose whatever real service  
provider they like.

Henning