Sonus CloudLink: Call Transfer Failed for PSTN Caller

I came across an interesting issue today with a Sonus CloudLink deployment involving failed Call Transfers of PSTN calls. I'll start with the background on this deployment.

Background

This deployment was fairly straightforward. The organization started out with a fresh Skype for Business Online environment, and no Hybrid was ever involved. All users had E5 licensing with Cloud PBX. The firm had a CUCM device (and another random Intercom device using an FXO port), and they wanted to continue using their voice carrier with their existing DIDs for their Cloud PBX users. They decided to go with a Sonus 1K and CloudLink for the solution.

The journey to the point of our Call Transfer problems was a little longer than it needed to be, as this was my first CloudLink deployment, and there were a few lessons to be learned. Let's suffice to say, the CCE instance was finally installed nicely on the ASM, and calls were flowing quite nicely between all components: CCE, CUCM, and PSTN. All was just peachy. Until we tried to transfer an answered PSTN call to another Cloud PBX user, or their voicemail.

The Problem

To reproduce the issue, I would place a call over the PSTN using my cell phone to a DID that had been assigned to one of the test users that had been migrated from CUCM to Cloud PBX (CCE). The test user account was able to successfully answer the call and have a conversation. However, once the Cloud PBX user tried to transfer this PSTN call to another Cloud PBX user within this same tenant, or to their voicemail, the call would be placed on Hold, and an error message would appear in the Skype for Business client call window stating that the Call Transfer Failed.

Frustrating, but ok. Let's fire up the LX Logging tool for SBC logging, and run the CCE Logging wizard that is provided within the Sonus web interface on a CloudLink device. First, looking at the call in the LX Tool, I saw this entry in the Call Flow:

As you can see, this NOTIFY entry was where the Transfer attempt took place, and we the text:

Subscription-State: terminated;reason=noresource

and...

SIP/2.0 503 Service Unavailable

Well, this had me scratching my head. I wasn't sure what service it was saying was unavailable, or why the call could not be transferred based on this error, and the other messages in that chain didn't help. Taking a look at the CCE logs actually revealed the exact same issue, but nothing else that helped me:

After looking around a bit more, I finally involved the Sonus Support team (who has always been incredibly awesome to me!). After providing my logs, and a Config Backup of the SBC, they were able to spot the issue.

The Resolution

You see, in their documentation for installing and configuring the CCE instance, Sonus strongly suggests that you use the SBC Easy Setup wizard for configuring all your call routing rules, etc., as seen below:

However, I decided to be special, and create all the Signaling Groups, Call Routing Tables, and Transformation rules on my own. This wasn't an issue leading up to the Call Transfer problem, because all of our call routing was working as expected. However, the Sonus Support tech somehow was able to note (probably from the Config Backup) that I had not used this wizard. He then pointed out that one of the things that the wizard does is to create a Split-DNS entry on the SBC itself for the default CCE domain that is created with the CCE wizard (which is sfb-ccedomain.local), pointing this domain name to the IP address of the AD/DNS server that is created as a CCE VM. He stated that without this entry, the SBC was unable to resolve the Mediation Server's FQDN (med.sfb-ccedomain.local).

Now, I was confused why this was necessary for Call Transfers, but apparently not an issue with normal P2P calls, as the Mediation Server's IP address seemed to be sufficient. However, it was worth a try. So, I when into the DNS section on the SBC and created the new entry.

Then, I went and tested out the PING utility in the SBC's Diagnostics tab, and sure enough, it now resolved med.sfb-ccedomain.local, whereas it could not resolve it before. Brilliant!

Finally, I went to test transfer, both to a user, and to their Voicemail, and guess what? Yep: SUCCESS! Good way to end a Friday! I hope this helps at least one or two of you on your CCE or CloudLink adventures.