A couple of years ago, I blogged about getting my Cisco 7940G IP Phone working with SIP firmware and an external VoIP provider (in my case, it was Sipgate). I also wanted to get a couple more Cisco IP Phones working – the Cisco IP Communicator softphone and a 7911G for my wife’s business but, unlike the 7940 and 7960, these phones use a different configuration file format – an XML file that I’d never managed to get working properly.
Now, with the help of Garry Martin, I’ve got the 7911G working. Hopefully the IP Communicator will follow soon but, for now, this post describes the steps I needed to take.
Installing the SIP firmware
Just as with the 7940, I needed to load the firmware using a TFTP server – in my case it was a simple case of adding a few extra files to the existing server – I used v8.5.4 of Cisco’s SIP firmware for the 7911 and, once the phone located the server and found the term11.default.loads file, it pulled down the remaining firmware images and updated itself.
Next up, I created two configuration files: XMLDefault.cnf.xml (note the case); and SEPmacaddress.cnf.xml. Just as for the 7940’s SIPDefault.cnf and SIPmacaddress.cnf, these configuration files provide default and device-specific settings respectively.
The TFTP logs show the phone attempting to load some other files too (CTLSEPmacaddress.tlv, English_United_Kingdom\tc-sip.jar and English_United_Kingdom\g3-tones.xml) but the fact they don’t exist doesn’t seem to matter.
The last file that the phone downloads is dialplan.xml.
SIP Providers
I mentioned that, with my 7940G, I connect directly to Sipgate and I initially tried to do the same thing with the 7911G but it doesn’t work. This is where Garry helped me out – he’s already been through this with a 7965G – and he found that the newer Cisco IP phones will attempt to register using a high port number but expect a response on the configured VoIP Control Port. To make this work, they append the rport parameter on the VIA headers in SIP registration. This is RFC compliant but doesn’t take into account the symmetric network address translation (NAT) workarounds that some providers have in place to maximise device support.
In Garry’s testing with a few different providers, he found the SIP Proxy Voxalot had a Web UI option for Symmetric NAT enable/disable that allowed his 7965G to succesfully register, and both SIP Providers VoIPtalk and Orbtalk worked without modification. However Sipgate (like me, his main SIP provider) failed consistently.
The workaround we used was to use another SIP Proxy (Sipsorcery) to act as a broker between SIP providers (although, in my case I only use one provider). Working with Aaron (Sipsorcery creator and admin), two changes were put in place. The first was for Aaron to remove the troublesome rport parameter in the top VIA header for phones registering against Sipsorcery with a specific UserAgent. In Garry’s case the UserAgent string was “Cisco-CP7965G/8.5.3”, and in mine “Cisco-CP7911G/8.5.3”. The second change was to apply a dialplan on our accounts that modifies the bindings for SIP responses that use high port numbers. My dialplan is called incoming and it contains the following Ruby code:
bindingURI.Host = bindingURI.ToSIPEndPoint().SocketEndPoint.Address.ToString() + “:5060”
sys.Dial(bindingURI.ToString())
Once I’d made sure that my SIP account had appropriate incoming and outgoing dialplans, my registration authentication failures went away – for reference, the outgoing dialplan that I use contains:
sys.Dial(“sipgate”)
Where sipgate is the name of the SIP Provider that I have registered on Sipsorcery.
A few more things to know
Unlike my 7940G, the 7911G configuration needed to know about my external IP address for NAT purposes. Without the <natAddress> parameter I could call out, but the phone didn’t ring for inbound calls and so I didn’t answer, meaning that callers were redirected to my Sipgate voicemail.
At this point, my configuration should have been working but there were still some issues. Rather than embarrassing myself by pointing out my stupid firewall (mis)configuration issues, I’ll highlight some key facts:
The control ports that are needed for SIP communications are:
- SIP: TCP and UDP 5060.
- SIP-TLS: UDP 5061.
Some more ports are needed for the actual communications – these are called media ports (RTP/RTCP) and are configurable in the phone configuration files but both TCP and UDP ports are required, generally for Cisco products in the range 16384 to 32766. Two ports are required for each media stream – an even numbered port for RTP and the next higher odd numbered port for RTCP. So on a 2-line Cisco phone, you need 4 ports (say 16384-16387), and on a 6-line phone, you need 12 ports (say 16388-99).
If you use multiple phones, you’ll need to think about assigning different port numbers (e.g. 5062/3 for SIP) and using IP address reservations with appropriate IP filters set on your firewall. I haven’t done this yet – it could be the subject of a future post as I still need to get the 7940G and the 7911G working in tandem, once I’ve sorted out a second power supply, or some Power over Ethernet (PoE) for the handsets.
Remember that, just because you have selected a certain range for media on a given device, doesn’t mean that the remote party will use the same range so only set the destination port numbers in your inbound firewall rules, not the source port numbers (i.e. allow responses from any source port to be passed through to the appropriate destination media ports).
Finally, some tools that may help (if you don’t have a good friend who’s already gone through this, like I did!):
- Wireshark is great for seeing what the SIP/RTP conversations look like (e.g. SIP authorisation issues, one-way conversation streams, etc.).
- Sipsorcery has its own console and, not only can the
event *filter be used to trace proxy activities and interactions butevent fullgives an extremely verbose log.
Leave a Reply