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

["Michael Hammer \(mhammer\)" <mhammer at cisco.com>]

Not sure why Outlook is omitting carriage returns:

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?

Mike



> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Michael Hammer (mhammer)
> Sent: Thursday, August 18, 2005 12:33 PM
> To: James Polk (jmpolk); Stastny Richard; Jonathan Rosenberg 
> (jdrosen); Paul Kyzivat (pkyzivat); voipeer at lists.uoregon.edu
> Cc: geopriv at ietf.org; enum at ietf.org
> Subject: RE: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in 
> common policy
> 
> 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.
> 
> 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?
> 
> Mike
> 
> 
> > -----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
> 

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