Call forking, or in Skype4B parlance ‘Sim-Ring’, can be a nasty business both from a technical perspective and from an end-user perspective. One can certainly arrive at potential use cases for call forking, but companies that insist on deploying call forking between Avaya/Cisco & Skype4B often regret the decision later on due to the poor user experience.
Note: I am a strong opponent of utilizing call forking as a method to get calls to Skype4B users – the architecture is poor and the user experience is confusing at best, and mind-numbingly-frustrating at worst. Avoid it at all costs and don’t fall into the temptation of trying to ‘offer the best of both worlds’. It’s not the best of either solution and is rubbish to think otherwise.
If you insist on going down the call forking path and are utilizing Avaya EC500 functionality, you may run into unforeseen issues due to some settings within Avaya that impacts call flows to Skype4B Server.
The Setup
- Skype4B Server is downstream of Avaya
- Skype4B Server has Avaya SES as the PSTN Gateway in topology
- Avaya CM’s have licenses for EC500
- Skype4B users have EC500 enabled on their Avaya extension
- This essentially ensures that both Avaya and Skype4B ring when someone calls their Avaya extension
- Avaya extensions for Skype4B users have a call coverage path & configuration set still defined
The Issue
If a Skype4B user is set to DND or not signed in and they receive a call to their Avaya extension, the inbound EC500 forked call to Skype4B Server appears to never reach Exchange UM voicemail and instead goes to the Avaya voicemail system. All other inbound/outbound call flows worked correctly, but the two scenarios above showed a very different call behavior:
- Skype4B Server would receive the inbound EC500 forked call and redirect the call to Exchange UM successfully
- Even though Exchange UM answered the call, the caller would continue to hear ringing
- The caller continued to hear ringing while the Skype4B call flow was active but Avaya would then send a SIP ‘BYE’ message and terminate the Skype4B call flow, ultimately sending the caller to the Avaya VM system
- The Skype4B user would receive a ‘Missed Call Notification’ from Exchange UM
The whole scenario was a bit perplexing as the desired state (and normal state) was to have Exchange UM answer the call and receive the caller’s voicemail message, but it was more difficult to explain why it was Avaya that was sending the ‘BYE’ message and sending the caller back to Avaya voicemail. Of course Skype4B was assumed to be ‘broken’ but after all the back-and-forths we were able to determine the true root cause…
The Fix
This particular customer was utilizing ‘Cellular Voice Mail Detection’ within Avaya Configuration Sets and had those settings applied to their Skype4B user’s extensions. What this meant was that any immediate answer of a forked call invoked the ‘Cellular Voice Mail Detection’ settings and prevented Avaya from using the forked call, to ensure that the call always ended up in the Avaya VM system instead of an external VM system.
change off-pbx-telephone configuration-set 1
cellular voice mail detection: timed
The customer had the setting set to 4 seconds, which meant that any EC500 forked call answered within 4 seconds was treated to be a remote VM system. The BYE messages didn’t correlate with this 4 second timer and instead matched up with the Voicemail diversion timer – the point at which a call gets diverted to Avaya VM after ringing an Avaya IP phone for a defined number of seconds. Once Avaya VM answered the call, Avaya would send the SIP ‘BYE’ message to the EC500 forked call leg. What this meant was that Avaya had actually established audio on the EC500 call leg to Skype4B but wasn’t using it, thus leaving Exchange UM in a perpetual state of silence wondering if the caller is still there. Bottom line: the ‘Cellular Voice Mail Detection’ setting proved to be the proverbial ‘needle-in-a-haystack’.
The ultimate fix was two-fold:
- Create a new configuration set for Skype4B extensions
- Set Cellular Voice Mail Detection setting to ‘None’ in configuration set for Skype4B extensions
- Apply the new configuration set to Skype4B extensions
Once the settings were in place, they were rolled out to the Skype4B extensions on Avaya and all the call issues went away. Calls now landed in Exchange UM which is exactly where they were meant to be in the first place.
Wrapping Up
If Exchange UM is the desired endpoint for all voicemail you really should remove the users Avaya VM configuration, but if VM is required on both sides then you need to make sure that the ‘Cellular Voice Mail Detection’ setting doesn’t cause you unintended problems!
Note: To be fair, Skype4B Server has the same type of functionality as well, called Voicemail Escape, to detect if a Sim-Ring call has been immediately answered by a remote voicemail system. While Avaya’s settings were the root cause in this case, you can potentially see the same symptoms due to settings on the Skype4B side as well. Voicemail escape is not enabled by default, however, so plan carefully if you choose to implement.