THE ISSUE:
Some element of audio is completely missing from calls. This could be a one-way audio issue, or that audio is completely missing.
We often hear that audio works just fine with other VoIP providers and it's just SIPTRUNK.com that is the issue. This may be true, but there's a very concrete explanation for it! Get a cup of coffee and do some stretches, because this is going to be a long article. Don't worry, we'll give you a "tl;dr" first!
TL;DR:
SIPTRUNK.com delivers audio a little differently from many VoIP carriers. Your networking infrastructure needs to accept RTP(Audio) from any IP address and forward it to your PBX.
THE SOLUTION:
VoIP communications is not mystical wizardry, but there are many pieces that combine to form the service you know as telephony. The two main pieces are SIP and RTP. SIP packets can be understood as the signaling information. Bob wants to call Alice, so SIP tell's Bob's phone where to find Alice's phone and ensures that the phones stay connected while they carry on their conversation. RTP carries the media/audio of a call. Bob speaks, his phone converts his voice to an RTP packet, the RTP packet is delivered to Alice, Alice's phone turns the RTP into Audio which Alice recognizes as Bob's voice.
SIP can be transmitted and re-transmitted with very few ill-effects on the overall experience of a user. RTP however, needs to be sent with no-re-transmissions and as few errors as possible. It also needs to be delivered as quickly as possible. If any one of the problems in the last two sentences crop up, users will notice because they will hear the the problem!
To provide the best audio quality possible SIPTRUNK.com tries to give RTP streams the shortest path between the two ends of the call. This can cause some issues when a networking environment isn't set-up for getting the RTP stream from a different IP address than it gets the SIP traffic from. Here is a graphic that demonstrates how SIPTRUNK.com is different from many other VoIP providers.
Referencing what you've learned so far; if Bob calls Alice with SIPTRUNK.com, Bob's firewall opens a connection with SIPTRUNK.com for SIP traffic. It will also automatically open a connection with Alice's phone for RTP traffic after SIPTRUNK.com tells Bob where Alice's phone is. However, when Alice's phone tries to send RTP to Bob, his firewall might not let Alice's RTP in. The result will be one way audio where Alice can hear Bob, but Bob will never be able to hear Alice.
Alternatively it might also be the case that Bob's firewall will refuse to open an RTP connection to Alice's phone since it only knows about the connection to SIPTRUNK.com. This would result in no audio at all even though their phones think they are connected to each other. This result will almost certainly be the case if Alice calls Bob, as his firewall may not have any clue why Alice's IP is trying to open an RTP stream with him.
The way to ensure that Audio connection is established in each call through SIPTRUNK.com, is to allow RTP streams to reach your phone/PBX from any IP address. You may also need to allow RTP connectivity to ANY IP address even when it's initiated by your phone. With Asterisk based systems RTP operates on ports 10000 to 20000 by default. Other systems vary. Determine the RTP ports used by your system, allow UDP connections from ANY IP to those ports, and forward those ports to your PBX/Phone only.
ISN'T THAT INSECURE?
Couldn't somebody commit a Denial of Service (DoS) attack? Isn't opening RTP ports dangerous? Random SIPTRUNK.com knowledge-base author guy (or girl), you should know those Chinese hackers (and the NSA) are everywhere!
We understand what you are saying but we don't think that DoS is a valid concern in this instance. RTP is used within UDP packets. As you know (or maybe you don't), UDP packets are not concerned with whether or not they were delivered. We can send you 1,000,000 UDP packets, our computer doesn't care whether you acknowledge them, and your computer should never try to acknowledge them. Furthermore by opening the RTP ports on your firewall and then forwarding them to your PBX you should know with certainty that your PBX isn't going to respond to those packets (if it does something beyond accepting and transmitting RTP on those ports, there is a fundamental flaw with the programming of your PBX...FIND A NEW PBX IMMEDIATELY!). Your PBX will simply accept the packets if there is an associated call that has opened the port that the RTP packets are received on. Thus SIP is the gateway to whether or not your server will accept a given RTP packet. Since your SIP ports should be locked down to accept traffic from gw1.siptrunk.com and gw2.siptrunk.com there should be no danger of someone opening a false RTP session and your server trying to accept those packets.
Thus, someone could use a botnet to flood the open ports on your firewall with UDP packets but your PBX will simply drop them. Your firewall does have to go through the extra step of routing the packets from a botnet that are going through the firewall but the processing overhead shouldn't prove much greater than the risk to having the firewall drop the packets. You can botnet attack a closed port with RTP just as easily as an open port.
In summary it's a calculated risk, but extremely mitigated, and the benefit to allowing media to come directly from dozens of sources which can be closer to the endpoints is very nice (crystal clear call quality).
Great Information, Thanks Team!