In a recent Lync project I came across an interesting issue with SIP Trunks, fortunately we had an AudioCodes SBC so there was a simple solution to the problem.

Problem

In some call-forwarding scenarios no audio connection could be established, a debug trace on the gateway would show no RTP packets at all.

Signaling was working just fine, all the right IPs and Ports were listed within the SDP messages, as you see in the screenshot, though, no RTP packets can be seen.

Solution

Apparently the SIP provider used some kind of NAT or security device in front of their SIP equipment, and pinholes were only opened when this device received any incoming packets from our side of the communication.

That’s when I learned about the “NoOpEnable” parameter which is designed for problems, just like this one. Once the “NoOpEnable” parameter is set to “True”, the SBC will send one RTP packet (with payload No-Op) to each IP involved in the session (retrieved from SDP). The following Screenshot shows another debug trace, please note the first to RTP packets:

This did the trick, whatever device the remote side was using, it let RTP packets through once it received an incoming packet.

For more Information on the No-Op Payload Type, check out the following IETF Draft: A No-Op Payload Format for RTP

Enable NoOp

The NoOpEnable parameter can be configured using the devices AdminPage, which can be found at: https://<IPAddress>/AdminPage

Another way, the one I prefer nowadays, is to use the SSH command-line interface, simply connect to the device using PuTTY or TeraTerm and use the following syntax:

configure voip
media RTP-RTCP
  no-operation-enable 1
  activate

Lessons learned

Always use an SBC if dealing with SIP trunks :)

Tom