Configuring a Cisco IP phone for VoIP using SIP – revisited

Posted on By Mark Wilson
This content is 15 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.

Microsoft Unified Communications: part 4 (a brief note on Cisco, QoS and codecs)

Posted on By Mark Wilson
This content is 16 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.

As might be expected for a series of blog posts about the Microsoft view of Unified Communications (UC), it is heavily biased towards Microsoft products but I wanted to take a brief look at another major player in the unified communications space – Cisco. It should be said that I have very limited experience of Cisco’s UC offerings (only as an end user of their IP telephony products) but it’s worth highlighting the differences between the Microsoft and Cisco approaches.

Microsoft and Cisco are partners, but they are also competitors. Some googling suggests that Cisco and Microsoft’s VoIP products can be integrated but not always without challenges (Aaron Tiensivu’s post on integrating Microsoft Exchange and Cisco CallManager is just one example of such a challenge) but it should be considered that they have come to UC from different directions.

Cisco are a networking company and they have approached UC as a networking problem for which there is a networking solution. On the other hand, Microsoft are a software company – they have looked at the overall user experience an attempted to engineer a software solution.

Whilst Cisco concentrates on providing a VoIP solution that offers Quality of Service (QoS) and has grown out of PBX technology, Microsoft relies on codecs that are tolerant of poor network conditions to deliver what they refer to as Quality of Experience (QoE). Those with far more experience than I have commented that the Microsoft approach is sensible for calls that are routed across the Internet (where there is no QoS) but less so in an enterprise environment and Ed Horley made a very valid observation that network links, particularly WAN links, tend to be under-provisioned. I have to say that using the SCCP/UCM solution at work provides fantastic call quality but I also find that the Cisco IP Phone (running SIP) on my desk at home provides a great experience too and, at a recent event, Microsoft even compared their solution with Skype, citing this as a well-known example of a software solution that provides good call quality over variable consumer Internet connections (something which I was surprised to find when I was using Skype for a video call between the UK and Australia recently).

Microsoft’s general recommendation is to let the software select an appropriate codec and Office Communicator will constantly assess the available bandwidth and select an appropriate codec, even switching codecs and/or tuning parameters as required during a call.

The main concern is with voice traffic saturating network bandwidth at the expense of data – that’s where QoS can be used effectively – to manage the network.

In the final post in this series, I’ll wrap things up with some notes from my own OCS implementation last year.

Customising a Cisco 79xx IP Phone: directory services

Posted on By Mark Wilson
This content is 16 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.

I’m still working on customising the the Cisco 7940 I use with SIP firmware for VoIP calls and one of the items that’s now working well is the directory services functionality.

At the most basic level, the directory_url directive may be set in one of the SIP configuration files (either SIPDefault.cnf or SIPmacaddress.cnf), for example:

directory_url: ”http://webserver/directory.xml”

The contents of the directory.xml file are actually quite simple:

<CiscoIPPhoneDirectory>
  <Title>IP Telephony Directory</Title>
  <Prompt>People reachable via VoIP</Prompt>
  <DirectoryEntry>
    <Name>Bob</Name>
    <Telephone>1234</Telephone>
  </DirectoryEntry>
  <DirectoryEntry>
    <Name>Joe</Name>
    <Telephone>1357</Telephone>
  </DirectoryEntry>
  <DirectoryEntry>
    <Name>Operator</Name>
    <Telephone>0</Telephone>
  </DirectoryEntry>
</CiscoIPPhoneDirectory>

The trouble with this is that it’s just a static file. If I have a large directory, then I need to keep it up-to-date. That’s where a directory service comes into play. The Open 79xx XML Directory looks useful but it’s another application to install and manage on my infrastructure. I already have a directory (Microsoft Active Directory), so I thought it would be great if a piece of code could query the AD and output the file in a format that the 7940 understands.

Luckily I found such a piece of code, courtesy of a message posted to the Asterisk Users forum back in 2004 by Jeff Gustafson:

<?php
$ds=ldap_connect("ldapserver");  // must be a valid LDAP server!

if ($ds) {
  $r=ldap_bind($ds);  // this is an "anonymous" bind, typically read-only access

  $sr=ldap_search($ds, "ou=People,dc=domainname,dc=com",
"telephoneNumber=*");
  echo "<CiscoIPPhoneDirectory>\n";
  echo "<Title>IP Telephony Directory</Title>\n";
  echo "<Prompt>People reachable via VoIP</Prompt>\n";

  $info = ldap_get_entries($ds, $sr);

  for ($i=0; $i<$info["count"]; $i++) {
    echo "<DirectoryEntry>\n";
    echo "<Name>" . $info[$i]["cn"][0] . "</Name>\n";
    echo "<Telephone>" . $info[$i]["telephonenumber"][0] .
"</Telephone>\n";
    echo "</DirectoryEntry>\n";
  }

  echo "</CiscoIPPhoneDirectory>";
  ldap_close($ds);

} else {
  echo "error";
}
?>

