84
SIP Domain
- [only applies to
Registered
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 field is not populated, that is the default. If, for some
reason, the domain is different than the server/proxy address, then this field is used.
SIp troublEShootINg
In a nutshell, SIP establishes a communication 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 communication channel is terminated once the
handshaking is complete. Note that firewalls 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 matters is in how an audio channel gets established once the handshake channel
is defined. In the common sense world, the call would be initiated to the destination 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” field, and requires that a codec negotiating a call send
to that address only. This is important in the case of having an intermediate server. And this works fine as long as each
codec knows what its public IP address is.
outgoINg CAll ISSuES
A unit making an outgoing call must populate the ”return address” field. But any codec sitting 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.
192.168.x.x
style) address into that “return address” field. The called codec will dutifully attempt to connect to that
address and undoubtedly fail, since that can’t be reached from the Internet at large.
INCoMINg CAll ISSuES
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 firmware>. And since even the “forward address” is negotiated in SIP, the incoming unit is likely to
populate the “forward address” field with its private address as well.
SolutIoNS
Many times the “return address” field issue is fixed by the SIP server (in
Registered
mode) and no compensation
measures are necessary. Often, in fact, the server insists on acting as a “proxy” and handles all the traffic itself--outgoing
and incoming streams are relayed directly by the server, solving any router issues.
In point-to-point connections, this isn’t possible. All is not lost here, since we can find some hacks to make this work. The
first 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 Application Layer Gateway (ALG), then enabling this option can fix the issue.
Содержание Access NX
Страница 1: ...Product Manual ...
Страница 37: ...37 AUDIO INputs Settings with mixer Audio Output Settings with mixer ...