Bandwidth.com SIP Trunks - 911 Failover [Solved]

[Tech Electronics]

Mitel "Bandwidth" Gurus,

I am trying to setup Bandwidth as the SIP Trunk Carrier and they are requiring a 911 Test that requires the MCD to Failover to the secondary 911 route when they send a 4xx, 5xx or 6xx response to an Emergency Call.

Here is what they are requiring us to do for the Failover Testing.

Simulated failover testing
This test will validate your system’s ability to successfully redirect failed calls to your secondary route.

During this test we'll simulate a scenario in which your 911 call is sent to your primary route and will then fail with a SIP 410 response. When you receive a 410 response, you should send the SIP INVITE to the opposite data center.

To complete testing, simply make a call from the following ANIs:

If ATL is the primary, 15555558888
If DFW is the primary, 15555559999
Once you’re setup to do these things, you’re ready to migrate traffic. Please notify us if you require any assistance with the migration of services. 

Note: If the 933 call isn't successful, please halt testing and open a ticket with your Bandwidth Support Team.

We have two SIP Peer Profiles for 911 that go to two different geographical locations [IPs] that Bandwidth supports. Their on-boarding team is requesting the previous testing to be completed, but I don't see a way to make that happen in the MCD. We do have an MBG setup and I am looking into whether or not we can Identify 4xx, 5xx, 6xx responses and redirect using the SIP Adaption feature, but so far I haven't successfully got that to work either.

I performed a search on the forums and seen that people have used Bandwidth Trunking before so hopefully someone can explain how they approached this scenario.

Thanks,

TE

[sunspark]

Ars digits dialed : 911 followed by 0 digits

Create 2 route

Emergency Route 4 - - > primary sip peer profile
Emergency Route 5 - - > secondary sip peer profile

Create route list 3 for example and put in route 4 and 5

[Tech Electronics]

Sunspark,

Alright, I guess I didn't really explain my ARS so here is what I have.

I already have SIP Peer Profile 911A programmed on the Primary Controller and SIP Peer Profile 911B programmed on the Failover Controller.

Digit Modification 1 is left default
Digit Modification 2 is set to remove the first 1 digit; in this case 9 from the dialed digits.

ARS Route 1 is programmed for Emergency Calling on both Controllers using Digit Mod 2
ARS Route 51 is programmed for Emergency Calling as a Direct Route to the other Controller using Digit Mod 1

Route List 1 is programmed as Route 1 and then Route 51 on both Controllers

Dialed Digits 9911 and 9933 both go to Route List 1

Secondary Dial Tone is provided on Dial 9

System Speed Call 911 and 933 have an actual of 9911 and 9933

I have tested that if I Change the Network Element 911A from Auto-Detect/Normal to Disabled that the 911 call will go to the Failover Controller to the SIP Peer Profile 911B and the Emergency Hunt Group will get the Alert on both Controllers.

Now that the basics are out of the way the problem I am running into is the following.

The Primary and Failover Controllers both see the path as available in the Auto-Detect/Normal operation as the trunks are responding to the Options Ping [Keep-Alive]. So, when the 933 call goes out for testing it will select the Primary Controller and try to go out SIP Peer Profile 911A; because it is up.

We get a response of 410 [Gone] - The user existed once, but is not available here any more.

The System doesn't know to move over to the secondary path as it received a valid response from the Bandwidth.

Hopefully that clears up any misunderstanding as to what my problem is.

Thanks,

TE

[sunspark]

ok i see, in this case the active - passive mode must be managed by your carrier not your controller

[Tech Electronics]

Sunspark,

Are you referring to setting the Network Element from Auto-Detect/Normal to Always Active?

Thanks,

TE

[sunspark]

1st,  I don't understand why you created 2 speed calls

911 -> 9911
933 -> 9933

question 1: is the user dialing 911 instead of 9911 in some case ?

-----------------------------

now I have another question: why in route 51 you absorb the 1st digit (9)

normally if your IPxnet or your direct route is correctly configured, you are not supposed to do any absorb for the second route.

To make it simpler, create an extension on the second controller and dial 9911 to see if it already works.


then this is what I usually do:


9911 -> Route 1 (emergency): 1st controller - Sip peer profile 1
               Route 2 (emergency): 2nd controller - Sip peer profile 2 (same ars digits modification)

Route list 3: (route 1 + route 2)

that it

[Tech Electronics]

Sunspark,

Question 1: Yes, most users will just dial 911, but the law here is that we have to allow 911 instead of 9911 due to the Kari Law.

Question 2: Route 51 doesn't Absorb the 9 as Digit Modification 1 is default which doesn't do anything. Only Digit Modification 2 removes the first digit (9).

I already have tested that the SIP Peer 911B does work on the Failover Controller.

The scenario you are referring to is what I explained previously and it does work as expected; just not for a SIP Cause Code of 410.

Thanks,

TE

[sunspark]

why you don't ask your carrier to shutdown the first link ( sip peer profile 1 )

then you call  991 to see if the system use the 2nd path

[Tech Electronics]

Sunspark,

I am not sure what more I could explain to you about this.

When I make an Emergency Test Call (933) from any phone on the system using the CPN Substitution [5555558888] which forces Bandwidth to send a SIP Cause Code of 410 [Gone] - The user existed once, but is not available here any more.

What Bandwidth wants the MCD to do is see the 410 SIP Message and then move over to send out the INVITE to the Failover Route 911B instead of sending a Busy Message to the user.

Are you wanting to see a SIP Packet Capture?

Thanks,

TE

[sunspark]

yes please

[sunspark]

you have configured your sip trunk by following the sip COE of your carrier?

[NEPhoneGuy]

Looks like the Bandwidth config document is outdated and certainly doesn't cover this or I'd imagine you wouldn't be asking here.

I'd imagine this would have to be customer SIP adaptation configuration on the MBG because I don't know of anything/anywhere out of box that you can send a new invite to a different endpoint when receiving an error (in this case the 410 or any other response code) Is Mitel offering any assistance on this?

[Tech Electronics]

Guys,

As with most of the documents I have tried to use in the past the SIP CoE document for Bandwidth is outdated and inaccurate to say the least, but yes I did start with that.

I have reached out to Mitel Tech Support, but so far they haven't come up with an answer on Tier 1 or 2 and I am awaiting T3's response now.

I just thought there were other technicians that have run into this issue with Bandwidth since they seem to be a T1 Carrier.

I have thought about SIP Adaption, but I haven't figured out how I would go about writing that one.

Thanks,

TE

[sunspark]

Sip adaptation in the MBG only .

[Tech Electronics]

Guys,

We ended up using a TelcoBridges ProSBC for this as Mitel has no way to make this happen natively.

We put the ProSBC in the Cloud and then point our MCD to that via an MBG, because we have an MiVCR doing SIP Trunk recording, and then let the ProSBC determine the routing based on call-type.

The ProSBC will see the 410-Gone as an Invalid response and then recursively sends it to the second option.

If anyone has to do this make sure to turn off Use Session Timers as that will cause some troubles with calls dropping and it isn't needed for this solution as you just want calls to pass through it once they are setup.

ProSBC Webportal -> SIP -> Sessions Timers -> uncheck “Use session timer” , save and activate the configuration.

Thanks,

TE