Sonus SBC1k/2k signalling group out of service when SIP OPTIONS fail

4
2300

As of  firmware version 4.1.2, Sonus SBC1000 and SBC2000 Session Border Controllers now support taking a Signalling Group out of service when SIP OPTIONS fail. Prior to this change the Signalling Groups SIP registration status was the only thing the SBC used to determine if the trunk was up or down. The issue with this is that only on re-registration the SBC will determine that there is a problem. Typically service providers do not like re-registrations to happen too often (in this part of the world 60 minutes is the norm), so this means there could be a considerable delay before a failed Signalling Group is taken out of service by the SBC.

To control this behavior we now have a new option in SIP Signalling Groups:

Sonus-Use-Register-As-Keep-Alive-Small

This option allows you enable or disable the use of the registration status to keep the Signalling Group alive.

Enabled = Use SIP Registration Status as keep alive for trunk

To mark the SIP Signalling Group down the following has to be true – Registration has to be failed (which will only happen after timeout and re-registration occurs) AND if SIP OPTIONS are enabled they also have to be failed. This the current default behavior.

Disabled = Ignore SIP Registration Status as keep alive for SIP Signalling Group

To mark SIP trunk down the following has to be true – SIP OPTIONS are enabled and have failed.

 

With this new setting set to disabled and with SIP OPTIONS enabled, the SIP Signalling Group will be taken out of service when SIP OPTIONS are no longer responding. When this occurs you will see the following events logged:

Sonus-Signalling-Group-Taken-Out-Of-Service

When the Signalling Group is taken out of service it will immediately respond with a 404 for all call requests. If you are expecting Skype for Business (Lync) to do any re-routing, you’ll need to re-write this to a 503 Service Unavailable. Skype for Business will treat the 404 as a final response and will not re-route otherwise. You can achieve this in the SBC using Message Manipulation or in Skype for Business using a Sip Response Code Translation Rule (New-CsSipResponseCodeTranslationRule).

 

4 COMMENTS

    • Hey dude! My testing definitely found a 404 – I questioned Sonus about this as it seemed odd to me at the time. I cant find a reply confirming if this is expected. This was May 2015 so possibly the behaviour has changed. Here is the summary I sent Sonus:

      We did some thorough testing with the customer last night, here’s what we found:
      1. Removing the internal network cable results in:
      a. Lync re-routing outbound immediately – expected as Lync is monitoring internal interface
      b. Inbound fails – I couldn’t trace this as I was not onsite, will organise this for later date if required. Suspect same issue in reverse – Telco is not informed that internal side is down and there is no route, so Telco does not re-route
      2. Powering off the SBC results in
      a. Lync re-routing outbound calls immediately – expected as Lync is monitoring internal interface
      b. Inbound calls re-routing immediately – expected as Telco gets no response from SBC
      3. Removing route to ITSP results in:
      a. Outbound – silence for about 20 seconds then a number not in service message in Lync – Lync sent 404 by SBC after 11 INVITES to ITSP receive no response. Why 404? If no response shouldn’t this be a 500 error?
      b. Inbound – Re-routes immediately
      4. Removing external cable results in:
      a. Outbound – Silence for about 20 seconds then a number not in service message in Lync – Lync sent 404 by SBC after 3 INVITES to ITSP receive no response. Why 404? If no response shouldn’t this be a 500 error? 404 is a final response.
      b. Inbound – Re-routes immediately

      Hope that helps and be interested to hear what you find.

      Andrew

LEAVE A REPLY