Change to Extension Manipulation with Sonus SBC Edge v6.1.3 (SBC1000/2000)

Last week, Sonus released software version 6.1.3 build 474 for their SBC Edge 1000/2000 session border controllers. Whilst I don’t usually rush out and deploy fresh out of the oven updates, in this case there was a pressing requirement for any Sonus CloudLink appliances that were soon to be updating to Microsoft Cloud Connector Edition 2.0.

This advisory was received from Sonus a few days prior to the release of CCE 2.0:

TITLE: Crucial SBC Edge Upgrade to 6.1.3 in Association With Release of Microsoft CCE 2.0

SUMMARY: SBC Edge customers with installed CCEs must upgrade to the new SBC Edge version 6.1.3 on July 18. The upgrade file will be posted on the SBC Edge Download Center. Follow instructions at Upgrading SBC 1000/2000 for details.

This upgrade is necessary for proper operation of the CCE after its 2.0 update.

(Note: The 6.1.3 upgrade must be applied in order to be able to re-deploy a system a system that was running an earlier version of CCE that got auto-updated to CCE 2.0, and this should occur only if you change a parameter after the CCE 2.0 auto-update).

For CCE hybrid environments, installing 6.1.3 did not cause any issues. This is because Microsoft do not include a user’s extension number in the SIP INVITE when routing calls via CCE. For on-premises deployments however, there has been a change to how extensions are handled by the SBC.

Extension Handling

Prior to 6.1.3, the extension component of a user’s Line URI was handled using the dedicated “Calling Extension” field type. Using the entry highlighted below would ensure that, if present, extensions were stripped from a user’s phone number prior to further manipulation taking place. the Input Field Value of (.*) would match “something” or “nothing”, meaning that the table would still be valid regardless of an extension being presented or not:

Here’s a trace prior to 6.1.3 showing the extension being handled independently by the Calling Extension field and subsequently being stripped off:

This trace is of the same call flow once the SBC has been updated to version 6.1.3. Note the extension number is no longer being stripped from the user’s Line URI:

Following up with Sonus TAC (who are always amazing I might add):

This issue has been caused by a change in code that was to ensure the SBC was compliant with REF 3261. In doing so there have been some negative affects with respect to Calling/Address Number and Calling Extension manipulation via the Transformation tables.

With this change it appears the we are no longer able to remove the Calling Extension using the Calling Extension Input Field, and on the Calling/Address Number we are no longer ignoring the ;ext=nnnn in the user part of the from header when looking at the Calling/Address number.

We have engaged engineering on this issue and need to evaluate how we will address the overall problem that has been created.

For clients that still use ISDN trunks, this may not be a major issue. Even if the calling number is not correctly manipulated, the ISDN trunk will still make the outbound call. At worst, a caller’s direct in dial number may not be presented, instead replaced with the main (pilot) number of the ISDN Trunk. However, if the telco trunk is SIP, many providers will drop any outbound calls that originate from phone numbers it does not recognise as part of the known number range. Not stripping the extension number now becomes a problem.

Workaround

If you want to update to 6.1.3 and are still supporting an on-premises Lync/Skype for Business environment, adding the following entry to your transformation table will ensure that the extension is stripped, whilst still ensuring the table is valid if the extension is not present:

Problem solved.