49
Challenges with SIP/RTP
To summarize the previous sections, most VoIP connections involve a continuously active SIP channel initiated from the user
device to a service provider over port UDP 5060. Using this channel, the two ends negotiate calls and create and destroy RTP
sessions (each consisting of one RTP and one RTCP) in each direction. Like the SIP channel, these sessions also run between
the end-user and provider, so the provider can bridge them to the legacy phone network. The SIP channel also negotiates
which encoders will be used on the RTP channels.
So what can possibly go wrong? Almost every issue can be run down to NAT-based routers or blocking firewalls.
Issues with the SIP channel
The SIP channel generally has the fewest issues, since it’s usually originated from the user end of the link. This means NAT
routers on the user end will generally allow this outgoing traffic to pass, and allow the response traffic (from the provider) back
in. But if a network is heavily firewalled in a way that blocks outgoing access to UDP 5060, this channel will never be created
and the user cannot register with the provider.
Also, although we have described the SIP connection as “always active”, there are periods of inactivity on the link when no
calls are being set up or ended. In order to receive information about new incoming calls from the provider, the user end must
keep the SIP connection (or “binding”) open through the NAT router to prevent it from terminating the binding and blocking
incoming traffic. It does this by sending periodic updates even when no changes are being made to any calls. The interval
of these updates is usually adjustable, but must be shorter than the timeout value the router takes to shut down any unused
bindings.
Where am I?
According to the SIP standard, the user device will inform the provider of its IP address (over the SIP signaling connection),
and the provider will “push” the RTP session containing the incoming voice to that address. But devices on LANs often don’t
know what their “public” address is, only the private one assigned to them on the LAN. If the provider tries to initiate a stream
to that address, it will go nowhere.
Many VoIP providers install a “cheat” here that will look at the user’s IP address and determine if it looks “private”. If so, they
will ignore it and send the RTP stream to the destination address of the RTP session they receive.
If the cheat isn’t implemented, user devices have a way of looking up their public IP address via a protocol called STUN. This
protocol can usually be enabled within the user’s equipment configuration. If enabled, the device will look to a STUN server
out on the public Internet, and query its own address. It will then use that public address to populate the “from” field in the
SIP handshake.
Summary of Contents for VH2
Page 1: ...Product Manual ...
