Odd Cause Code 50 with Skype for Business Server

For all the grief that IT architects and engineers give the SIP RFC “standard” causing interoperability issues between different systems/vendors, I could argue that ISDN suffers from similar – although not quite as widespread – deficiencies.  ISDN protocol errors are fairly descriptive, but some errors do not clearly correlate to a particular root cause and could be returned for any number of reasons for a call failure.  A recent PSTN gateway replacement caused a day of head scratching before I realized what the issue was.

Background Info

The pertinent details of this situation are as follows:

• This was Skype for Business SBA deployment for a US site.
• The site was changing from one PRI circuit to another PRI circuit – effectively a PRI cutover.
• The site was changing from another gateway vendor to an Audiocodes Mediant 1000B
  • The configuration on the existing gateway vendor was a cobbled-mess to the point that you really could not rely on anything that was there.  Burn to the ground and effectively start from scratch.
• The site did not have documented specifics of what the PRI carrier required for ANI/DNIS presentation for outbound calls
  • This was despite my plea for the information and clear communication that this could cause issues on Go-Live
• Cutover day arrived and the circuit was swapped
  • Inbound calls functioned
  • Outbound calls did not

The Error

Every single outbound PSTN call attempt from Skype for Business resulted in the PRI carrier rejecting the call:

It did not matter what type of number was dialed, nor the format of the digits presented on either the Calling or Called number – local, mobile, US national, international – the call was released by the carrier.  Syslog messages showed the reason for the rejection was an odd Cause Code 50 error:

local0.notice  [S=10351] [SID:2010590319] (   lgr_psbrdex)(     10161)   pstn recv <-- CALL_RELEASED Trunk:0 Conn:0 RetCause:104 NetCause:50
local0.notice  [S=10352] [SID:2010590319] (   lgr_psbrdif)(     10162)   Abnormal Disconnect cause:50#GWAPP_REQUESTED_FAC_NOT_SUBSCRIBED Trunk:0 Conn:0

The “Requested Facility Not Subscribed” error was not one I had previously encountered and was not particularly familiar with.  As any “normal” person would do, I turned to Bing/Google in the hopes that I could find a similar case to help guide me, but few searches were helpful.  It seemed that Cause Code 50 could be returned for various scenarios where you are attempting to use a feature that isn’t supported on the trunk.  My unsuccessful initial troubleshooting involved changing either the Called Number or Calling Number format (including the TON/NPI indicators), thinking that it was an issue of the carrier not “liking” how we were presenting those digits.  My “ah-HA!” moment came when I stumbled across a Cisco Community forum post with a similar issue and realized it had nothing to do with digits at all….

The Cisco forum post was undeniably helpful in opening my eyes to the fact that this error could be caused by Calling Name information in the outbound call request to the carrier.  Examining the Syslog entries again, I could see that a Calling Name was being presented:

pstn send --> PlaceCall: Trunk:0 BChannel:9 ConnID:0 SrcPN=+1714XXXXXXX SrcSN= DstPN=01161298702200 DstSN= SrcNT=0 SrcNP=0 SrcPres=0 SrcScrn=0 DstNT=0 DstNP=0 ServiceCap=M RdrctNum= RdNT=0 RdNP=0 RdPres=0 RdScrn=0 RdRsn=-1 Excl=1 Display=Test3 UserNMC3 IE= UUIE=0, RawData:0 CLIRReason:-1 OrigPN= OLI=-1 OffhookInd=0 SendingComplete=1 MoreDigitsInNext=0

The format didn’t contain any hidden or non-standard ASCII characters from what I could see.  I went so far as attempting to modify the Calling Name to be a different value than the initial attempts, but those calls were still rejected.  Re-reading and focusing on the Cisco article again, I realized the true root cause…that the carrier did not want Calling Name at all.

The Fix

There are a few ways of potentially removing Calling Name on Audiocodes appliances for PRI calls:

• Configuration->VoIP->GW and IP to IP->Digital Gateway->Digital Gateway Parameters->Remove Calling Name=Enable
• Configuration->VoIP->PSTN->Trunk Settings->Remove Calling Name=Enable
• Configuration->VoIP->GW and IP to IP->Manipulations->Calling Name IP->Tel

While any of these approaches would have effectively done the trick, I typically don’t like to set Global parameters unless absolutely required.  My personal preference is to set parameters as explicitly as possible so I went with the last option and created a quick manipulation table entry to remove the Calling Name:

I tested a call after setting the configuration above…and voila!  Outbound calls to the carrier now proceeded and connected without issue:

pstn send --> PlaceCall: Trunk:0 BChannel:10 ConnID:0 SrcPN=+1714XXXXXXX SrcSN= DstPN=01161298702200 DstSN= SrcNT=0 SrcNP=0 SrcPres=0 SrcScrn=0 DstNT=0 DstNP=0 ServiceCap=M RdrctNum= RdNT=0 RdNP=0 RdPres=0 RdScrn=0 RdRsn=-1 Excl=1 Display= IE= UUIE=0, RawData:0 CLIRReason:-1 OrigPN= OLI=-1 OffhookInd=0 SendingComplete=1 MoreDigitsInNext=0

pstn recv <-- CALL_CONNECTED Trunk:0 Conn:0 BChannel:10 Number: SubAddr:

In the end it was as simple as Caller-ID Name being sent on the call….who woulda-thunk!?

I suppose for some carriers, Calling Name support may still be a purchased “feature” on a voice circuit which is why the error of “Requested Facility Not Subscribed” made sense after-the-fact but didn’t necessarily send off any light bulbs at the outset of the issue.  With the configuration in place, production outbound calls started working as expected and we were able to complete the site deployment.  Definitely an odd issue – probably not encountered all that often – so here’s hoping that this will help someone else down the road!