Closed Bug 917073 Opened 11 years ago Closed 11 years ago

Port Telepacific DID's to Level3

Categories

(Infrastructure & Operations :: Telecom, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ahill, Assigned: justdave)

Details

We currently have 4 DID's being delivered to Mountain View via Telepacific.  Per Bug 797220, we'd like to port those numbers over to our new Level3 SIP trunk.  This will provide better service and consolidate our carriers.

Services impacted:
DID phone numbers 650-963-8461,650-903-0800,650-963-8807,650-963-8809

Risk: 
These are our main company DID's and they receive a lot of traffic.  They would be temporarily out of service if they are not ported correctly.

Risk Mitigation:
There isn't much we can do since all the work happens on the carrier side.  On our side, this is an existing configuration being carried over to the new trunk.  We will conduct this maintenance after hours to minimize any potential impact.

Steps involved:
1. Give permission to Telepacific to release these numbers to Level3.
2. Ask Level3 to port these numbers to our SIP trunk

Requested date/time:
Since there are multiple telecoms involved, we need to give plenty of padding to get the paperwork done.  I'm requested we complete this change on 1 Oct 13 at 9pm Pacific.
Flags: cab-review?
Aaron on point to get both carriers on the phone and agree to switch without any loss of service. Once this is done, we can proceed with the window.
Assignee: server-ops → ahill
(In reply to Shyam Mani [:fox2mike] from comment #1)
> Aaron on point to get both carriers on the phone and agree to switch without
> any loss of service. Once this is done, we can proceed with the window.

Telepacific has outright stated they will not cooperate on agreeing on when to switch.  It'll happen when it happens.

The risk of downtime is low, regardless.  Since Level 3's drop is actually in place now, we're not in danger of having nowhere to deliver the calls.  We simply need to make sure we know what Level 3 plans to send for the DID codes to make sure the programming is in place on our end for it (If they send straight 10-digit numbers like Telepacific is doing now, there'll be no programming changes needed on our end, but if they send it with the 1 in front, for example, we'll need to add new programming).
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #2)

> Telepacific has outright stated they will not cooperate on agreeing on when
> to switch.  It'll happen when it happens.

Very nice of them.
 
> The risk of downtime is low, regardless.  Since Level 3's drop is actually
> in place now, we're not in danger of having nowhere to deliver the calls. 

Okay.

> We simply need to make sure we know what Level 3 plans to send for the DID
> codes to make sure the programming is in place on our end for it (If they
> send straight 10-digit numbers like Telepacific is doing now, there'll be no
> programming changes needed on our end, but if they send it with the 1 in
> front, for example, we'll need to add new programming).

What's the contingency plan for this? (say they make a switch and we have a 1 in front, who's going to catch it and if we don't, what happens?)
(In reply to Shyam Mani [:fox2mike] from comment #3)
> (In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #2)
> > We simply need to make sure we know what Level 3 plans to send for the DID
> > codes to make sure the programming is in place on our end for it (If they
> > send straight 10-digit numbers like Telepacific is doing now, there'll be no
> > programming changes needed on our end, but if they send it with the 1 in
> > front, for example, we'll need to add new programming).
> 
> What's the contingency plan for this? (say they make a switch and we have a
> 1 in front, who's going to catch it and if we don't, what happens?)

We already know the style they are using on the trunk since we have other DID's and have made test calls (they are not sending a 1 in front.)  Also, I'll generic make a backup-up route to catch anything with a 1 and forward it to the same DID without the 1.  

Albert sent in the disconnect notice to Telepacific with a contract end date of 24 Oct.  That will give Level3 the permission they need to take the numbesr.  We can still ask Level3 to make arrangements on their end to port the numbers at a specific time, and at Albert's suggestion I'd like to ask for Friday, Oct 11 at 8pm Pacific.
Approved by the CAB on Sept 25th to be done on Oct 11th. Aaron will make sure Level 3 is in the loop and feels they will be more helpful in this case than TP has been.
Flags: cab-review? → cab-review+
Assignee: ahill → adam
Sent Level 3 LOA doc to port these # as of 11-Oct port to them:
6509030800
6509030875
6509638461
65096388xx block

Conversely, I sent disconnect notice to Telepacific for 24-Oct.
(In reply to Albert from comment #6)
> Conversely, I sent disconnect notice to Telepacific for 24-Oct.

which was rejected because we stated intention to port to Level 3 in the same notice and they said we could do one or the other but not both (the port implies a disconnect when it happens)
 Dear Albert
I have submitted order # 1006LSKC  with a requested due date of 10/11/2013.  Your Customer Care Manager, Jean Witzel, will be following this order through to completion for you.  If you have any questions or need an update please contact Jean for assistance.  I have included  her on this email trail for your convenience.

Thank you,

Robin Davis
Customer Order Support  
Level (3) Communications
712 N. Main St.
Coudersport, PA 16915
p: 814-260-3006
e: robin.davis@level3.com
Confirmed for 6AM PDT Fri 11-Oct. JustDave is technical contact for Level 3.
Assignee: adam → justdave
Component: Server Operations: Change Requests → Server Operations: Telecom
Flags: cab-review+
OS: Windows 7 → All
QA Contact: shyam → adam
Hardware: x86_64 → All
This was completed during this morning's maint window.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.