Thanks for the followup, Shawn.
I got ahead of myself in the pronouncement that STUN is the only way
for a SIP UA to function behind NAT. My bias was showing.
I'm not sure what is meant by "SIP pass-through support" below, but
I assume it is synonymous with an "application layer gateway" (ALG)
implemented in the router itself. The role of the ALG is to treat in
some exceptional way the traffic of a particular protocol (application).
If the protocol changes down the road, the ALG must in general be upgraded
to accomodate the change.
NAT is a hairball, and a nonstandards-based hairball, to be sure[1].
And NAT poses challenges not only to SIP, but potentially to any UDP-based
protocol. STUN provides a relatively simple way to deal with an already
challenging situation. It does not require application-aware logic in
the router beyond what is already implemented for routing and NAT itself.
Application-aware logic, no matter how clever or well-implemented, in
a home router throws up a red flag, especially from a customer support
perspective.
Most consumer NATs will support a single STUN-enabled SIP phone behind
NAT, and more than one phone if the user is willing to change SIP service
port numbers on the additional phones.
Of course, the user can manually open ports on the router to an IP client
(i.e., the SIP phone) behind the NAT. That solution is not consumer
friendly (grandma doesn't possess those skills), and generally won't
work for more than one phone.
Mark
[1] But it did create the home networking market where before there
was none --- and could be none without ARIN and public address space
management.
On 1Jul, Shawn Rogers wrote:
> 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]
> >
> >
--
Mark Petrovic
Pasadena, CA
[EMAIL PROTECTED]
