So I recently had an issue at a customer where any Polycom 2W Wireless conference phone devices attached to an Audiocodes M1000 FXS ports would drop calls when attempting to establish a second call using the “Multi Party” button, but this issue could apply to any analog device that uses Hook-Flash to switch between virtual lines
If you can come up with a better wireless conference solution for Skype4B I’m eagar to hear it.
About Hook-Flash
When an Analog device attempts to place a user on hold, make another call or switch between callers a “Flash Hook” event is sent down the phone line to the Telco/Exchange/Audiocodes. This is effectively hanging up and picking up the phone really quickly as there is no other way to send “outofband” messages down an already established audio channel. Hence why in old movies you will see people tapping the hook switch to get an operator.
The issue
The issue was twofold. The Audiocodes wasn’t detecting the Hook Flash events from the Polycom2W units as they were too short (100ms), we adjusted the detection interval on the Audiocodes end to 60ms and the “Flash period” (the amount of time the hook switch is held down) on the 2W units to 200ms to allow for detection without terminating calls. Once this was completed calls were getting dropped several seconds after a hook-flash was sent.
Logically this would indicate the hook-flash is being held too long and making the Audiocodes think the user has hung up the device. However further investigation found the device was indeed detecting Hook-Flash correctly and placing the call on hold. The gateway would then, several seconds later drop the call with a “400 Bad Request” statement in the BYE packet.
After enabling debugging on the Audiocodes and digging into this further, the issue turned out to be that the Audiocodes was terminating the call as it wasn’t receiving an audio stream from the Skype4B mediation server (ChannelResource:RTP_BROKEN_CONNECTION_EV)
This was caused by the “Hold Format” setting for the gateway’s internal hold server using the “Sendonly” format instead of sending “0.0.0.0” in the SDP header, once this was changed in the gateway configuration the issue was resolved.
Most SIP carriers require that you set the Hold Format to “Sendonly” when terminating with them, however the best place to set this is the SBC Remote Hold Format attribute. There is no need to set this in the Gateway as this confuses the internal hold server.
You can find the gateway setting under Advanced > Voip > Gateway > DTMF and Supplementary > Supplementary Services
Hope this helps someone else!
Breakdown of a failed call
- Call is established
- User sends “Flash Hook” event
- Audiocodes SBC invites Audiocodes Gateway Module to play hold music
- Gateway answers and starts playing hold Music
- Gateway Terminates the call with the error “400 Bad Request” as no media stream is established