Shutdown/Alarm PRI on SIP Trunk Failure

[Anonymous]

A new customer of ours is looking to us to provide them a SIP trunk on their TA924.  They currently have a SIP trunk provided to them by another carrier which they terminate into the 924 and then hand off a PRI to their PBX.  We will be doing the same thing for them, but they have a current issue that they are hoping we can resolve.

Currently, when the SIP trunk goes down, they have to physically remove the cable from the 924 going to the PBX so the PBX will failover to its other methods of sending calls.  They are looking for us to come up with a solution that will failover automatically.  Is there a way to disable the PRI interface or put it into alarm status when the SIP trunk goes down?

[jayh · Accepted solution]

This is going to be difficult, and the PBX should be capable of handling it without a specific action on your part.

Keep in mind that SIP is session-based.  The Internet connection can be up and happy, but until a call is placed and an INVITE sent, the TA900 has no way of knowing whether the call will go through.  The local circuit can be up but the SIP server out of order, for example.  This differs from a circuit-based PRI where the D-channel is constantly nailed up and a failure can be detected without placing a call.

However, when a call is placed that is unsuccessful, the TA900 should send an ISDN message back to the PBX identifying the failure such as cause 38 - Network out of order, etc.  The PBX should be capable of trying a secondary route when a call is rejected by the TA900.

It is possible to manipulate the way SIP failure messages relate to cause codes with the voice cause-code-map to-pri command, and you may need to do so in order for the PBX to try a secondary route.

You may need to experiment with the PBX and this command mapping in order for the PBX to do the right thing if the SIP call fails and not attempt a reroute if the number is simply busy for example.  Advise the customer that there is likely to be some post-dial delay in the case of SIP circuit failure.

[Anonymous]

This is outside the context of your question but maybe a viable alternate solution.  Instead of having the PBX route to different connection type use least cost routing and perform the failover directly on the Adtran.  You could setup two different SIP trunks with two different providers and if using a TA900e model each provider could even have it's own port using different ISP connections.  This type of setup will work for outbound redundancy.  Another option would be to terminate analog lines into the TA900 via FXO ports and in the event the SIP route is out you could then have it failover to the Analog ports on the Adtran.  In either scenario the Adtran itself is doing the failover and not the PBX.

John Wable

[Anonymous · Accepted solution]

Bchesler,

Thanks for posting!  There are some good responses on this post, but I thought I would give you another option.  The Busy-Out feature is explained in the document Configuring Busy-Out Monitoring in AOS.  Essentially, this allows you to use a probe to test for network connectivity.  In the event that pings fail upstream, you can take down the D channel on the PRI.  Below is a small sample configuration.

probe DROPTRUNK icmp-echo

  destination 192.168.1.1

  period 30

  timeout 300

  tolerance consecutive fail 3 pass 2

  no shutdown

!

track TESTTRACK

  test if probe drop-trunk

!

voice trunk T02 type isdn

  busy-out monitor track TESTTRACK

Hope this helps!

David

[jayh]

david wrote:

Bchesler,

Thanks for posting!  There are some good responses on this post, but I thought I would give you another option.  The Busy-Out feature is explained in the document Configuring Busy-Out Monitoring in AOS.  Essentially, this allows you to use a probe to test for network connectivity.  In the event that pings fail upstream, you can take down the D channel on the PRI.  Below is a small sample configuration.

probe DROPTRUNK icmp-echo

  destination 192.168.1.1

  period 30

  timeout 300

  tolerance consecutive fail 3 pass 2

  no shutdown

!

track TESTTRACK

  test if probe drop-trunk

!

voice trunk T02 type isdn

  busy-out monitor track TESTTRACK

Hope this helps!

David

Nice, but even better would be the ability to configure a SIP OPTIONS probe to the SIP server.  ICMP ping doesn't tell the whole story and may even be firewalled by the service provider.  Consider this an informal feature request. 

[Anonymous]

This should work.  I will get it tested to make sure.  I think a SIP OPTIONS would be nice as jayh stated as well.

[Anonymous]

I tested this configuration this morning and it worked perfectly.  Thanks for the help.

[curtc]

I agree.  ICMP would be good for testing the link to a host is up, but won't tell whether the SIP trunk is up or down.  I am in this same boat and found this post via Google search.  Anyone have an update on SIP OPTIONS or another way to test the trunk?  Thanks.