SIP Trunk ARS

[Johnniehec]

Hi,
We have two Ribbon SBCs to provide connection to MS Teams Direct Routing. In the ARS we have two Routes in a Route List to provide resilient routing. This morning due to VM issues the 1st choice SIP Trunk was out of service when I checked SIP LINK STATE ALL but calls were returning busy tone rather than following the 2nd choice route. I swapped 1st and 2nd Routes round in the Route List and calls were routed to the secondary SBC correctly so I know the 2nd Route works. Does anyone know why the calls returned busy tone rather than following the second choice Route?

Thank you,
John.

 

[nytalkin]

Are you sure it returned BUSY and not REORDER? What SW Release and platform are you using?

I suppose you're entitled to your opinion, I'm just not going to suppose very hard.

 

[Johnniehec]

Hi nytalkin,
Yes definitely busy, 6920IP display showed "3399 is busy" vMCD Release level: 8.0 SP3 PR3
Thank you,
John.

 

[Johnniehec]

When I typed the answer to your question I had a flash of inspiration, we're using Speed Dials to route four digit extension/DDI numbers to the SBCs and the "Overrides Toll Control" was left default No. I changed 3399 to Yes but unfortunately it's still returning Busy tone.
Thank you,
John.

 

[dfarzad]

Hi,
I made all the settings according to the document for SIP trunk.
But the connection is not established.

My scenario is like this :


PSTN(SIP Trunk) <----------> MBG(SIP Trunk)<----------> MiVB(SIP Trunk)<-----> Extensions

Please guide me or tell me step by step if you can.
Thanks,

 

[Devolution]

Running a packet trace on the SIP MBG whilst the primary SIP is out of service will most likely hold the answer.

Make sure in the route list, you haven't got the option to inject a tone if a route other than the 1st choice is not available. This has caused odd issues like this in the past for me.

 

[Valamagules]

I have seen that sometimes if the peer is still reachable, even if the trunk is OOS, the calls will still try to route out the SIP trunk if the peer is responding to keepalive options.
I suppose the logic of failure is if the peering party is no longer reachable, no more events are received from the peer. This indicates a total failure in the SIP trunk service, the controller will then opt for the 2nd route in the list.

You can simulate this by disabling the connection or interface from the upstream peer to the Mitel.






Clever men learns what Wise men shares!

 

[Johnniehec]

Valamagules,
You are correct, our maintainer came back with a couple of options all of which were already correctly set but the final fix was
Cause
The failure of the call to use another route is caused by the "Invite Ringing Response Timer" not being configured.

Resolution
To enable this behaviour to function the initial SIP Peer (and all others in the list) must have the "Invite Ringing Response Timer" configured to a value other than 0 (Default and Disabled). The behaviour is design intent as stated in the online help "Enabling this timer allows calls to be rerouted at the time of network failures instead of waiting for the link to be considered totally out of service."
I changed this timer to 8 seconds and calls now follow second choice route if SIP trunk is out of service or set to ManBusy. Also when setting SIP trunk to ManBusy now takes the SIP trunk out of service as the Ribbon SBC end which it didn't before.

Thank you,
John.