Jeff’s code is great (my PHP skills are certainly not good enough to have written this myself) but Active Directory has an attribute for IP phone numbers (ipPhone), so I made a couple of edits to change the phone prompts and to make the LDAP query search on the ipPhone attribute:

<?php
$ds=ldap_connect("domaincontroller.domainname.tld");  // must be a valid LDAP server!

if ($ds) {
  $r=ldap_bind($ds); // this is an "anonymous" bind, typically read-only access

  $sr=ldap_search($ds, "ou=directorycontainer,dc=domainname,dc=tld",
"ipphone=*");
  echo "<CiscoIPPhoneDirectory>\n";
  echo "<Title>IP Telephony Directory</Title>\n";
  echo "<Prompt>Active Directory Users</Prompt>\n";

  $info = ldap_get_entries($ds, $sr);

  for ($i=0; $i<$info["count"]; $i++) {
    echo "<DirectoryEntry>\n";
    echo "<Name>" . $info[$i]["displayname"][0] . "</Name>\n";
    echo "<Telephone>" . $info[$i]["ipphone"][0] .
"</Telephone>\n";
    echo "</DirectoryEntry>\n";
  }

  echo "</CiscoIPPhoneDirectory>";
  ldap_close($ds);

} else {
  echo "error";
}
?>

I still needed a couple of tweaks to get this working though – not to the script, just to: the webserver I used to serve it; to Active Directory; and finally to the phone configuration.

First up, you need a web server with PHP installed (I used PHP 5.2.6 on IIS 6.0). This also needs the LDAP extension to be enabled by uncommenting extension=php_ldap.dll in php.ini. The extensions folder (e.g. C:\phpinstallationfolder\extensionfolder) also needs to be appended to the %path% system variable.

The script is actually for a generic LDAP directory (nothing wrong with that) but recent versions of Active Directory do not allow anonymous access by default. Daniel Petri has a detailed article on anonymous LDAP operations in Windows 2003 AD and that gave me the information that I needed to open up the parts of the directory that I wanted the script to read – basically: setting the 7th bit of the dsHeuristics flag on CN=Directory Service,CN=Windows NT,CN=Services,DC=domainname,DC=tld to 2 on the forest root domain; waiting for replication to complete; granting ANONYMOUS LOGON read access on the appropriate objects and List Contents access on the OU that contains the object(s). Alternatively, it should be possible to edit the script to use an authenticated logon (and sorting by surname wouldn’t go amiss either) but it’s getting late now and that will have to wait for another day! In the meantime, Geoff Jacobs’ post on creating a personal directory for the Linksys SPA942 using LDAP should provide some inspiration.

Last, but by no means least, the directory_url directive needs to be edited to reflect the name of the PHP script instead of the original static XML, for example:

directory_url: ”http://webserver/directory.php”

In order to pick up the changes, the phone will need a reset.

Now, when I access the external directory from the phone using the directory button and option 5, I’m presented with a list of contacts from Active Directory. Furthermore, because the web server uses dynamic content, the details are as current as the directory server that it refers to.

Customising a Cisco 79xx IP Phone: Ringtones

Posted on By Mark Wilson
This content is 16 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.

In my recent post on configuring a Cisco IP phone for VoIP using SIP, the RINGLIST.DAT file pointed to a file called CTU.raw – a custom ringtone for my phone. I hadn’t realised at the time but CTU is something to do with the TV series “24” and had been passed over to me with the rest of the configuration files that I used for reference. If you want to generate your own ringtones it’s quite simple but beware – there is not room for anything more than a few seconds.

I followed Jozef Janitor’s advice to create a custom ringtone, using the SoX Wrap to generate a .RAW file from an .MP3 on my Mac (I can handle the command line but SoX Wrap is also an easy way to get sox into Mac OS X). If you don’t use a Mac then Leigh Harrison offers some alternatives in his blog post on the subject and Josef’s advice suggests some others. Unfortunately though, even after truncated the file to 16KB using dd it was too long and when I tried to select it the phone displayed Custom Ring Unavailable!. Chopping it down to 15 bytes seemed to work but that left a very short clip indeed (about 2 seconds).

If you’re after a good source of pre-recorded tones, then try The Caretakers’ Website or here. I found that, including the two built-in tones, my 7940 only offered a choice of 50 tones.

