[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Michael Hammer (mhammer) wrote: 
James,

This seems to be a number portability question.  E.164 numbers get
assigned by the national authority either directly to the individual or
to a carrier.

In the individual case, when the number ports from one SIP address to
another, it remains "owned" by the individual.

In the carrier case (at least in the US as I understand it), the number
is assigned to what is known as the donor switch/network/carrier.  This
is typically the network that "owned" the number before number
portability was invented.  When a user ports to a new serving
switch/network/carrier, the NP database maps the number to a location
routing number (LRN).  Carrier ENUM does essentially the same thing, it
records the current E.164 to SIP URI of Serving Carrier point of
interconnect.

If the user ports again, the donor network remains the same, while the
serving network in ENUM will change.

I thought I saw a note that the ENUM WG accepted a work item to do exactly this, which would imply that it isn't yet being done this way. If its not, then I would assume that the carrier enum would simply point to the donor network.

If the user relinquishes the number (cancels service), the number
reverts back to the donor network to be assigned to their next new
customer.  (Not sure if this is same worldwide.)

If one carrier buys another carrier, then the numbers owned by the
acquired carrier will now belong to the buying carrier.

So:

Donor 1 = ENUM leaf  (original carrier moves customer to ENUM)
Donor 1 -> Serving 2 = ENUM leaf  (first port)
Donor 1 -> Serving 3 = ENUM leaf  (second port)
Donor 1 -> Serving 4 = ENUM leaf  (third port)
Donor 5 -> Serving 4 = ENUM leaf  (carrier 5 buys carrier 1)
Donor 5 = ENUM leaf  (customer cancels)

Does that make sense?

Modulo the above comments. But I don't think this really has a whole lot to do with the original question. This comes down to whether you believe that

	sip:+1-232-555-1234 at foo.com;user=phone

is only valid if foo.com is the serving network/carrier for +1-232-555-1234. There are a whole lot of people who don't think that.

In my mind all that you can conclude from such a URI is that foo.com is to participate in routing calls to that URI. Whether they terminate in foo.com's network, or are eventually terminated someplace else is for foo.com to decide.

	Paul


-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of James Polk (jmpolk)
Sent: Wednesday, August 17, 2005 12:46 PM
To: Stastny Richard; Jonathan Rosenberg (jdrosen); Paul Kyzivat (pkyzivat); voipeer at lists.uoregon.edu
Cc: geopriv at ietf.org; enum at ietf.org
Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy

At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote:

I fully agree that there seems to be an issue here, because

the problem

is currently discussed at voipeer also.The format sip:+1-232-555-1234 at foo.com;user=phone
gets very important especially for Carrier ENUM indicating the destination providers (see below)

So, and perhaps this is a naive point/question - what happens when a carrier no longer operates a phone number that is in operation by another carrier?

For example, my wife has had the same cell phone number for 15+ years, yet she has recently changed to her third carrier. The company that originally owned her phone number is being acquired by a 4th company now (here in the US, giving you a hint as to two of the players involved).

What does this do to your statement:

"The format sip:+1-232-555-1234 at foo.com;user=phone
gets very important especially for Carrier ENUM indicating the destination providers"


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



cheers,
James

                                *******************
                Truth is not to be argued... it is to be presented.

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum




_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum