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

Rich, thank you for your informative reply. I checked with our admin and he
replied:

"I setup from the start "nat=yes" and "canreinvite=no"
on sip phones from
Internet and modified the rtp channels (voice ports) and the rtp
port on the phones. Still have the same problem, no sound."

Perhaps the VPN solution is something we should try but this is more
limiting than we had wanted... the concept that we could simply attach a SIP
phone to a high speed internet connection anywhere, anytime (such as at a
hotel when traveling) and become one with our office was a compelling one.




-----Original Message-----
From: asterisk-users-admin@lists.digium.com
[mailto:asterisk-users-admin@lists.digium.com]On Behalf Of Rich Adamson
Sent: Saturday, November 01, 2003 8:53 AM
To: asterisk-users@lists.digium.com
Subject: Re: [Asterisk-Users] NAT router and off-premise SIP audio
problem


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.



_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users

> Rich, thank you for your informative reply. I checked with our admin and he
> replied:
> 
> "I setup from the start "nat=yes" and
"canreinvite=no" on sip phones from
> Internet and modified the rtp channels (voice ports) and the rtp
> port on the phones. Still have the same problem, no sound."
> 
> Perhaps the VPN solution is something we should try but this is more
> limiting than we had wanted... the concept that we could simply attach a
SIP
> phone to a high speed internet connection anywhere, anytime (such as at a
> hotel when traveling) and become one with our office was a compelling one.
As I've mentioned several times on the asterisk list, there is no shortcut
to understanding how the sip protocol works and how nat/firewall boxes 
impact the sip protocol. Trail & error guessing at parameters only ends 
in frustration. Packet sniffers are often times required.

There are plenty of people that have it working, but each implementation
has some specific vendor-dependent or software-dependent elements to it
that relates to the exact sip phone being used and the exact nat functions
implemented within a vendor's nat/firewall box.

Having worked as a network consultant (eg, protocol analysis, performance
and security) for ten years with corporations in 40+ states, your objective
to make sip connections work anywhere will only happen in "maybe" 10%
to
20% of the locations visited.  The issue is truly one of the sip protocol
embedding network addressing information within the upper layers, and most
firewalls and nat boxes don't look past layer three/four. Therefore, to 
make it work requires tweaking of the nat/firewall box (which obviously the 
hotels and customer accounts won't let you do), tweaking of the phone RTP 
port range (in some cases), and tweaking of the asterisk parameters for 
specific implementation needs. (Note: STUN won't even help in the majority
of cases.)

For those hotels that I've stayed at that offer the $10.95 Internet access
specials, add a few more variations to the dozens of nat implementations. 
The few that I've used require yet another html authorization mechanism 
that's not likely to appear in sip phones anytime soon.

Someone on this list suggested there are two types of nat/firewalls on the
market. That might be true from a 10,000 foot engineering/design perspective,
but there are dozen's of different real nat implementations in commonly-
available off-the-shelf boxes, each with there own special needs.

For those folks that have asterisk on a registered Internet address, there
are many implementations of remote Internet sip phones working from behind
a nat/firewall box.  (As one example, we have a 7960, a PC with Xlite, and
a Dell wireless PDA with Xlite working from behind a single Linksys wireless 
firewall box just fine. All three can call, be called, and call between 
each other. The asterisk box is at a distant location using a registered IP 
address. If we would swap that cheap Linksys box for another vendor's box,
we would likely have to revisit all the parameters again just because of
variations in how that next vendor implemented nat.)

If asterisk is behind a nat/firewall box, and the remote sip phones are on
registered Internet IP addresses, the choice of parameters becomes a little
more difficult. If asterisk AND the sip phones are behind individual nat or
firewall boxes, the parameter selections become rather intense and require
someone sniffing actual packets to diagnose configuration issues in most
cases.

Since we support a number of corporate clients and ISP operations, we have
carried a sip phone around just like you want to. However, we generally have 
access to their registered addresses, nat boxes, etc, and can tailor the 
phone and other assets to what's needed to make them work.