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]
