Issue Description:

Recently I did a project of adding additional Telstra SIP trunks into Sonus production environment. The customer Sonus environment has primary SIP trunks with another SIP provider. They are going to use the new Telstra SIP trunks set up for new established small office. After the new trunk set up. I had one issue: when the calls were forwarded from SFB clients to users’ mobile phones, the A party number didn’t Pass through, instead, the number shown on mobile phones is the pilot number of the primary SIP trunk. The feature of A Party Number Pass-through was not supported by the primary SIP trunk provider, but on the new Telstra SIP trunk, this feature is definitely supported as I know. Now my question is: how to configure SBC to forward calls out back to Telstra Signalling group where the incoming calls comes in?
 
Investigation:

I did a testing call (A Party Rang B Party, B Party set to forward the call externally to C Party) and captured the logs for the whole call forwarding scenario, I can see the forwarding part of the call has a SIP “invite” message sent from the mediation server. in the SIP header, it contains all the numbers of Party A, B, C. Screenshot as below:
I can see the HISTORY-INFO data field contains “B Party Number” during the call forwarding. what I was thinking to do is to create a transformation rule to compare on the History-Info data field value, if the value contains the Telstra SIP trunk number range, the call should be routed out via the Telstra SIP Trunk.
Before creating new rule, I wanted to verify the A Party Number Pass-through was working. I created an optional rule to match calling address/number with my mobile number (A Party). When I called the Telstra number range, calls coming in from Telstra trunk and went out ringing another mobile (C Party) via the same trunk, A party number displayed as Caller number. It’s all good.
I set up the message manipulation rule for invite message based on below Sonus Doc (the first half of the doc) https://support.sonus.net/display/UXDOC61/Using+HISTORY-INFO+to+set+the+FROM+Number.
After that I tried to put an optional transformation rule matching the Telstra outgoing calls out, it didn’t work and still the call went out from the primary trunk. Because this rule can’t be mandatory under the current SFB to Telstra routing table. It will disconnect the normal outgoing calls on the Telstra trunk.
Next, I created a mandatory rule to compare the history-info value and bind this rule with Telstra SG, re-test the call forwarding scenario, still the call went out from the primary trunk. :/
When I moved to the Sonus local system log, I couldn’t see any logs contains the “SG User” variable. This made me realise that the inbound manipulation rule assigned to Telstra SG was totally wrong, because the invite is from SFB server, so I correct this setting. It started to work as expected.
Solution Summary:

  1. Create a message manipulation rule “Collect History-Info” on the “invite” message to collect “Collect History-Info” to “SG User Value 1”: Applicable Messages – Selected Messages, Message Selection – Invite, Table Result Type – Mandatory, refer to screenshot below:

  2. Assign it to the Inbound Message Manipulation of SFB SG
  3. Create a transformation rule to compare “SG User Value 1” with the Telstra SIP trunk number range:

  4. Create a NEW route match this transformation rule.

 
After this, retest the call forwarding scenario, both inbound part and the forwarding part of the call are routed through Telstra SIP Trunk. The result looks all correct. Verified the issue resolved. 😊

Category:
Lync

Join the conversation! 1 Comment

  1. The important part here for anyone else coming across this document, is unlike in the Sonus Documentation, you should NOT be replacing the “Calling Name/Number” with whats stored in the SG User Value 1 variable. Instead assign it to “Original Calling Number” otherwise Party C will get Party B’s number displayed.

    You must ensure that the Pilot Number is still presented in your PAI to Telstra or they will reject the call

Comments are closed.