Incidentally, RINGLIST.DAT is one supported file format but you can also use an XML file (as described in the Cisco Call Manager documentation for custom phone rings).

If your IP phone is in a work environment, the chances are that the administrators won’t let you add your ring tones to the system. Logan Ingalls found a workaround by using his own TFTP server but I have to warn you that they probably won’t like that either!

Useful things to know about Cisco IP Phone software

Posted on By Mark Wilson
This content is 16 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.

Whilst configuring my Cisco 7940 IP phone it’s been necessary to reset it a few times to load new configuration details. I started out by removing the power (pretty brutal, but effective), until I reached a point where I could telnet into the phone and issue a reset command.

Then I learned the reset codes for Cisco IP phones:

  • For SIP firmware, press *+6+settings
  • For SCCP firmware, key in **#**.

Note that these are soft resets (like Ctrl+Alt+Del on a PC) – they do not return the phone to factory settings.

Finally, it may be useful to know that the default password for the phones is cisco.

Configuring a Cisco IP phone for VoIP using SIP

Posted on By Mark Wilson
This content is 16 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 logoOne of my projects at home has involved trying to get a variety of telephony systems to work together so that I can make voice over IP (VoIP) or plain old telephone service (POTS) as necessary to get the best call rates. In truth, it’s probably not about getting the best rates as our phone bill is already pretty small – maybe it’s just because the geek inside me wants to get an IP phone working on my desk… anyway, I still have a few pieces of the puzzle to fit in place but last week I had a major breakthrough in getting a Cisco IP phone to provide a voice over IP (VoIP) service using SIP. It was a long haul, but worth it in the end – and this is how it’s done…

Cisco IP Phone 7940GFirst of all I needed an IP Phone. I managed to pick up a brand new 7940G for £50 on eBay (a bargain) and this was perfect for me. Why a Cisco phone? Partly because we use them at work (so I know they are good phones – and I like the form factor – although I wish it had a backlit screen) but mostly because there are so many of them about – that means that plenty of people have tried to do this and there is information available on the web. Using a Cisco phone does cause a couple of problems though:

  1. The standard protocol used for VoIP is session initiation protocol (SIP) and Cisco IP phones don’t use SIP natively. Cisco has it’s own IP Telephony system (Call Manager) which uses SCCP; however they do provide SIP firmware for their 79xx IP phones.
  2. Some of the Cisco documentation and software is only available with a service contract and generating configuration details can be a challenge if you don’t have access to a Cisco Call Manager solution – thankfully everything I used for this is available on the ‘net through a variety of websites that are aimed at getting people up and running with VoIP solutions.

It’s also worth knowing that there are two types of configuration file for Cisco IP Phones:

  • The 79x0 models use a fairly simple configuration file.
  • The 79x1 models use an XML configuration, which is all very well if you have access to a Cisco Call Manager solution but not so well documented if you don’t.

I found that the 7940 is a good model to go for as it has been around for a while, there is plenty of information available, and it can be picked up for a reasonably low price (and it helped to know that one of my colleagues already had this solution working well for him!). The 7960 is similar but with support for more lines and there are other models available (e.g. cordless phones, or phones with colour screens). In addition, Linksys (owned by Cisco) sells some similar phones that do run SIP natively but I don’t know if they use the same firmware.

After choosing the phone there were a couple of other considerations:

With the phone powered on and able to download a configuration, I uploaded the necessary configuration files to the TFTP server. Cisco Document ID: 5455 – Converting a Cisco 7940/7960 CallManager Phone to a SIP Phone and the Reverse Process gives details of the required files but the main ones to know are:

  • OS79XX.TXT – tells the phone which firmware to use.
  • SIPDefault.cnf – configuration information relevant to all phones.
  • SIPmacaddress.cnf – configuration information relevant to a specific phones.

Other files that I have include:

  • RINGLIST.DAT – Lists audio files that provide the custom ring types.
  • CTU.raw – an audio file referenced by RINGLIST.DAT.
  • dialplan.xml – a dialplan.
  • Various firmware images named as follows:
    • P003x-xx-x-00.bin – universal application loader for upgrades from images earlier than 5.x.
    • P003x-xx-x-00.sbn – secure universal application loader for upgrades from images 5.x or later.
    • P0y3x-xx-x-00.loads – universal application loader and application image, where y represents the protocol of the application image (.loads) file: 0 for SCCP, and S for SIP.
    • P0y3x-xx-x-00.sb2 – application firmware image, where y represents the protocol used by the image: 0 for SCCP, and S for SIP.

