I’m not going to do my usual detailed write up on this one just figuring this might help someone Googleing, But I recently had to look into an issue for a customer who had another intergrator build thie Skype4B platform and all worked well.
The issue was that when a call came from an external PSTN line and hit a response group that was designed to forward to a dedicated mobile(cell) phone. If the device was busy, the call would drop instead of forwarding to the carriers voicemail.
Luckily the carrier in question (Telstra) announces diverts in band as well as the usual out of band notification messages and I could see that the inband message never got played.
After a little digging with the CLS Logging tool and Snooper, I could see the RGS service itself generating “BYE” messages with “The Response Group application was unable to transfer the call to the configured destination and no fallback exists”
Further digging in snooper showed that the call transer was being aborted because it wasnt a safe transfer.
A quick check of the trunk configurtation and I can see that the previous intergrator had enabled sending “Refer” to the Sonus gateway.
Unfortunatley as I didnt have access to the Sonus I couldnt see what the issue was on the gateway, Sure enough turning refer support off on the trunk resolved the issue as the call legs were now being handled by the Mediation Role instead of the gateway itself..
If I get time (and a spare sonus) I might lab this one up for better details.
Till next time….heres some quick nasty notes I took at the time
Excuse the crudity of the diagrams, I didn’t have time to paint them
When the remote party attempts to forward the call to another phone or voicemail service an outofband diverting message is sent to the gateway, which is passed up to the Skype4B infrastructure.
Skype4B or the Gateway isn’t expecting a remote divert and thus tears down the call
We solve this problem by disabling the “Refer” support on the trunk between the Skype4B infrastructure and the gateway. Thus there is no call processing done by the gateway itself, the mediation server is now responsible for joining the two call legs together. This however has the disadvantage that additional voice traffic will pass between the external gateway and the mediation server.
REFER is evil and should be banished forever.
I dont know a single deployment that I’ve enabled it. the Gateway and mediation servers are usualy side by side anyway. The only time it would be benificial is if media bypass is disabled (it was at this customer due to their CAC config)
This REFER support caused more issues in my 6 yrs of working with it while enabled, than the advantage it was supposed to solve by implementing it.
“The Response Group application was unable to transfer the call to the configured destination and no fallback exists” also occurs when you make a sip2sip call to RGS from O365 to on-premises SfB RGS and workflow fails to transfer to queue.
I’ve not tested this scenario but its nice to know. Thanks.
I am experiencing the same behavior when calling and RGS from O365.
I was seeing “The Response Group application was unable to transfer the call to the configured destination and no fallback exists” as an unexpected failure although it still followed the workflow.
Calls routing ok to RG but when all agents were unavailable the call would route successfully to workflow at “Outside of business hours, process call as follows (after the message has played, if you have configured one).” which was an external number.
I honestly can’t say I’ve seen that one before. Weird
It means that you have to adjust a Voice Policy to include a specific PTSN Usage that is somehow missing for this route, i figured out.
I recently tried killa kush brand , and I’m extraordinarily impressed with the quality. The effects were mild, calming, and literally what I was hoping for. The make of options also allowed me to find something flawless for both relaxing evenings and fecund days. Absolutely advise for anyone seeking significant results!