I’ve long been a fan of the “Easy Config Wizard” in Sonus’ SBC 1k, 2k and now SWe Lite devices. With very few exceptions, all of my SBCs are deployed from scratch using it.
If you’re not familiar with it, it presents you with a few basic questions and when you click Finish it sets up a mostly working SBC for you, with SIP Server tables, Signaling Groups & some basic transformation tables. Just add some certs (and credentials if your SIP carrier wants them) and you’re online between Lync or SfB & your carrier in no time:
Here’s the how-to on the Sonus support site – see for yourself.
Why not just clone an existing SBC with the “Import Partial Configuration” option? I like the idea of starting from fresh each time, using Sonus’ latest recommended configurations baked into the Wizard, rather than perpetuating any bad habits or out-of-date config that I might still have left in a legacy ‘source’ SBC. And of course by starting from scratch you don’t have to spend any time undoing any of the customer-specific or boutique bits you had in the backup you used. (I *do* however like importing my Transformation Tables and I love that feature, but that’s a story for another time).
“There can be only one”
The Easy Config Wizard has been set with the assumption that you only have the one SBC in your SfB environment. With only one SBC from which to choose SfB can’t afford to lose it, however if the SBC rejects too many outgoing call attempts in a short period of time, SfB will mark it as “down” or “less preferred” – potentially stopping *all* calls!
In order to protect against this, the Wizard creates and activates a “Q.850 to SIP Cause Code” table that translates a bunch of failure codes to the mostly harmless SIP 480 – “Temporarily Unavailable”:
(If this scenario and table seem familiar to you, we’ve been here before – way back in the pre-historic days of 2011).
Enabling automatic failover / re-route
In a larger setup with another SBC elsewhere you’re probably expecting SfB will try that one next, however it interprets SIP 480 as the end of the road for this call and doesn’t attempt any re-routing.
My preferred fix is to edit the table to turn these failures into a SIP 503 – “Service Unavailable”:
Should SfB receive a 503 from the SBC when the call fails it resumes the call routing and tries the other SBCs in your voice route or policy.
My colleague Mike S. points out that the Q.850 failures identified here would all be natively interpreted as SIP 503 anyway (as per RFC3398), and so specifying the translation is redundant: deleting the table would have the same effect. He is absolutely correct, however for consistency across the whole fleet of SBCs we support, I prefer to retain the table and have the config and behaviour more explicit than implicit.
And yes, if you’re feeling so inclined you can translate it in SfB as well, with a “New-CsSipResponseCodeTranslationRule”.
Summary
I love the Wizard. Don’t stop using it. But if you have > 1 SBC and want to failover between them, don’t forget to update the Cause Code table!
References
- Sonus documentation
- My 2011 post
- Andrew in NZ has also posted on the subject of message translations.
Revision History
15th August 2017. This is the initial publication.
– G.
