{"id":1815,"date":"2010-05-14T11:58:52","date_gmt":"2010-05-14T11:58:52","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/?p=1815"},"modified":"2013-03-15T08:05:37","modified_gmt":"2013-03-15T08:05:37","slug":"configuring-a-cisco-ip-phone-for-voip-using-sip-revisited","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2010\/05\/configuring-a-cisco-ip-phone-for-voip-using-sip-revisited.htm","title":{"rendered":"Configuring a Cisco IP phone for VoIP using SIP – revisited"},"content":{"rendered":"

\"CiscoA couple of years ago, I blogged about getting my Cisco 7940G IP Phone working with SIP firmware and an external VoIP provider<\/a> (in my case, it was Sipgate<\/a>).\u00a0 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<\/a> 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.<\/p>\n

Now, with the help of Garry Martin<\/a>, I’ve got the 7911G working.\u00a0 Hopefully the IP Communicator will follow soon but, for now, this post describes the steps I needed to take.<\/p>\n

Installing the SIP\u00a0firmware<\/h3>\n

Just as with the 7940, I needed to load the firmware using a TFTP server –\u00a0in 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\u00a0for the\u00a07911 and, once the phone located the server and found the term11.default.loads file, it pulled down the remaining firmware images and updated itself.<\/p>\n

Next up, I created two configuration files: XMLDefault.cnf.xml (note the case); and SEPmacaddress<\/em>.cnf.xml.\u00a0 Just as for the 7940’s SIPDefault.cnf and SIPmacaddress<\/em>.cnf, these configuration files provide default and device-specific settings respectively.<\/p>\n

The TFTP logs show the phone attempting to load some other files too (CTLSEPmacaddress<\/em>.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.<\/p>\n

The last file that the phone downloads is dialplan.xml.<\/p>\n

SIP Providers<\/h3>\n

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.\u00a0 This is where Garry helped me out – he’s already been through this with a 7965G\u00a0– 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.\u00a0 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<\/a>.<\/p>\n

In Garry’s testing with a few different providers, he found the SIP Proxy Voxalot<\/a> had a Web UI option for Symmetric NAT enable\/disable that allowed his 7965G to succesfully register, and both SIP Providers VoIPtalk<\/a> and Orbtalk<\/a> worked without modification. However Sipgate (like me, his main SIP provider) failed consistently.<\/p>\n

The workaround we used was to use another SIP Proxy (Sipsorcery<\/a>) 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<\/a>.\u00a0 My dialplan is called incoming<\/code> and it contains the following Ruby code:<\/p>\n

bindingURI = sys.GetBindings()[0].ContactSIPURI
\nbindingURI.Host = bindingURI.ToSIPEndPoint().SocketEndPoint.Address.ToString() + “:5060”
\nsys.Dial(bindingURI.ToString())<\/dirtycode><\/p>\n

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:<\/p>\n

sys.Trace = true
\nsys.Dial(“sipgate”)<\/dirtycode><\/p>\n

Where sipgate<\/code> is the name of the SIP Provider that I have registered on Sipsorcery.<\/p>\n

A few more things to know<\/h3>\n

Unlike my 7940G, the 7911G configuration needed to know about my external IP address for NAT purposes.\u00a0 Without\u00a0the <natAddress> parameter I could call out, but the phone didn’t ring for inbound calls and so I didn’t answer, meaning that\u00a0callers were redirected to my Sipgate voicemail.<\/p>\n

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:<\/p>\n

The control ports that are needed for SIP communications are:<\/p>\n