Manual
90
- Only applies to mode. This is the name of the network controlled by the SIP
server. This parameter must be passed by the codec to the server. Under most circumstances, this is
the same as the server/proxy address, and if this eld is not populated, that is the default. If, for some
reason, the domain is dierent than the server/proxy address, then this eld is used.
In a nutshell, SIP establishes a communicaon channel from the calling device to the called device (or server) on port
5060. All handshaking takes place over this channel, and a separate pair of channels is opened between the devices: one
to handle the audio; and the other to handle call control. The original communicaon channel is terminated once the
handshaking is complete. Note that rewalls must have all three ports open to allow calls to be established correctly.
Also, port forwarding may be required to accept calls if your codec is behind a router.
The main area where SIP complicates maers is in how an audio channel gets established once the handshake channel
is dened. In the common-sense world, the call would be iniated to the desnaon IP address, then the called codec
would extract the source IP address from the incoming data, and return a channel to that address. In fact, that’s how the
default mode of Comrex codecs work, and it works well.
But SIP includes a separate “forward address” or “return address” eld, and requires that a codec negoang a call send
to that address only. This is important in the case of having an intermediate server. And this works ne as long as each
codec knows what its public IP address is.
A unit making an outgoing call must populate the ”return address” eld. But any codec sing behind a router has
a private IP address, and has no idea what the public address is. So, naturally, it will put its private IP address (e.g.
style) address into that “return address” eld. The called codec will dufully aempt to connect to that
address and undoubtedly fail, since that can’t be reached from the Internet at large.
Incoming calls to codecs behind routers are complicated by the fact that ports on the router must be forwarded to the
codec. In the case of SIP, this must be three discrete ports (For Comrex codecs these are UDP 5060, 5014 and 5015)
<6014 and 6015 with 3.0 rmware>. And since even the “forward address” is negoated in SIP, the incoming unit is likely
to populate the “forward address” eld with its private address as well.
Many mes the “return address” eld issue is xed by the SIP server (in mode) and no compensaon
measures are necessary. Oen, in fact, the server insists on acng as a “proxy” and handles all the trac itself—outgoing
and incoming streams are relayed directly by the server, solving any router issues.
In point-to-point connecons, this isn’t possible. All is not lost here, since we can nd some hacks to make this work. The
rst place to look is your router, since many modern routers are aware of this issue and have taken steps to relieve the
pain. If your router supports a SIP Applicaon Layer Gateway (ALG), then enabling this opon can x the issue.