I recently encountered a strange problem where calls to certain test numbers stopped working as expected after we’d commissioned a new Sonus PSTN Gateway for Lync (in this case an SBC1k running 3.0.2 b271 firmware) “upstream” from the PABX.

If you called ”127 22123” from the PABX, the call just rang and rang without answer – where it should have answered instantly and spoken your CallerID back to you. (This service has lost much of its relevance of late simply because it’s just as easy to call your mobile and view the CallerID on screen, adding the 1832 prefix if the line’s normally set to hide its details by default).

Installing the Gateway “Upstream”

Just in case you’re not familiar with the scenario, let me fill in some background.

As a first step to ease an Enterprise Voice customer into Lync, we’ll often commission their new PSTN Gateway “upstream” of their PABX, and we do so just by breaking their existing ISDN service to the PABX and re-routing it through the gateway. It’s often as simple was re-routing a patch cord, although you’ll need an ISDN crossover like one of these guys for one leg.

As far as the PABX is concerned it still thinks it’s talking to the carrier, whilst to the carrier the gateway emulates a PABX.

Before		After

This configuration brings with it multiple benefits:

• Users can be easily and quickly migrated from the PABX to Lync
• PABX users can still reach the Lync users (and vice versa) without the call routing via the PSTN and incurring charges
• The Lync users are still contactable on their normal PSTN number, and still present that same number when they call the PSTN
• We don’t need to engage the PABX maintainer for reconfiguration or to establish ISDN or SIP trunks to Lync for the duration

As far as downsides are concerned, the main weakness of this solution is that you require twice as many ISDN ports for the hopefully short period where you have users on both platforms. That’s not ordinarily a problem for a relatively small site serviced by a single T1/E1, but of course for a major head-office this might appear prohibitive and require a more considered cost justification.

Overlap Sending / Receiving

A lesser (although quite annoying) problem we see here in Australia is when the PABX uses Overlap Sending to the exchange (typically Telstra), rather than the more common “en-bloc” method.

With a gateway in the flow it needs to capture all of the dialled digits before it can determine whether the call is to be routed to the PSTN or to Lync. As it doesn’t know how many digits are going to arrive, the only option is to wait for an “end of dialling” timer to elapse. In the ISDN Signaling Group to the PABX, that’s the T302 timer.

 
I usually set it for 4 seconds, as I believe that to be the best compromise to cater for those who are slow to dial, and not cause everyone to suffer an interminable post-dialling delay. (Occasionally something hanging off the PABX has forced me to drag this out to 5 or 6 seconds, but that’s normally a stopgap measure until the offending device – usually a fax or EFTPOS terminal – can have its ‘wait for dial tone’ delay cut or disabled altogether).
 

Message Translations to the Rescue!

Sometimes this fairly simple installation process will throw a curly one at you, and you’ll need to tweak some ISDN signaling parameters to re-establish normality – as was the case here.

A trace of the call using Sonus’ “LX” application quickly revealed what was going on: the carrier had signalled that there was in-band information – the spoken message being delivered on the B-channel – however the PABX was still resiliently playing ringback tone to the caller, waiting for a formal answer to the call.

It didn’t take me long to craft up a Message Translation triggering a “pseudo-answer” and apply it to the Call Routing Table entry for calls from the PABX to the PSTN:

The table above takes an incoming “Inband Information” message and turns it into a “Connect” – the answer signal the PABX is seeking.

If you’re at all concerned that tweaking the signalling could disrupt or adversely affect other call types, just create a new Transformation Table that matches only this number or range of numbers and add a new entry to your routing table. You then apply the Message Translation to just this entry and not all calls… (Don’t forget to move your new rule higher in the sequence so it fires before other less specific rules that don’t reference the translation table!).

You are likely to encounter other times when you need to adjust the ISDN or SIP signalling between a carrier and a PABX, or a pair of PABXs, and the process is much the same.
 

– G.