This problem presented itself at one of my customers a couple of weeks ago. I thought it was an interesting case that I should share this incase you find yourself in a similar situation. The problem started withe an e-mail to me from a current client saying “Please can you help? When someone calls our main office line they don’t hear the phone ring”. To set the scene this means that when the Caller places a call to a number, they don’t hear the ringing tone in their ear. This has a few names, but for consistency with telephony naming, we will call this ringback.
A few more pointed questions later, I determined that when the Caller (Calling Party) placed the call, the Callee (Called Party) recieved ringback and when answered, the media was established and the called party could have a conversation with the calling party. This could get a bit confusing so perhaps this simple diagram will help
Person A is the customer and User B is the Skype for Business receptionist at the customer. For the rest of this post, we will refer to Person A and User B when describing call flows.
During validation testing of the problem, the following outcomes were recorded:
- When User B placed a call to Person A, both parties received ringback.
- When Person A called User B, User B heard ringback, but Person A heard silence.
- When Person A called User C (i.e. user with DDI number) both User C and Person A heard ringback.
- When User C called Person A both parties received ringback
- When User B called Person A, Person A received the Caller Display of the main line office number
I decided to approach this from two angles, one from Skype for Business to the PSTN and from the PSTN to Skype for Business. At this point I was fairly certain that the problem was not with Skype for Business itself, but some problem may be with the client device, the SBC or an issue with the carrier perhaps. The first thing I wanted to get the bottom of was why scenario 4 worked and scenario 2 didn’t, as the experience should have been the same for both. Therefore something with scenario 2 was slightly different to scenario 4 and if this could be identified we have a point to start from.
Breaking out snooper and centralised logging placing two calls, one replicating scenario 2 and the other scenario 4 I was able to capture the logs and compare side by side. Immediately, I could see that when I replicated scenario 2, the first SIP INVITE Skype for Business received was to a Line URI that was different to the number I had dialled as Person A.
So the burning question, how is the dialed number translating to the Line URI of the user? In Skype for Business I checked the trunk configuration for any called translation rules, nothing there. So the translation must be happening higher up in the call flow. But before I moved my attention there, I decided to compare both call flows all the way through the leg. No other differences where found, the same SIP message flow and SDP was identical, so the TO header was the key. This was compounded by the fact that if Person A dialed User B’s DDI rather than the main line number, Person A heard ringback.
Now I had to capture the logs from the SBC. It’s an Audiocodes one, and anyone who knows me personally, knows that I have tried (until now) successfully to avoid being in the same building as one, let alone trying to troubleshoot one! So this was going to be a learning curve…
First up I didn’t have the Audiocodes Syslog viewer application, until fellow MVP Jonathan McKinney kindly assisted me. But as he is on CST and I was GMT, I had to improvise and use Sonus LX Logger to capture the logs and Notepad++ to read and search. Again, looking at replaying scenarios 2 and 4 I could see that the first invite the SBC receives from the SIP provider in scenario 2 was that of the User B Line URI and not the main line number that Person A had dialed into their dialpad. So the translation must be happening either with the provider or some other system that we were not aware of. Other than this the SIP message flow of both calls appeared to be almost identical (difference highlighted in red).
Scenario 2 (Failed Call Flow)
Scenario 4 (Working Call Flow)
Interrogating the call flow a bit further, paying particular attention to the first invite received by the SBC from the provider I noticed a subtle difference in the SDP body sent
Working Scenario 4 SDP
Failed Scenario 2 SDP (difference highlighted)
At this point I could identify that although both calls were being passed to the SBC on the same trunk, from the same provider, there was an additional leg in the call in scenario 2 than 4, and this was the source of the problem.
First I tried to remove parts of the SDP body before it was sent to Skype for Business to make it identical to that of the working SDP body. This involved creating some message manipulation rules to remove silencesupport and maxptime from the non working message and add sendrecv to it. Once I had identical SDP I tested the call again. Still the same.
The customer raised the problem with the provider, but they were less than helpful, blaming the configuration at the customer side and washing their hands of it. The fact that it has previously been working for months, if not years and there have been no changes to SBC configuration in that time including firmware (still on v6..), something had to have changed with the system that was translating the main line number to User B’s direct number that caused the incompatibility.
As a last ditch attempt to try and do something for the customer I decided to implement the following workaround / fix:
- Disable Early Media on the trunk configuration between the SBC and the provider
- Enable ringback to be played from the SBC rather than relying on the remote endpoint to play it. In otherwords, send ringback as media, rather than signalled.
After this was applied, Person A heard ringback. Result!!
There is of course an offset in experience for disabling early media. When Skype for Business users dial a PSTN number they hear Skype’s default ringback melody rather than the PSTN tone of the country. A slightly different experience for users, but traded against the issue they had, an acceptable adjustment.
Although a simpl(ish) resolution, I thought that the scenario was an interesting one to share and could help to prevent you falling down the rabbit hole as much when presented with a similar kind of problem.