asterisk users - Nov 2003 - NAT router and off-premise SIP audio problem

Our network is connected to a cablemodem using a dynamic DNS service to
resolve our address. The Asterisk server has been alternately set up behind
a NAT router and without a NAT router -- that is, with two NICs, one of
which is providing NAT to the rest of the network; the office SIPs are
behind that with static private IP addresses.

Off-premise SIPs are all behind simple NAT routers.

Off-premise SIPs have been able to receive calls from and make calls through
the PSTN. No problem. Calls between on-premise SIPs, not a problem. Calls
between off-premise SIPs and any other SIPs connected to the server are a
problem... they ring up but no audio is passed in either direction.

SIP.CONF has NAT=YES.

We presume that a dedicated IP address for the Asterisk server would resolve
this but we would like to avoid the extra expense.

What are we missing? TIA.

Jim Greenfield
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20031101/38651532/attachment.htm

Jim Greenfield, Computer Troubleshooters Metro NY/NJ wrote:
> Our network is connected to a cablemodem using a dynamic DNS service 
> to resolve our address. The Asterisk server has been alternately set 
> up behind a NAT router and without a NAT router -- that is, with two 
> NICs, one of which is providing NAT to the rest of the network; the 
> office SIPs are behind that with static private IP addresses.
>
> Off-premise SIPs are all behind simple NAT routers.
>
> Off-premise SIPs have been able to receive calls from and make calls 
> through the PSTN. No problem. Calls between on-premise SIPs, not a 
> problem. Calls between off-premise SIPs and any other SIPs connected 
> to the server are a problem... they ring up but no audio is passed in 
> either direction.
>
> SIP.CONF has NAT=YES.
>
> We presume that a dedicated IP address for the Asterisk server would 
> resolve this but we would like to avoid the extra expense.
>
> What are we missing? TIA.
>
> Jim Greenfield
>
Try adding canreinvite=no in the config of the remote phones.. This will 
force the audio path through Asterisk..

Also I would suggest that you NOT put the Asterisk server behind NAT..

Jim,
> Off-premise SIPs are all behind simple NAT routers.
> 
> Off-premise SIPs have been able to receive calls from and make calls 
> through the PSTN. No problem. Calls between on-premise SIPs, not a problem.
> Calls between off-premise SIPs and any other SIPs connected to the server 
> are a problem... they ring up but no audio is passed in either direction.
> 
> SIP.CONF has NAT=YES.
> 
> We presume that a dedicated IP address for the Asterisk server would
resolve
> this but we would like to avoid the extra
> expense.
> 
> What are we missing? TIA.
It's the same problem that lots of others have posted about for months,
and basically relates to not understanding the sip protocol during call
setup. From a 10,000 foot view, here's what happens during call setup:
 1. sip phone A dials sip phone B (communicates with * on udp 5060)
 2. asterisk tells phone A to contact B directly (on udp 5060) and phone
    A does that (works since phone A is behind the nat box and is allowed
    the outbound dataflow)
 3. phone A and phone B negotiate to establish the RTP channel (on some 
    other udp port that is "dependent" upon the phone manufacturer)
 4. phone A is allowed to communicate on that RTP port through the 
    outbound nat box.
 5. phone B is "not" allowed to pass inbound through the nat box on
the
    choosen RTP port (since RTP is used for voice, it fails).

That last step is the problem.

You only have three choices today to fix the RTP problem in your case:
 1. use the canreinvite=no statement on the phone definitions in
    sip.conf (which then forces "all" RTP sessions to pass through
    the asterisk box, increasing the processor workload of the box), or,
 2. map each of the internal sip phones to a real registered IP address
    on the outside of the nat box. (Cheap nat boxes usually don't have
    this capability, however more expensive routers and firewalls do.)
 3. replace the nat boxes with the VPN equivalents, and use the VPN
    tunneling to force the external phones to appear on the inside of
    your asterisk network.

In those cases where there is only a single sip phone behind the nat
box (and assuming a cheap nat box), one can change the RTP port range
on some sip phones to some small specific set of udp ports, and then
map those udp ports in the nat box to the individual internal sip phone.
On the Cisco 7960 phones, the RTP port range can be set via Settings,
SIP Config, item 16 (Start Media Port) and item 17 (End Media Port).
One udp port will be required for each simultanous conversation supported
by the sip phone, therefore on a six-line phone using a udp port range
with at least six ports should work just fine.

Also note that not all nat boxes work the same. Some vendors include
special functions (and their marketing people exclude that technical
detail in their published data), while others boxes are just plain
dumb nat boxes.

The only realistic way to see what is going on is to use a packet
sniffer (like ethereal) to actually observe what the phone and nat
box is really doing.

Some working nat config's are just now beginning to get documented
at the http://www.voip-info.org site.

Look at RTP (/etc/asterisk/rtp.conf) packets, and its firewall
configuration.
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20031101/2328f381/attachment.htm

Hi All,

Is it possible to show which line a call has come in on in *.

My scenario is 8 incoming lines, 6 lines are trunked to one number and the
other 2 are individual lines.

I would like to pass the trunked lines to one set of extensions, and the
other lines to two other set of extensions.

Also with the outgoing calls I would like to send the call out on the
correct line for the extension group.

I need to get this clear in my head before I go to a friend of mine who is
looking for a new switch and tell him that * can do the job.

The total system for a start will consist of, 8 PSTN (analogue lines and 25
extensions, with the possibility of expansion for remote SIP phones
globally).


Thanks in anticipation for any advice/recommendations.


Dave

PS. This may appear again as it was held for moderation as I had a picture
attached.