The Enabling Technologies Blog

Our team of Cloud Strategy Advisors, Solution Architects, Engineers and former C-Suite Executives work diligently to provide our vistors with the most pressing information.

Dave Bergquist /

One-way Audio Issue with AudioCodes SBC and Dialogic HMP


I recently worked with a client migrating from Sonus VX1200 SBCs to AudioCodes Mediant 2600 SBCs. This included porting all routes, manipulation rules, and settings. The VXs were configured to work with various applications and devices such as Skype for Business, contact center, IP centric IVRs as well as analog gateways and endpoints.

I was able to successfully translate everything from the VX1200 SBCs to the AudioCodes Mediant 2600s, however we discovered one-way audio issues between the Public Switched Telephone Network (PSTN) and the IP-based IVR. What initially seemed to be a sporadic issue was one-way audio received from the IVR application (which relied on Dialogic HMP under the hood). Occasionally the caller would hear the IVR answer multiple times in a row, and other times you wouldn’t hear anything at all (silence).



Wireshark captures, and debug recordings were captured at the AudioCodes SBC and the Dialogic HMP IVR application. Based on those captures I could see that the IVR/HMP was sending the audio media to a port lower than requested by the AudioCodes INVITE (17624), and then sending RCPT to the audio port requested by the INVITE (17625). In short, the AudioCodes SBC was being sent an audio stream to a port it wasn’t actively listening on.

Invite from the AudioCodes SBC ( to the IVR ( requesting audio media to port 17625:



However, the IVR (HMP) sends the audio stream to port 17624…which is a port lower than the AudioCodes SBC requested:




You can see here that the IVR (HMP) then sends the RTCP packets for this call to the audio port (17625) originally requested by the AudioCodes SBC



The one-way audio issue experienced was a result of differences in RTP port spacing. Dialogic HMP utilizes even number ports only, while by default the AudioCodes SBC utilizes a mixture of odd and even number ports. I was able to work around this issue in the AudioCodes SBC configuration by changing the parameter “RTP UDP Port Spacing” from its default (5) to “10”. “RTP UDP Port Spacing” can be found via the AudioCodes web interface by going to: Setup -> Signaling & Media -> Media -> RTP/RTCP Settings -> General

Note: Changing this parameter requires a reboot of the SBC.


Per the AudioCodes documentation, the device allocates UDP ports for RTP and RTCP

traffic per session in "jumps" (spacing) of 4, 5, or 10. By default the RTP UDP port spacing is set to “5”. For example, if the port range starts at 5000, the available ports include 5000, 5005, 5010, 5015, and so on (depending on number of simultaneous media sessions). As you can see, it’s possible for the AudioCodes SBC to include odd numbered RTP ports for audio media in the INVITE. This explained why sometimes we had audio and others we did not – the AudioCodes SBC would request to use an odd-numbered RTP audio port, and the Dialogic HMP IVR would not use the odd port, but the closest even port (one lower) instead. If the port range starts at 5000 and the RTP UDP port spacing is 10, the available ports include 5000, 5010, 5020, 5030, and so on (depending on number of media sessions). In this example, calls sent by the AudioCodes SBC will always contain even-numbered RTP audio ports, and odd-numbered RTCP ports. 


Contact Enabling Technologies if you require any assistance.

Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.