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 SIP.US that is the issue. This may be true, but there's a concrete explanation for it. SIP.US delivers audio 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. RTP packets make up the audio.
Example: Bob wants to call Alice, so SIP tells 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, and Alice's phone turns the RTP into audio recognizable as Bob's voice.
SIP can be transmitted and retransmitted with very few compromises to the overall experience of a user. However, RTP needs to be sent with no retransmissions and as few errors as possible. It also needs to be delivered as quickly as possible. If retransmissions, delay, or other errors do occur, users will notice because they will hear the the problem!
To provide the best audio quality possible, SIP.US 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 that it gets the SIP traffic from. Here is a graphic that demonstrates how SIP.US is different from many other VoIP providers.
Referencing what you've learned so far, consider this next example.
Example: If Bob calls Alice with SIP.US, Bob's firewall opens a connection with SIP.US for SIP traffic. It will also automatically open a connection with Alice's phone for RTP traffic after SIP.US 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 SIP.US. 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.
Direct Media Delivery
The way to ensure that audio connection is established in each call through SIP.US, 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?
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. The key takeaway is that UDP packets are not concerned with whether or not they were delivered.
Example: We could send you 1,000,000 UDP packets, and 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 those 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 only accept traffic from our gateways, there should be no danger of someone opening a false RTP session and your server trying to accept those packets.
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. The benefit to allowing media to come directly from dozens of sources which can be closer to the endpoints is responsive and crystal clear call quality.