Configuring a Cisco IP phone for VoIP using SIP – revisited

This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Cisco logoA 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 = sys.GetBindings()[0].ContactSIPURI
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.Trace = true
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 but event full gives an extremely verbose log.

22 thoughts on “Configuring a Cisco IP phone for VoIP using SIP – revisited

  1. I too have purchased a 7911g in the hopes of getting it working with sipgate, but sadly not only are sipsorcery registrations closed, I have no idea where to begin with regard to what to put into config files.

    Is it possible for you to post your configuration files (username and password excluded of course, but with the points hilited would be a bonus!) so that I might have some idea where to begin, and just hope and pray that sipsorcery opens their registrations again soon.

  2. @thelongmile – thanks for getting in touch – I’ll send the config files over by e-mail in due course but I’m sorry to say “it’s stopped working”. Both I and Garry Martin, who helped me set this up, are now finding that something has changed at SIPsorcery and we’re no longer able to remap the ports so that the response comes back on 5060 (or whatever port is selected).

    In short, that means that my 7940 still works well, but that 79×1 devices don’t :-(

  3. Hi There. I have this phone and I can not get it working. I reset it, and now it asks for the term11.default file. I have no idea what to do. Could you help?

  4. Tim,
    Your phone will continue to display ‘term11.default’ when it cannot read the correct ‘SEP{macaddress}.cnf.xml file in your tftp server directory. When that file is in place, it will look for the ‘ tag, which is where you specify your SIP file name that you want the phone to be looking for in your tftp root directory.
    Once is finds the correct .cnf.xml file and finds the correct SIP files to install, it will grab them and install your new files. One more thing to keep in mind: you may not be able to upgrade directly to the latest version of SIP from the version that you have installed. You may have to do it incrementally, jumping to say 8.3.x > 8.5.x > 9.2.x

    I hope this helps some.

    J

  5. Hi Mark,

    Have come across your article while looking to configure 5 shiny new (ok, from eBay) Cisco 7960G phones, but this lack of STUN support and the fact we won’t be able to configure inbound firewall forwarding sounds like it will be a complete non-starter via our sipgate which I use for the company comms…

    Thanks for most likely saving me from several hours of frustration trying to get a phone working which would most likely never have happened…

    Is yours still working or would you recommend something different to the Cisco?

    Jamie

  6. Hi Jamie,
    My 7940 is still working, although I use it a lot less these days. I tried to get a 7912 working but it was a lot harder (XML config), as is the 7941. So it is model-dependant but I think the 7960 should be OK (AFAIK, it’s just a 4-line version of the 7940).

    Mark

  7. Hi,
    I am new in voip and I really have trouble configuring my cisco ip phone 7911 for using sip. would you like to help me out step by step?

  8. Dear Mark,
    i have the this phone and saw what you are taking about, though wireshark, but could you please explain how i can use the outcoming/incoming dialplan you mentioned ?
    i just use SEP.cnf.xml to configure the phone
    my phone behind ADSL-modem with nat

    thanks alot
    Mahmoud

  9. by the way, regarding 7912, it’s very easy to configure with any sip server and also have good feature to me and that is configuring the phone from the web interface unlike 7911 the only way to configure it by sending the xml file

  10. Mahmoud, the dial plans I mentioned are (were?) a feature of SipSourcery. I haven’t looked at this for a while – I found it unreliable and stopped using the 7911. Sounds like you had better results with a 7912.

  11. that’s right i can easy register with any sip provider by 7912
    but i have another issue and that, after period of time of registration done between the 7912 and sip server, the phone become unreachble and i have to restart it again to be in active mode
    it looks like keep alive issue, i tryed to modify it but the phone have no option for that
    do you have any about that ?
    in my HTC-andriod for example i have an option to make the send keep alive “always send” that make my htc mobile in active mode all the time and therefore reachable

  12. Mark
    i found that the SIPRegInterval is set to 3600 as default, so i make it 60 secs instead and now the 7912 become always reachable for incoming calls

  13. are you suggesting placting RTCP (voip control port) within the range of start media port and end media port?

    (that doesn’t seem wise)

    7960G 8.12

  14. hello, nice article. You did mention TLS up there, have you actually managed to configure the 7940 using TLS? Or only with the 7911…

  15. Sorry George, no. It was a long time ago now and I only really had success with a 7940. Now everything I do is in Microsoft Teams so I don’t use the solution at all.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.