From: Barry Bishop

To: Darin Liston

Subject: Re: Number Pooling Preporting

Darin, it seems that this may be the issue of the week, but at this point I am not sure I agree with your assessment (or others) on this situation. "I think" part of the problem is terminology, and is dependant upon the action of the receiving service provider. Basically is the receiving service provider leaving the block of numbers as unallocated in their switch? If so I agree you would return a cause code 26. If the receiving service provider opens the block of numbers in their switch (allocated but unassigned), you should get normal intercept treatment and not return cause code 26. In my mind this is no different than porting 1 number who may be disconnected and have intercept provided by the receiving service provider. One or one thousand, it should be the same or in my eyes we have major problems with LNP in general.

The receiving service provider needs to allocate the numbers in their switch, providing intercept treatment to any unassigned numbers.

Maybe I don't fully understand the issue, but we do need to discuss it to make sure we are moving in the right direction. I will forward your memo to the rest of the team so we can discuss it.

Thanks

Barry

• • -----Original Message-----
    • • • From: Darin.Liston.EandO@igate.sprint.com [SMTP:Darin.Liston.EandO@igate.sprint.com]

          Sent: Wednesday, July 23, 1997 1:43 PM

          To: barry.bishop@ported.com

          Subject: Re: Number Pooling - Preporting - Issue with Cause Code 26

    << File: number~2.ppt >> Barry, I have run across another potential problem with pre-porting numbers.

    In a pre-porting scenario, if a call is made to a pre-ported number that has not been assigned to a customer, the call (theoretically) should be routed to a vacant recording which will tell the customer that the number is not in service. However, since the number has already been dipped, when the switch see’s that the number is vacant it will produce a Cause Code 26 recording, which will tell the customer that the number is not currently in service and to please call again later. This will be misleading. So, for every block that is ported, each number will have to be routed to a message, instead of doing default routing. When the number is assigned, the routing will be changed via a service order. However, when the number is disconnected, and it snaps back to the block owner, the message routing will have to be re-established. This is a process issue, and a tracking item.

    This is not a problem with porting-on-demand.

    I have attached a quick Power Point Document that tries to draw a picture of this scenario. I don’t know if this is a show stopper or not, but wanted to get it out to everyone so that they could review it prior to our conference call next week.