Spent roughly two months playing around with provisioning and setting up polycom soundpoint IP320 and IP 430 polycom phones. My asterisk box has one SIP trunk and I simply wanted to get some use out of some fairly robust IP phones. The first problem I discovered was that I did not understand how tftp worked. The trivial ftp protocol albeit not at all secure is quite common means of provisioning or flashing the bootrom or SIP software on these phones. I suppose most people have moved onto FTP, HTTP or TLS provisioning.
Important points to consider when
To make matters worse, the Polycom phones while popular and admired for both quality and cost are not STUN aware.
I'll save the SIP registration problem for last.
I had read that provisioning Polycom phones was shall we say quite trivial.
So I had to make sure that I could administer the asterisk box remotely.
Of course ssh and screen works well for this purpose, as I needed to open up several
terminal windows to inspect traffic coming across port 69, the tftp default port.
The first challenge was actually setting up /tftpboot and running the tftpd correctly.
For some reason the inetd wrapper never worked as designed so I simply run the tftp daemon
as stand alone service. Opening up a terminal and as root typing -->
/usr/sbin/in.tftpd -l -s /tftpboot/ -vvvv Note the "l" for listen or stand alone instance not controlled by the inetd wrapper. If you try to run tftp daemon without the 'l' switch and without the inetd service it will fail. One other gotcha which is specific to Polycom and other phones which can be provisioned via Trivial ftp (yes I know tftp is not secure and most folks provision phones via FTP and perhaps TLS or http), you must specify /tftpboot directory. These phones expect the directory to be included in all tftp daemon statements. If you are using the inetd wrapper this work is already done for you.
I then decided to run tcpdump against the desired port to monitor the output of the connection. I later learned that I could simply direct the stdout to asterisk syslog.
Now let us get to the selection of Polycom bootrom and SIP software selection. I have found this exercise to be fraught with peril. The site is very confusing and not very well planned. Essentially, it is appears to be a spreadsheet with a few colors and hyperlinks. The legend is not very useful. The result is a web page that is circa '93. Not sure if anyone else experienced this problem, but I downloaded the incorrect SIP software and wasted countless hours on needless trouble shooting. If you want to test your mettle and attention to detail visit the Polycom download site yourself. I would recommend that they mistake proof the site with some parsing mechanism to make certain bootrom and SIP combinations impossible. At the very least some sort of selection hierarchy that is common on modern websites that allow you pick and select software or hardware components. Radio boxes or pull down menus work well. I think you get the idea. Select your IP phone model --> next pull down --> recommended stable bootrom --> next pull down recommended SIP software. Really very simple. Overall I believe Polycom to be a very good customer driven company, but their self-support software website is woefully outdated. They might as well be running a BBS :-)
Now onto the most interesting part of this exercise. The networking and effective understanding of what we'll call the double "NAT" conundrum. I was working with a consumer grade Netopia 3307 DSL Router which comes with 4-port switch. The router doesn't seem to handle SIP traffic very well at all. In a nutshell, the problem could be characterized as follows:: the Netopia router doesn't understand IP addresses embedded in SIP and SDP payloads. The only way to get this to work is to place some sort of sip proxy on the LAN to intercept the packets, rewrite them to maintain state about the SIP endpoints (ie remote Polycom phones) then dynamically create the necessary NAT rules to allow RTP packets to pass between the endpoints in a call. I learned about this fact while perusing #openwrt IRC. I owe a special thanks to <DIdaho> for the insight. For those of you who are not familiar with VoIP, RTP is what allows audio transport for both endpoints. If RTP isn't working the failure mode is that you will not hear any anyone speaking on the other end or vice versa.
Understand that Netopia has a set of tools that did enable "one" polycom phone to work. I used the IP Passthrough mode and it enable one endpoint to correctly register with the remote asterisk box. Of course this was less than optimal since the I have two SIP endpoints. So, I had to abandon IP Passthrough and figure out a better workaround.
I began looking for a solution to my dumb Netopia problem, so I immediately thought openwrt project. Luckily, I was able to cop a Linksys WRT54GL for $50 bucks. My theory was that I could learn how siproxd works and place the openwrt device on the network between my SIP endpoints and the remote asterisk box. However, I was on a time constraint and I had to get the problem resolved and leave the experimentation to a later time. I still have the the openwrt router and will use it to monitor connections on the LAN and perhaps install squid proxy. One day I might even try siproxyd.
So, I was able to get things working albeit not exactly my first preference.. I finally broke down and placed both the SIP endpoints and asterisk box on the same LAN. Voila, no more double NAT situation. No more need to punch holes in firewall to accept SIP and RTP packets. I then used the IP Mapping feature of the Netopia router which seems to work quite fine. In truth, I am still not entirely sure how it inspects inbound SIP and RTP packets. Perhaps that is less important now that iptables rules on the asterisk box can do the heavy lifting. The router is simply mapping a static IP address and the iptables rules on the asterisk box accept all the required traffic and drops all that is not desired.
Another added benefit is that I finally upgraded from Asterisk 1.4 to Asterisk 1.6 and hardened my CentOS box a bit more. If I get more time I'll share my experiences with openwrt..