Hello, I forwarded your message to the product manager for the P2000W.
Here is his reply:
Shawn,
NAT is not friendly to SIP.
There are many way used in the field to make SIP
Pass-through NAT.
The 3 major technic used are listed below
The VoIP challenge
SIP is a session initiation protocol which is an application-layer
control (signaling) protocol for creating, modifying, and terminating
sessions with one or more participants. These sessions include Internet
telephone calls, multimedia distribution, and multimedia conferences.
For SIP to successfully massively deploy there are several challenge of
the real environment it must able to work with. The most common faced
problem is NAT pass-through issue and SIP client and call server
interoperability issues.
When SIP protocol is proposed it self does not consider network
environment and other technology that maybe in the deployed network.
Since IPv4 IP is insufficient and will soon run out. Thus NAT is very
commonly used. Unfortunately from field test many vendor's NAT are not
SIP friendly.
Fortunately, there are already ways to workaround the NAT for SIP. The
most commonly used way is listed below.
SIP pass-through support on NAT router (require router vendor
implement it).
STUN.
Outbound Proxy.
There are advantage and disadvantage of each technology.
For example SIP pass-through on NAT router this requires router vendor
implementation. From carrier point of view this does not seem feasible
as not every NAT router vendor implement this on their router and they
do not have control of which router their customer is using.
STUN is a simple traversal of user datagram protocol. It helps to
traverse UDP through NAT. STUN allows applications to discover the
presence and type of NATs between the host and public Internet. It also
provides the ability for application to determine the public IP
allocated to the host by NAT. STUN works with many
Existing NATs, and does not require special handling from NAT router.
As a result it can make SIP pass-through NAT. Please refer to RFC 3489
for more details.
The outbound proxy is a normal SIP proxy. You configure your client, the
phone or software, to use the proxy for all SIP sessions, just like when
you configure your Web browser to use a Web proxy for all Web
transactions. In some cases, the outbound proxy is placed alongside the
firewall and is the only way to let SIP traffic pass from the internal
network to the Internet. For more detail you can refer to RFC 3261 for
details.
This is the way ZyXEL currently supports SIP. At some point, I expect
we will migrate over to STUN.
Phil
Thank you,
Phil Thompson
Product Manager
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark S. Petrovic
> Sent: Saturday, June 26, 2004 6:12 PM
> To: [EMAIL PROTECTED]
> Subject: [SOCALWUG] Zyxel Wi-Fi phone
>
> I saw on the dailywireless.org site mention of the Zyxel
> Wi-Fi SIP phone.
> I'm very much looking forward to more products like this coming on
> the market.
>
> http://www.zyxel.com/product/P2000W.html
>
> SIP, of course, is the protocol that makes VoIP truly accessible to
> millions of developers world wide. SIP is not simple - despite what
> looking at a few SIP messages might lead one to believe - but it is
> sufficiently simple that inexpensive IP phones can use it in
> conjunction
> with open source (read free) SIP registrars and proxies (e.g., SIP
> Express Router at http://www.iptel.org/products).
>
> Because of SIP, and proprietary apps like Skype, the next few
> years will
> bring fascinating changes to telecommunications - or at least what we
> used to call telecommunications. Pulver's Free World Dial
> come to mind
> as an example of the coming change:
>
> http://www.fwd.pulver.com/
>
> However, based on a reading of the Zyxel user guide, one problem this
> phone does not appear to address is that of network address
> translation
> (NAT). If the phone operates behind a NAT, which is quite
> likely, it must
> be able to receive inbound SIP Invites from a proxy on a
> public address.
>
> STUN (RFC 3489),
>
> http://www.ietf.org/rfc/rfc3489.txt?number=3489
>
> is a simple protocol that gives something like a SIP phone a fighting
> chance to register a public address in the SIP registrar, the latter
> of which ultimately proxies inbound calls to the phone -- which has a
> private LAN address behind the NAT. Unfortunately, NAT is implemented
> in an amazing abundance of ways, as there is no standard
> implementation
> guideline. Consequently, a STUN client on the phone will do
> its best to
> ascertain what the NAT's public address is, but for some
> obsessive NATs
> ("symmetric" NAT), STUN is of no use. Fortunately, there are very few
> symmetric consumer grade NATs on the market.
>
> The STUN client would run prior to SIP registration. The SIP "client"
> on the phone will then register to its service provider's proxy with
> the NAT's public address, and periodically re-register to keep the UDP
> (SIP signalling is typically UDP) pinhole open on the NAT. When a
> call for the user triggers a SIP Invite message inbound to the phone,
> the pinhole is ready and open and the Invite is forwarded to
> the private
> address on phone where it is consumed by the SIP "server" or
> the phone,
> which ultimately causes the phone to ring. Quotations are
> used because
> SIP phones act alternately as clients and servers, depending
> on whether
> they are, simplistically, making or receiving calls.
>
> This is all a long-winded way of saying that if this phone does not
> support something like STUN, it cannot run behind NAT with a *very*
> helpful proxy (I won't go there).
>
> Does anyone have experience with this phone? Does it support NAT
> traversal via something like STUN, despite an apparent absence of a
> discussion in the manual?
>
>
> -Mark
>
> --
> Mark Petrovic
> Pasadena, CA
> [EMAIL PROTECTED]
>
>
