For more details on how to resolve NAT-related audio issues, see our article on how to resolve one-way or no-way audio on VoIP calls. There are several techniques for allowing VoIP to function over NAT, including drastically reducing the RTP port range, using UDP Hole Punching or Session Traversal Utilities for NAT (STUN). You can easily configure the router to unblock the two SIP control ports and allow for call control to occur, but since the voice packets pick a random port from within a range of over 16,000 ports to use for each call, it would not be safe or proper to unblock the whole range and open up the network to potential attack. However, it can be terrible when trying to employ VoIP. This is perfectly fine, and is desirable in most cases. As is well known, NAT will block all transmissions from the Internet. This is especially true if one of the telephony endpoints is on one side of the NAT router and the other is on the other side, namely, the Internet. There may be many reasons why these ports would be blocked. The vast majority of one-way or no-way audio problems are a result of the blockage of RTP ports for the voice stream.
Having said that, it is quite clear that if the ports used by RTP are being blocked somewhere in the voice stream, but the SIP control ports are not, then calls can be set up and teared down successfully without any successful exchange of voice packets. The range of ports used by RTP for voice packets varies by manufacturer and is typically, although not always, from 16384 to 32767. In most implementations, the protocol that carries voice packets is the Real-time Transport Protocol (RTP), a protocol designed for real-time applications such as voice and video. Interestingly enough, SIP is only involved with call control that is, the signaling portion of a communication session and is not responsible for the transmission of voice packets. Consequently, call control packets are handled differently from voice packets and as a result, a call may go through all of the proper call control procedures flawlessly while the voice stream may encounter obstacles in one or both directions.Ĭall control for the Session Initiation Protocol (SIP) occurs using the TCP or UDP transport protocol on ports 50.
In a sense, call control occurs on a different “channel” from that of the voice packet exchange. It is important to remember that the call control procedures which include call setup and teardown, call routing, ringing, connecting, codec choices and other such processes are independent from the exchange of voice packets. Here we list four of the most common culprits of this issue and suggestions for how to tackle them. This is a scenario that comes up a lot on our tech support calls at TeleDynamics. It seems counterintuitive that the transmission of voice packets could be unsuccessful if the call was successfully set up. It may be difficult to understand why this happens, especially since the phone does ring, both physically for the called party and via the ring-back tone for the calling party.
This is the classic case of one-way or no-way audio, where a voice call is successfully completed, but either the voice packets only successfully travel in one direction, or neither end successfully receives voice packets. Or, it may be that neither party can hear the other and there is just silence on the line. If you deal with Voice over IP (VoIP), you must have come across this scenario at one time or another: A user complains that when they answer their phone, the caller can’t hear them, even though they can hear the calling party.
0 kommentar(er)