With all the necessary files available on the TFTP server, I set about upgrading the firmware to the latest SIP release by editing the OS79XX.TXT file to read P0S3-08-2-00 and resetting the phone. The TFTP server log told me that the phone picked up the appropriate firmware release, but that it couldn’t find one of binary images (P0S3-08-2-00.bin)

After some research, it seems that POS3-08-x-00.bin does not seem to exist for any 8.x firmware:

Versions [6.x] and [7.x] seem to have P0S3-0x–xx-00.BIN files which make it easy when upgrading from SCCP to SIP as all you have to do is rename the file it loads in OS79XX.TXT to one of these *.BIN files and its all done straight to SIP.

With version 8 series it doesn’t have these and that forces you to upgrade it in a 3 part reboot and load phase with[:]

XMLDefault.cnf.xml
[SEPmacaddress.cnf.xml]

That loads the *.loads file then it loads *.sbn and reboots
After warm reboot it loads *.sb2 which must be the sip software.

Then reboots again starting in sip and then provisions with[:]

SIPDefault.cnf
[SIPmacaddress.cnf]

Armed with this new information, I put the 7.4 SIP firmware into my TFTP root folder, edited OS79xx.TXT to read P0S3-07-4-00 and created an xmlDefault.CNF.XML file.

After booting the phone I was pleased to see a message that said Upgrading software but that pleasure soon ended as the upgrade never completed. Thankfully I hadn’t “bricked” the phone and, after another reboot, the phone showed a message which said Load ID Incorrect. The TFTP logs indicated that the phone was trying to load a file called SEPmacaddress.cnf.xml.

Googling turned up some more information and it turned out I was trying to go too far in one jump – my phone had been supplied with v3.x SCCP firmware and I was trying to go straight to v7.x firmware:

You have to upgrade to a new version of SCCP or older version of SIP before the bootloader on the phone will be able to handle the newer firmware […] you can either use an older version of SIP first, or a newer version of SCCP. Older SIP is probably easier – 6.3 is the newest you can use to then jump to 7.x and/or 8.x.

I put the v6.3 firmware on my TFTP server, edited OS79XX.TXT to read P0S3-06-3-00 and rebooted the phone. This time I saw the Upgrading Software message and watched the transfer take place.

After rebooting itself the phone came back up on the v6.3 firmware and was showing itself as Phone Unprovisioned.

I set about the second stage upgrade to v8.2 by editing OS79XX.TXT to P0S3-08-2-00 and rebooting the phone again. That didn’t help, but a further OS79XX.TXT edit from P0S3-08-2-00 to P003-08-2-00 did the trick as the Universal Application Loader booted.

Despite attempting to read non-existent files called CTLSEPmacaddress.tlv and SEPmacaddress.cnf.xml (the Cisco 7940 and 7960 IP Phones Firmware Upgrade Matrix explains the hunt algorithm employed by the Universal Application Loader) the phone downloaded the appropriate files and restarted to return as an unprovisioned device, finally running the v8.2 SIP firmware.

By this point, the TFTP logs were not much help as they didn’t indicate any errors but the status message on the phone gave me more clues:

W350 unprovisioned proxy_backup
W351 unprovisioned proxy_emergency
W362 No Valid Line Names Provisioned

The unprovisioned backup and emergency proxies didn’t bother me but I couldn’t understand why I had no valid lines provisioned. I had been trying to get the phone to use my Linksys SPA3102 as a SIP proxy but something was not quite right. In the end, I gave up and registered with SIPgate. After updating my configuration files to reflect the SIPgate account details, my phone picked up a valid line but couldn’t make or receive calls. Following advice on the SIPgate website, I made sure that the following ports were all open:

I’m not sure if all of these are strictly necessary but they seem to have got things working. The final contents of my configuration files are detailed below, after the TFTP log from a successful boot:

