Manual

Technically, as shown above, a SIP client opens one channel to its host when it registers. This channel is kept open
indefinitely, and uses the TCP transport layer for reliability.
This channel is used by the SIP client to request an outgoing call, as well as by the SIP host to notify the client of
incoming calls. The channel is initiated from the client and kept open with keep-alive data so it doesn’t have any
issue when running through routers that incorporate Network Address Translation (NAT).
This signalling channel doesn’t actually carry any voice data, the voice data channel is created separately over
distinctly different “ports” on the client, using a protocol called RTP.
NAT Router issues with SIP
The issues with a SIP client (like EarShot IFB) behind a NAT router are twofold:
1 When SIP clients (like EarShot IFB) are behind NAT routers, they don’t know their public IP address.
The client only knows the private LAN (e.g. 192.168.x.x) address, but not the public IP used by the
NAT router on the Internet. During the negotiation process, the client provides information on how
other devices can reach it directly. But this information is flawed, since the LAN address is useless
to devices outside the LAN.
2 NAT routers don’t know what to do with unsolicited incoming RTP streams. The RTP and
RTCP channels that are created as a result of the negotiation over the registration channel for
incoming calls are aimed at the router’s public IP address and are targeted to temporary or
“ephemeral” ports that are chosen during that negotiation.
Issue #1 is usually resolved when using a reputable SIP provider, as they will have the smarts to substitute your
public IP address for your private one during the negotiation process.
Note that even when this issue is resolved, the second issue remains - the streams created to the proper address
will “bounce” off the router, because the router has no idea where to send them.
29