inbound sip server failover

[Anonymous]

Just a question, willl be glad to post configuration or any other detail if required.

I am trying to test inbound redundancy from a provider standpoint to a 3430 running R10.5.3 code for SIP purposes. On the voice trunk facing the provider I have a primary SIP server as one SBC and a secondary SIP server of the other SBC. For calls to the 3430 I am trying to test redundancy to the secondary sip server. These are open SIP trunk so there is no registration that I could block or something along those lines. I first simply tried to change the IP of the primary SIP server but the 3430 returns a "404 not found" to the provider and the provider side cannot be changed to try the next route on a 404.

Basically, can internally set SIP cause codes be mapped to send something different back to the provider side i.e. map a 404 to a 503 to cause the provider to try the next route?

[Anonymous · Accepted solution]

:

Thank you for asking this question in the support community.  I'm not sure I follow what is happening during your testing.  Is the following correct:  You have a single SIP trunk configured to the provider, with a primary and secondary SIP server configured on that SIP trunk.  When you reverse the primary and secondary IP address configurations in the ADTRAN, the ADTRAN responds with a "404?  I think a debug and configuration would be beneficial, as that sounds more like the IP address or DNIS may be incorrect.

The Configuring SIP Trunk Failover in AOS guide provides good examples of this application and troubleshooting.  However, if you have additional questions or information, I will be happy to assist you with troubleshooting.

Levi

[Anonymous]

Thanks for the info Levi. What I actually first attempted was just changing the IP address of the primary sip server to lets say 1.1.1.1. I then placed an inbound call from the telco. The 3430 returned a 404 message to that and the telco did not try to reroute the call. I was just easily trying to replicate telco not being able to reach the 3430 primary server and the second call would be sent from the backup server.

What I did to test this scenario was just apply an acl to block traffic from the primary server and with no response the telco failed over so there was no need to try to change the cause code supplied.