Connection received from ipaddress on port 50967 [25/07 00:41:32.672]
Read request for file <CTLSEPmacaddress.tlv>. Mode octet [25/07 00:41:32.672]
File <CTLSEPmacaddress.tlv> : error 2 in system call CreateFile The system cannot find the file specified. [25/07 00:41:32.672]
Connection received from ipaddress on port 50968 [25/07 00:41:32.703]
Read request for file <SEPmacaddress.cnf.xml>. Mode octet [25/07 00:41:32.703]
File <SEPmacaddress.cnf.xml> : error 2 in system call CreateFile The system cannot find the file specified. [25/07 00:41:32.703]
Connection received from ipaddress on port 50969 [25/07 00:41:32.719]
Read request for file <SIPmacaddress.cnf>. Mode octet [25/07 00:41:32.719]
Using local port 1203 [25/07 00:41:32.719]
<SIPmacaddress.cnf>: sent 2 blks, 632 bytes in 0 s. 0 blk resent [25/07 00:41:32.735]
Connection received from ipaddress on port 50970 [25/07 00:41:32.766]
Read request for file <P0S3-08-2-00.loads>. Mode octet [25/07 00:41:32.781]
Using local port 1204 [25/07 00:41:32.781]
<P0S3-08-2-00.loads>: sent 1 blk, 461 bytes in 0 s. 0 blk resent [25/07 00:41:32.781]
Connection received from ipaddress on port 50962 [25/07 00:41:54.672]
Read request for file <SIPDefault.cnf>. Mode octet [25/07 00:41:54.672]
Using local port 1205 [25/07 00:41:54.672]
<SIPDefault.cnf>: sent 2 blks, 925 bytes in 0 s. 0 blk resent [25/07 00:41:54.688]
Connection received from ipaddress on port 50963 [25/07 00:41:54.813]
Read request for file <SIPmacaddress.cnf>. Mode octet [25/07 00:41:54.828]
Using local port 1206 [25/07 00:41:54.828]
<SIPmacaddress.cnf>: sent 2 blks, 632 bytes in 0 s. 0 blk resent [25/07 00:41:54.828]
Connection received from ipaddress on port 50967 [25/07 00:41:56.891]
Read request for file <RINGLIST.DAT>. Mode octet [25/07 00:41:56.891]
Using local port 1207 [25/07 00:41:56.891]
Connection received from ipaddress on port 50974 [25/07 00:41:56.907]
<RINGLIST.DAT>: sent 1 blk, 15 bytes in 0 s. 0 blk resent [25/07 00:41:56.907]
Read request for file <dialplan.xml>. Mode octet [25/07 00:41:56.907]
Using local port 1208 [25/07 00:41:56.907]
<dialplan.xml>: sent 1 blk, 104 bytes in 0 s. 0 blk resent [25/07 00:41:56.907]

OS79XX.TXT

P003-08-2-00

SIPDefault.cnf

;begin
image_version: P0S3-08-2-00
proxy_register: 1
dial_template: dialplan
tftp_cfg_dir: “”
sntp_server: “ntp.sipgate.net”
sntp_mode: unicast
time_zone: GMT
dst_offset: 1
dst_start_month: March
dst_start_day_of_week: Sun
dst_start_week_of_month: 8
dst_start_time: 01
dst_stop_month: Oct
dst_stop_day_of_week: Sun
dst_stop_week_of_month: 8
dst_stop_time: 02
dst_auto_adjust: 1
time_format_24hr: 1
date_format : D/M/Y

# NAT/Firewall Traversal
nat_enable: 1 ; 0-Disabled (default), 1-Enabled
nat_address: “” ; WAN IP address of NAT box (dotted IP or DNS A record only)
voip_control_port: 5060 ; UDP port used for SIP messages (default – 5060)
start_media_port: 8000 ; Start RTP range for media (default – 16384)
end_media_port: 8012 ; End RTP range for media (default – 32766)
nat_received_processing: 0 ; 0-Disabled (default), 1-Enabled
outbound_proxy_port: 5082
telnet_level: 2
;end

SIPmacaddress.cnf

;begin
image_version: P0S3-08-2-00
phone_label : “markwilson.it ” ; Has no effect on SIP Messaging
line1_name : “sipgateid” ; SIPgate device ID#
line1_authname : “sipgateid” ; SIPgate device ID#
line1_password : “sipgatepassword” ; SIPgate device password
line1_shortname : “phonenumber”
line1_displayname : “phonenumber”
proxy1_address : “sipgate.co.uk”
proxy1_port : 5060
line2_displayname: “”
line2_shortname: “”
line2_name: UNPROVISIONED
line2_authname: “UNPROVISIONED”
line2_password: “UNPROVISIONED”
proxy2_address : “”
proxy2_port : 5060
phone_password: “password”
logo_url: “http://webserver/sipgate.bmp”
directory_url: “http://webserver/directory.xml”
;end

RINGLIST.DAT

CTU CTU.raw

xmlDefault.CNF.XML





2000
2427 2428



P0S3-07-4-00






Further information

Here are some of the sites that I found particularly useful as I went through this process:

[update 10 September 2009: Here’s another useful resource on how to set up a cisco 7940 and 7941 IP phone to do SIP.]

[update 27 March 2010: Tyler Winfield’s article on configuring Cisco IP phones with Asterisk is very thorough and easy to read – even if you’re not using Asterisk.]