Cisco's latest 79x1 lineup (including 7906G)

Introduction

Cisco recently released a new series of IP phones, the 7906G, 7911G, 7941G, 7961G and 7971G series. The 7941 and up also come in a G-GE model which has gigabit copper connectivity through the phone, the others have just standard 10/100 for the phone and on the additional PC port. All these new phones sport new cool features, mostly along the lines of newer and better display units, initial support for SIP, but additionally - and this is a major change - config file management, which is now XML based rather than plain (name,value) text pairs. These phones supposedly will, in the future, support an enhanced range of features compared to the 79x0 series.

Some product documentation on them is at http://www.cisco.com/en/US/products/ps6788/Products_Sub_Category_Home.html

Unfortunately the format of the config files has never been well documented on CCO and Google searching shows up a limited amount of content on "cisco SIP and cnf.xml", so this page serves as a reference guide to getting these phones working with SIP compliant phone services such as Asterisk. I recently opened a TAC case to find out more information about the format of the config files but Cisco were unwilling to assist - as as far as they are concerned if the phones are run in a CallManager environment (which is what they were intended for) there is no need to manually edit the config files therefore they were not willing to give help running them in a non CM environment. It's a real shame really because these phones really are very nice handsets, and even if cisco did not want to support third party SIP servers, they could at least make information available so that others could do so.

Here's a sample config file, documented tags are listed below. Note there is a minor error in this file as noted below. If you are aware of how to fix it please do so.

Please DO read this file in detail. You must change instances of things like YOURNTPSERVER and replace them either with an NTP server IP address, or remove the statement altogether. Leaving them in will confuse your phone, and at the very least cause it to reject parts of the config, if it loads it at all.

Config File Editing

Note that the config file contents appear to be case sensitive, and most of the parameters start with a small letter after the opening bracket.

<device xsi:type="axl:XIPPhone" ctiid="1566023366">

Note that there is a small syntax error of sorts in the statement above, the phone spits out a message:
 NOT 22:26:07.770897 JVM: -XML| unknown element or attribute name ("xsi:noNamespaceSchemaLocation") (line=2) however it seems harmless.

  <deviceProtocol>SIP</deviceProtocol>

Define these if you want to be able to ssh to the phone. After ssh'ing you can log in with debug/debug, or log/log to get some basic idea of what is going on, force the phone to re-register etc, or default/user to drop to a basic non-root shell.

  <sshUserId>username</sshUserId>
  <sshPassword>password</sshPassword>

These next settings are for time related configuration, setting the timezone etc. If you do not specify an NTP server, the phone picks the date and time up from the SIP registration headers from the SIP server. On a LAN this should result in your phone getting sub millisecond accuracy to a local NTP server.

You can find appropriate settings for the timeZone parameter at http://www.cisco.com/univercd/cc/td/doc/product/voice/its/cme34/cme_cr/cme_t1ht.htm#wp1071293 which is publicly accessible. If you copy and paste the relevant entry from the Description field into the <timeZone></timeZone> field in your config, then your phone should then display the correct local time on the phone.

<dateTemplate> can be D-M-Y M-D-Y or Y-M-D
You can also use either dashes, dots, or forward slashes as separators in your dateTemplate, these will be reflected in the date shown on the phone.
There is probably also a way to get the phone to display either 12 or 24 hour time but I'm unsure how just yet (possibly a <timeFormat> tag?)

Edit >> There is also 'a' (for 12 hour/am pm) and 'A' (for 24 hour) attribute that sets if it's 12 or 24 hours. (e.g. D/M/Ya) Note: if your using chan_sccp, you have to also set it on the server. For the times zones, you can use your local time zone, example: Pacific Standard/Daylight Time or New Zealand Standard/Daylight Time.

Edit >> The following time zones are also for the 7970 and can replace UTC Standard/Daylight Time for your local time zone but must be written precisely as follows including caps and punctuation (any deviation from the following will result in the time being automatically returned to UTC):

Dateline Standard Time
Samoa Standard Time
Hawaiian Standard Time
Alaskan Standard/Daylight Time
Pacific Standard/Daylight Time
Mountain Standard/Daylight Time
US Mountain Standard Time
Central Standard/Daylight Time
Mexico Standard/Daylight Time
Canada Central Standard Time
SA Pacific Standard Time
Eastern Standard/Daylight Time
US Eastern Standard Time
Atlantic Standard/Daylight Time
SA Western Standard Time
Newfoundland Standard/Daylight Time
South America Standard/Daylight Time
SA Eastern Standard Time
Mid-Atlantic Standard/Daylight Time
Azores Standard/Daylight Time
GMT Standard/Daylight Time
Greenwich Standard Time
W. Europe Standard/Daylight Time
GTB Standard/Daylight Time
Egypt Standard/Daylight Time
E. Europe Standard/Daylight Time
Romance Standard/Daylight Time
Central Europe Standard/Daylight Time
South Africa Standard Time
Jerusalem Standard/Daylight Time
Saudi Arabia Standard Time
Russian Standard/Daylight Time
Iran Standard/Daylight Time
Caucasus Standard/Daylight Time
Arabian Standard Time
Afghanistan Standard Time
West Asia Standard Time
Ekaterinburg Standard Time
India Standard Time
Central Asia Standard Time
SE Asia Standard Time
China Standard/Daylight Time
Taipei Standard Time
Tokyo Standard Time
Cen. Australia Standard/Daylight Time
AUS Central Standard Time
E. Australia Standard Time
AUS Eastern Standard/Daylight Time
West Pacific Standard Time
Tasmania Standard/Daylight Time
Central Pacific Standard Time
Fiji Standard Time
New Zealand Standard/Daylight Time

  <devicePool>
     <dateTimeSetting>
        <dateTemplate>D-M-YA</dateTemplate>
        <timeZone>UTC Standard/Daylight Time</timeZone>
        <ntps>
             <ntp>
                 <name>YOURNTPSERVERIPADDRESS</name>
                 <ntpMode>Unicast</ntpMode>
             </ntp>
        </ntps>
     </dateTimeSetting>

This next part is required, otherwise the phone claims to be unprovisioned. It just requires your SIP server's DNS name. It also appears that the phone will not pick up some XML configuration changes if the <callManagerGroup> element is not present.

     <callManagerGroup>
        <members>
           <member priority="0">
              <callManager>
                 <ports>
                    <ethernetPhonePort>2000</ethernetPhonePort>
                    <sipPort>5060</sipPort>
                    <securedSipPort>5061</securedSipPort>
                 </ports>
                 <processNodeName>PUTYOURSIPSERVERNAMEINHERE</processNodeName>
              </callManager>
           </member>
        </members>
     </callManagerGroup>
  </devicePool>

Generally don't need to specify these, but maybe you will want to put in the register line. Note that the opening and closing tags of these elements must be on the same line, or else it won't be able to do integer conversion (I think this is a bug).

  <sipProfile>
     <sipProxies>
        <backupProxy></backupProxy>
        <backupProxyPort></backupProxyPort>
        <emergencyProxy></emergencyProxy>
        <emergencyProxyPort></emergencyProxyPort>
        <outboundProxy></outboundProxy>
        <outboundProxyPort></outboundProxyPort>
        <registerWithProxy>true</registerWithProxy>
     </sipProxies>

Some basic features and settings.

     <sipCallFeatures>
        <cnfJoinEnabled>true</cnfJoinEnabled>
        <callForwardURI>x--serviceuri-cfwdall</callForwardURI>
        <callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
        <callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
        <callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
        <meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
        <abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
        <rfc2543Hold>false</rfc2543Hold>
        <callHoldRingback>2</callHoldRingback>
        <localCfwdEnable>true</localCfwdEnable>
        <semiAttendedTransfer>true</semiAttendedTransfer>
        <anonymousCallBlock>2</anonymousCallBlock>
        <callerIdBlocking>2</callerIdBlocking>
        <dndControl>0</dndControl>
        <remoteCcEnable>true</remoteCcEnable>
     </sipCallFeatures>

These are to do with SIP connection control.

     <sipStack>
        <sipInviteRetx>6</sipInviteRetx>
        <sipRetx>10</sipRetx>
        <timerInviteExpires>180</timerInviteExpires>
        <timerRegisterExpires>3600</timerRegisterExpires>
        <timerRegisterDelta>5</timerRegisterDelta>
        <timerKeepAliveExpires>120</timerKeepAliveExpires>
        <timerSubscribeExpires>120</timerSubscribeExpires>
        <timerSubscribeDelta>5</timerSubscribeDelta>
        <timerT1>500</timerT1>
        <timerT2>4000</timerT2>
        <maxRedirects>70</maxRedirects>
        <remotePartyID>false</remotePartyID>
        <userInfo>None</userInfo>
     </sipStack>

More general SIP features...

     <autoAnswerTimer>1</autoAnswerTimer>
     <autoAnswerAltBehavior>false</autoAnswerAltBehavior>
     <autoAnswerOverride>true</autoAnswerOverride>
     <transferOnhookEnabled>false</transferOnhookEnabled>
     <enableVad>false</enableVad>

Often you will need to specify the codec. The choices on these phones are g711 and g729a (and maybe others?)

     <preferredCodec>g729a</preferredCodec>
     <dtmfAvtPayload>101</dtmfAvtPayload>
     <dtmfDbLevel>3</dtmfDbLevel>
     <dtmfOutofBand>avt</dtmfOutofBand>
     <alwaysUsePrimeLine>false</alwaysUsePrimeLine>
     <alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail>
     <kpml>3</kpml>

If you are behind a cheap router then these options may be useful. These tell the phone to rewrite the SIP headers it sends out to the SIP proxy, to match your external address. This then allows your external IP address to be registered as the IP address that your phone is on. Set <natEnabled> to 1 and specify your external IP address. I'm not sure if this works with dynamic DNS, but it may do....

     <natEnabled>0</natEnabled>
     <natAddress>external IP address</natAddress>

The phoneLabel parameter defines what appears in the top right hand section of the black band in the display. It makes sense that this is where you put in your external/PSTN/DID number. However there seems to be a limit of 12 characters which is not enough if you want to put an international number there with spaces like I did (as when I lived in NZ but had an Australian DID on the phone)

     <phoneLabel></phoneLabel>

The stutterMsgWaiting setting is used to determine if your phone sends a 'stutter' signal to the earpiece when the line is first taken off hook if there is voicemail waiting. Set 1 to get a stutter, set to 0 if you don't want this feature.

     <stutterMsgWaiting>1</stutterMsgWaiting>

CallStats refer to if the phone feeds back call quality statistics to the SIP server when the call is terminated.

     <callStats>false</callStats>
     <silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts>
     <disableLocalSpeedDialConfig>false</disableLocalSpeedDialConfig>

These are the UDP ports that the phone expects to see RTP streams (UDP traffic) coming in and going out on. These values below are probably the defaults anyway. If you are running your phone behind a non SIP aware router you may want to narrow this range down to say 16384 and 16390, and then map UDP ports 16384 through to 16390 to your phone from the outside. This will allow your phone to receive inbound RTP voice streams. If your router is SIP aware then likely you do not need to change this from the defaults.

     <startMediaPort>16384</startMediaPort>
     <stopMediaPort>32766</stopMediaPort>

This is a crucial part of the config. If this is missing, your phone will complain about being "Unprovisioned" so take care with what you edit in here. While the phone is in the "Unprovisioned" state it will repeatedly download it's config file via TFTP every minute or two, so changes you make should be picked up fairly quickly. I am aware of the multiple uses of your SIP username - quite possibly some are redundant.

     <sipLines>
        <line
         button="1">
           <featureID>9</featureID>
           <featureLabel>extension number</featureLabel>
           <proxy>SIP proxy</proxy>
           <port>5060</port>

Put your SIP username in here

           <name>sip username</name>

This next line <displayName> is for the SIP request. The phone will send out whatever the value of this is in the SIP registration, so put your name. It doesn't matter too much but I believe that this name appears on the remote phone if it supports it. In my case I put <firstname> <lastname>

           <displayName>Your Name (appears in SIP requests as a type of Caller Name)</displayName>
           <autoAnswer>
              <autoAnswerEnabled>2</autoAnswerEnabled>
           </autoAnswer>
           <callWaiting>3</callWaiting>

SIP username and password

           <authName>sip username</authName>
           <authPassword>sip password</authPassword>

           <sharedLine>false</sharedLine>

The messageWaitingLampPolicy values work like this:

   # Primary Line - Light and Prompt       set to 1
   # Primary Line - Prompt Only set to 2
   # Primary Line - Light Only set to 3
   # Light and Prompt presumably set to 4
   # Prompt Only presumably set to 5
   # Light Only presumably set to 6
   # None set to 7

'Light' is the bright red lamp on the headset
'Prompt' will show up a flashing voicemail envelope next to the Line on the RHS side of the display when there is voicemail

           <messageWaitingLampPolicy>1</messageWaitingLampPolicy>
           <messagesNumber>voicemail extension</messagesNumber>
           <ringSettingIdle>4</ringSettingIdle>
           <ringSettingActive>5</ringSettingActive>

And again, your username:

           <contact>sip username</contact>
           <forwardCallInfoDisplay>
              <callerName>true</callerName>
              <callerNumber>false</callerNumber>
              <redirectedNumber>false</redirectedNumber>
              <dialedNumber>true</dialedNumber>
           </forwardCallInfoDisplay>
        </line>

This next block of statements is to define what you do with the second line button on your phone. Potentially it could be used for a second SIP registration - although I haven't tried it. The first line is defined above for outbound calls, the second line button on my 7941 is used as a speed dial. If you have a 7961 you'll have another four of these line buttons which you can customise in the same way.

        <line
         button="2">
           <featureID>21</featureID>
           <featureLabel>speed dial name goes here</featureLabel>
           <speedDialNumber>speed dial actual number goes in here</speedDialNumber>
        </line>
     </sipLines>

Define your dialplan in here. My dialplan basically just sets a 5 second timer after each digit before the phone starts dialing the digits already entered, but ideally you'd set this so that your most common blocks of numbers (e.g 8 digits) only had a short timer after the 8th digit so that the phone would start dialing quickly after 8 digits had been entered,

     <voipControlPort>5060</voipControlPort>
     <dscpForAudio>184</dscpForAudio>
     <ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy>
     <dialTemplate>DRdialplan.xml</dialTemplate>
  </sipProfile>

  <commonProfile>
     <phonePassword></phonePassword>
     <backgroundImageAccess>true</backgroundImageAccess>
     <callLogBlfEnabled>2</callLogBlfEnabled>
  </commonProfile>

This is where you put the load name of the image. Once you've decompressed the .cop file image you'll see a file like SIP41.8-2-2SR1S.loads. The name of this file is what you need to put in the config. if the phone is running a different image it should reflash itself to match the version listed here. Note - do not specify the term41.loads file, as that file is the one and only file that the phone looks for after it has been fully reset (it doesn't have a config at that stage to know what filename to load so it loads that one and then pulls the associated signed binaries in).

  <loadInformation>SIP41.8-2-2SR1S</loadInformation>

  <vendorConfig>

Allows you to disable the speakerphone. Why you would want to do this I'm not sure.

     <disableSpeaker>false</disableSpeaker>

Disable Speaker phone and Headset:

     <disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>

Set to 0 to enable the PC port on the back of the phone, or 1 to disable it:

     <pcPort>0</pcPort>

Toggles on and off the Settings button on the front of the phone. Useful to lock the phone config down.

     <settingsAccess>1</settingsAccess>

Gratuitous ARP functionality - relates to learning MAC addresses from Gratuitous ARP responses.

     <garp>0</garp>

Set this to 0 to disable access to the voice VLAN from the PC port. Note that if you run your PC on the same VLAN as the voice (if for example you are using 802.1p to do your QoS) you must set this to 1 otherwise your PC on the same VLAN won't be able to communicate if it is connected to the PC port on the back of the phone.

     <voiceVlanAccess>0</voiceVlanAccess>
     <videoCapability>0</videoCapability>
     <autoSelectLineEnable>0</autoSelectLineEnable>

Defines whether you can browse to the web interface of the phone. The 7941 unlike the 7940, has a web server built in which is useful for monitoring the phone's performance. If the web interface does not seem to be working, try setting the value to 0 instead of 1 and reloading the phone. Odd, yes, but for me, setting this to 0 made the web interface visible.

     <webAccess>1</webAccess>
     <daysDisplayNotActive>1,2,3,4,5,6,7</daysDisplayNotActive>
     <displayOnTime>00:00</displayOnTime>
     <displayOnDuration>00:00</displayOnDuration>
     <displayIdleTimeout>00:00</displayIdleTimeout>
     <spanToPCPort>1</spanToPCPort>
     <loggingDisplay>1</loggingDisplay>
     <loadServer></loadServer>
  </vendorConfig>

  <versionStamp>1143565489-a3cbf294-7526-4c29-8791-c4fce4ce4c37</versionStamp>

Specifying the networkLocale gives me NZ tones, which makes the phone almost feel like a normal phone for the rest of the house. These networkLocale files are on CCO - look under CallManager sections for these. If you don't specify this the phone will run with the standard US default.

Setting the locale does not seem to reset the dialtone to anything local, but it does customise the ringing tone and other PSTN tones.

  <networkLocale>New_Zealand</networkLocale>

  <networkLocaleInfo>
     <name>New_Zealand</name>
     <version>5.0(2)</version>
  </networkLocaleInfo>

  <deviceSecurityMode>1</deviceSecurityMode>

The next few statements define various URL's - the authenticationURL is for authenticating access to the phone settings and administration. The phone will send the username/password details to this URL for authentication, and if the URL returns just the word AUTHORIZED the phone will allow the user to access the web administration. In my case I have a PHP script on my webserver called authenticate.php of which the contents look like this: <?php echo "AUTHORIZED"; ?>

  <authenticationURL>http://www/ipphone/authenticate.php</authenticationURL>
  <directoryURL>http://www/ipphone/directory.xml</directoryURL>
  <idleURL></idleURL>
  <informationURL>http://www/ipphone/GetTelecasterHelpText.jsp</informationURL>

  <messagesURL></messagesURL>
  <proxyServerURL>proxy:3128</proxyServerURL>
  <servicesURL>http://www/ipphone/services.xml</servicesURL>

QoS stuff, but I'm not sure if this is valid for SIP or not - I suspect it is but I haven't tried it. Viewing the phone settings from the web interface suggests that it is valid for SIP.

  <dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
  <dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
  <dscpForCm2Dvce>96</dscpForCm2Dvce>

Leave the rest of these settings alone unless you know what they do (in which case please update this document!).

  <transportLayerProtocol>4</transportLayerProtocol>

  <capfAuthMode>0</capfAuthMode>
  <capfList>
     <capf>
        <phonePort>3804</phonePort>
     </capf>
  </capfList>

  <certHash></certHash>
  <encrConfig>false</encrConfig>

</device>

Phone Firmware

The first release of code or this phone running SIP was 8.0(1). However it was never available on CCO and was only ever bundled with CUCM 5.0. The first publically downloadable release was 8.0(2). This was then followed by 8.0(2)SR1 release which fixed a few critical bugs on the phone.

For Cisco customers with a valid Cisco login and support contract - firmware files may be downloaded from http://www.cisco.com/cgi-bin/tablebuild.pl/ip-7900ser
For a list of the Firmware Changes:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipp7961/relnotes/index.htm

• Version 8.0(2)SR1 was a good release, basic functionality of the phone all works. There are quite a few minor bugs but no showstoppers, such as slight voice clipping when the call is answered. MWI works, directories work, call quality is good.

• Version 8.0(3) released 18 May 06, seems to be disaster of a release and has been deferred due to the field notice at http://www.cisco.com/en/US/products/hw/phones/ps379/products_field_notice09186a008072aa8d.shtml In other words, DO NOT USE. This release has many new defects not present in 8.0(2)SR1 such as broken MWI, personal directories no longer loading, show conf truncated and a console message about " invalid argument: ccb->last_request".

• Version 8.0(4)SR1 was released on 30 August 2006 is only marginally better than 8.0(3). Many many more bugs are fixed, HTTP has more information than previous releases, and personal directories work again. The cropping of characters seen when running 'show conf' from the command line is fixed.

• Version 8.0(4)SR2 was released on 17 Jan 2007. It works for me for outbound calls, but inbound calls all fail, and my phone provider consider my phone to be "unregistered". Debugging shows that this release too, bungles the "Date:" SIP header. The HTTP server on the phone is disabled regardless of the config setting.

• NOTE: 8.0(4)SR2 and probably early releases DO NOT work with the qualify=yes setting configured in the extension. When asterisk attempts to contact the phone to requality the phone returns an invalid SIP response and Asterisk deregisters the phone. Setting qualify=no fixes the registration problem (however the phone status is no longer monitored by asterisk).If you are having problems with registration (or calling the c79xx from Asterisk) this will likely fix your issues.

• Version 8.0(4)SR3 was released on 20 February 2007. This release clears up several issues with the 8.0(4) series like HTTP access, transfers dropping, and hold music not working. The phone is able to register and make/receive calls, and transfer calls. The inbound call caller ID no longer contains the server IP. Unfortunately the "Date: " header on the SIP packets is still munged, and MWI is still broken.

• Version 8.2(1) was released on December 8 2006. It worked outbound for about 18 hours, before I had two full resets in short succession. That was a bad sign. The HTTP server is now fixed. However Cisco still have not fixed the "Date:" header problem which appears to be causing my system to be knocked back on SIP registration through my IOS SIP firewall. This must certainly be an issue of RFC compliancy...

• Version 8.2(2) was released March 27 2007. It seems to be good. Most critically, the Date: field problem is acknowledged and appears FIXED: See http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsg27644. My early testing is that with two SIP lines registered, calls in and out work as they should. The HTTP server does not seem to work though, and you need to rename the java file to be Jar41sip.8-2-1-19.sbn instead of just jar41sip.8-2-1-19.sbn (case sensitive), but if all else is ok then this release may possibly be a contender for a recommended release.

• Version 8.2(2)SR1 was released March 31 2007 to fix a problem with the Call Lists being in the wrong order. Otherwise I believe it is identical to the previous release a few days earlier. Initially the HTTP server on the phone did not appear to work, but I found that if I set the <webAccess> tag to 0 instead of 1, it works. Yes, it seems back to front, I know, but that's what I had to do...

• Version 8.2(2)SR3 was released May 22 2007 to fix a bug that the phone will fail to register if a duplicate IP is detected. It still has the same MWI 399 error as 8.2(2)SR1. The call quality is fine and the phone seems to perform exactly the same.

• Version 8.2(2)SR4 was released June 05 2007

• Version 8.3(1) was released June 29 2007 and introduces some new features including things like an "Intercom History" in the Directories (not sure what this does though). Most visible is the addition of a "DND" softkey on the front of the phone which is obviously a Do Not Disturb function that turns inbound calls away when activated.

• Version 8.3(2) was released August 10 2007. Release notes state no resolved caveats however it does appear to resolve at least one problem - that with the DND button displaying an odd error when the DND function is activated via softkey. The code seems generally functional and good.

• Version 8.3(3) was released October 24 2007. This firmware supposedly fixes a bunch more bugs, but it has a broken NTP implementation in it (see note 3, below). Be warned that if you upgrade your phone to this release it will almost certainly display completely the wrong date/time (mine displays some date/time from about 2 months ago). It doesn't matter what time your NTP server has, the phone will ignore it.

• Version 8.3(3)SR2 was released November 21 2007. This phone also appears to have issues with NTP. and again, if the right time on the phone is important to you then this release won't suit you. If you wish to reset the time, SSH to the phone and log in with user 'default' and pass 'user' and reset it with the 'date command'. The format of that command is:

$ /bin/date 200711212255
Wed Nov 21 22:55:00 EST 2007
$

Note: Set this to the NON DAYLIGHT SAVINGS time if you are on daylight savings, and check your phone display afterwards.

• Version 8.3(4)SR1 was released March 5 2008. NTP is still broken and will not sync with a Unicast (and as best I can tell, also Broadcast) NTP servers. If you don't care about the clock/display showing the right date and time, then this release seems otherwise OK.

• Outstanding issues:

• 1. MWI with Asterisk is broken which means that you never know if there is voicemail waiting. The console logs this message which may or may not be related:

• ERR 19:43:50.533983 JVM: SIPTaskProcessSIPNotify: Error: Bad MWI NOTIFY!

• This bug may be related to http://bugs.digium.com/view.php?id=8575

1. Update 11/08/2007 The MWI bug looks to be now being tracked via CSCsi29468, which is resolved in 8.4(0.2). The bug below for MWI is not visible. If this is the case then it looks like the MWI bug will be fixed in the first 8.4 release of code for these phones.
2. Update 07/06/2007 Torsten: I have tested the MWI bug http://bugs.digium.com/view.php?id=8575 with phone 7970 and 8.2.2(SR4). It is still the same, but after the patch of chan_sip.c it is ok for asterisk version 1.2.7.1.
3. Update 29/05/2007 Greg: Since the previous user hasn't updated this page, I've stepped in to add in the 8.2.2(SR3) report.
4. Update 22/03/2007 CRC: I've raised these issues with Cisco on a TAC case and am awaiting a reply. Will post any info I receive.
5. Update 24/03/2007 CRC: The MWI bug is being tracked under cisco bug ID CSCsh55589. Will need to lodge another case on the Date: header issues.
6. rf the Date: header appears fixed in 8.2(2), see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsg27644 - I am not in a position to test the MWI issue though...
7. red:Update 11/05/2007 I've updated my 7961G to 8.2(2)SR1 - The date is confirmed fixed, MWI is still broken. Still get an error 400 "Bad Request" on this. With 8.0(4)SR3 I had a lot of issues with lines unregistering themselves (looks like the SIP port that the phone registered too went up to the 24000+ range) is fixed. Time will tell - this seemed to be a random "feature" in 8.0(4)SR3.
8. red:Update (again)~~ CRC: You can enable the option "buggymwi=yes" in your phones configuration in sip.conf under asterisk 1.4.2 (and possibly older) to make the Cisco MWI notification work again.

• 2. A console message is logged: "ERR 20:35:21.782744 JVM: Content-Length header not received" I am still trying to determine if this is a bug in the phone firmware, my cisco IOS firewall, or an upstream SIP proxy. Whatever the case it seems to have no effect on the phone.

• 3. NTP is broken in 8.3(2) and above. This has now been acknowledged by Cisco, and tracked via CSCso40588

It has been very frustrating, at least from a SIP protocol and basic phone functionality perspective, that the firmware appears to continue to have had quite obvious bugs present in released versions of code. Relatively few releases for this phone have actually had no serious showstopper defects. 8.0(2)SR1a was one of the very first releases, and until recently was the only release which even registered to a non CM server. Cisco are generally wary of accepting support cases on the phone relating to it's operation if you are not running a CallManager server, see http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipp7961/relnotes/61821.htm noting that they state that the firmware is "IETF RFC 3261 compliant" yet "not supported by Cisco TAC or Engineering for use with non-Cisco call control systems". However I had a fairly clear cut case of broken NTP above which I had no real problems getting them to accept (presumably because CallManager or no CallManager, this was a defect in the phone's operating system). You should of course have no problems having hardware swapped if there are any issues with the physical handset.

Fortunately the phones are easy to downgrade if there are issues with newer firmware as you can just edit your SEP<mac address>.cnf.xml and specify the old version to force the phone to downgrade.

If you have a maintenance contract on your phone you can find release notes describing new features and bugs at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipp7961/relnotes/index.htm.

If you do not have a copy of the required SIP image or you want to upgrade, then either contact your reseller who sold you the phone and ask them for a SIP image, or obtain a maintenance contract for your phone (they're only about $12/year) and download the software legally from CCO.

Troubleshooting

Phone connection and registration issues

1. Watch your TFTP server for the files that the phone attempts to retrieve. If you are using Windows, I heartily recommend the tftpd32 server for this, and any other cisco products. It is 200k, does TFTP client and server, NTP, DHCP and Syslog, which are all services your phone and other cisco devices will use. You can get it here http://tftpd32.jounin.net/.

2. Set up a serial console session on 9600-8,N,1 to the phone via the RS232 serial port on the back. Normally this is used for a sidecar row of extra buttons, but it is handy for debugging also. Use an RJ11 socketed cable into a standard cisco serial console socket. It outputs (no input) various notices when booting up which can be most useful for debugging when the phon doesn't work as expected. I use this frequently when I'm experimenting with featues in the config file, as any parameters which are rejected are logged and visible - can be quickly edited and a soft reset performed.

3. If the phone appears to be downloading but ignoring your config, do a full factory reset, but note: this is not to be used routinely. This formats the onboard flash, downloads an image from your TFTP server and totally reinstalls the phone from scratch. I had to do this once when my phone stopped accepting config changes (it would pull the config file over but ignore it).
The factory reset procedure is documented in the Cisco TAC collection: http://www.ciscotaccc.com/kaidara-advisor/voice/showcase?case=K43691258 - see the second series of keystrokes.

4. Use Wireshark http://www.wireshark.org/ to find out what your phone is doing over the network. If you are attempting to register to Asterisk, turn on sip debugging on the PBX.

5. The phone will request some extra files that I have not documented, such as a CTL file. This is harmless, it is to do with security certificates which are not required. One day the configuration of those might be documented here.

6. If you're getting Unprovised Errors, check to see if in the phone status if its validating your Configs. If it isn't, its probably your code. Nab an XML editor, I recommend http://www.philo.de/xmledit/ for Windows (the first one I found, spyware free, relatively small) as it can check your code however it won't tell you what line. If it passes the first check, that means all your tags have been closed. That was hanging me up for a bit. I hope that helps some people. Anyone who has better XML editor recommendations (and for Linux and OS X) please edit.

7. If you're making changes and they're not registering, check the phone log to make sure the SEPXXXX conf is being verified.

8. If you're getting registration issues yet the SEP CONF is being accepted, check to make sure you do have NAT turned on. In Trixbox by default extensions have NAT = Yes. Change it to NAT = No. Also do not enter anything in the <sipProxies></sipProxies>. Double check your extensions code.

Trixbox XML services

Trixbox comes with SugarCRM, a powerful directory service application that can manage contacts using PHP front end to a MySQL database. Trixbox is preinstalled with XML Services for translating this directory to various phones, including the Cisco 74xxs. You'll want to add the following URLs to the tags in your SEPXX....

<directoryURL>http://YOURTRIXBOXIP/cisco/services/PhoneDirectory.php</directoryURL>
<servicesURL>http://YOURTRIXBOXIP/services/index_cisco.php</servicesURL>

On the default Trixbox 2.0 install there is an errant code snippet that needs to be changed. In the file:xmlservices/include/xmlservices_lib.php lines 40 & 41 need to be commented out. This may still be in Trixbox 2.2 (unconfirmed).

Change:
$browser = "Aastra";
$content_format = "aastraxml";
To:
// $browser = "Aastra";
// $content_format = "aastraxml";
What they are doing is regardless of what type of browser you're accessing with to are treat it like an astra phone. Be careful, there is a $browser= "Aastra"; $content_format = "aastrxml" before lines 40 & 41. You'll need some SugarCRM contact entries to test out the system.

Once its working you'll need to edit the PHP files. By default, the XML services come preconfigged with a dial out number. Note the variable $LongDistanceExtension = "91" is the beginning of a few of the PHP files (PhoneDirectory.php, DirectoryItem.php). It makes the bold assumption to dial out, you must press 9. You'll want to change these entries to fit your dial scheme. Example: $LongDistanceExtension = "1" to remove the dial out prefix.

Also to change the order in which phone numbers are displayed per contact, edit the DirectoryItem.php and PhoneDirectory.php. below the while ($row = mysql_fetch_array($SelectPersonInfo)).

Example:
               if ($row"phone_work") {
                       $PersonDirectoryListing .= "<DirectoryEntry>\n";
                       $PersonDirectoryListing .= "<Name>Work:</Name>\n";
                       $PersonDirectoryListing .= "<Telephone>$WorkPhone</Telephone>\n";
                       $PersonDirectoryListing .= "</DirectoryEntry>\n";
               }
               if ($row"phone_mobile") {
                       $PersonDirectoryListing .= "<DirectoryEntry>\n";
                       $PersonDirectoryListing .= "<Name>Cell:</Name>\n";
                       $PersonDirectoryListing .= "<Telephone>$MobilePhone</Telephone>\n";
                       $PersonDirectoryListing .= "</DirectoryEntry>\n";

becomes

               if ($row"phone_home") {
                       $PersonDirectoryListing .= "<DirectoryEntry>\n";
                       $PersonDirectoryListing .= "<Name>Home:</Name>\n";
                       $PersonDirectoryListing .= "<Telephone>$HomePhone</Telephone>\n";
                       $PersonDirectoryListing .= "</DirectoryEntry>\n";
               }
               if ($row"phone_mobile") {
                       $PersonDirectoryListing .= "<DirectoryEntry>\n";
                       $PersonDirectoryListing .= "<Name>Cell:</Name>\n";
                       $PersonDirectoryListing .= "<Telephone>$CellPhone</Telephone>\n";
                       $PersonDirectoryListing .= "</DirectoryEntry>\n";

This will now change it so Home is displayed at the top of instead of a search.

With SugarCRM, multiple users can manage the phone directories through a webpane interface, making painless contact management for users. Its recommended that you use "accounts" as a way of classing the type of contacts in SugarCRM. Notably these steps aren't specific to the 79x1s phones (aside from the directoryURL and serviceURL tags) Cisco phones. A 7940, for example, will view the directory information the exact same.

Some tips on using this phone.

1. It's probably better to soft reset the phone rather than to pull the power out when you want to reboot it. Bootup messages show that the phone does have a writeable file system in flash, which although seems to be resilient and recovers from powering off, is probably going to be more reliable if you do the <settings> **#** sequence to soft reset it.

2. Do not attempt to set 800k images as the background on your phone especially the lower and mid end ones. I don't know how the phone would cope, it may be OK but it may also fill all flash space and crash the phone. Try at your own risk. The phone only can display files 30k or so and additionally has limited flash space, so your fancy million colour png will go to waste if you try using it as a background anyway.

The following example shows a Desktops/320x212x12/List.xml file that defines two images. The required Image and URL attributes must be included for each image. The TFTP URI that is shown in the example is the only supported method for linking to full size and thumbnail images. HTTP URL support is not provided.

List.xml Example

<CiscoIPPhoneImageList>

<ImageItem Image="TN-pic1.png"
URL="pic1.png"/>

<ImageItem Image="TN-pic2.png"
URL="pic2.png"/>

</CiscoIPPhoneImageList>


3. For a very cool feature (and this is probably not new to the 7941), browse to: http://yourIpPhoneIPAddress/CGI/Screenshot (See Also /CGI/CallInfo /CGI/LineInfo and /CGI/SettingsInfo)

4. Note that as of version 8.0(2)SR1 the phone sends UDP SIP requests from a high source port. This means that it will send from (for example) source port 50116 to SIP port 5060 on the SIP server. This is acceptable behaviour as per the SIP RFC, but it is different to the Cisco ATA and 7940 SIP software (and many but not all phones) and may have ramifications on your firewall rules if you are expecting the phone to send packets out from source port 5060 as well (as you may have with 7940 and ATAs etc). There are a few phones around which behave in the same way although most don't - this is not a cisco specific behaviour and is NOT a bug.
It seems that the phone drops all control traffic destined for it sent on any port other than port 5060 - and as per the SIP RFCs no server should ever do this anyway, but Asterisk configured with NAT=yes behind a NAT does work this way for return traffic from the server to the phone. This was a major problem as my phone service provider (who have their Asterisk server behind a NAT device) were returning traffic on high ports to my phone which it in turn dropped it. I requested them turn NAT off for my extension, and now my phone works perfectly. Ethereal analysis will show this up as return UDP traffic destined for other than port 5060, and a failure of the phone to register due to it not receiving the return messages from the server requesting the phone authenticate (or if no authentication, the phone will never see a SIP 200 OK message after registering).

5. To further verify your configuration, ssh to the phone and log in with your ssh username and password as defined in your cnf.xml, then when prompted again log in as debug password debug. Type 'show conf' - you should see something like this, which is basically the running config of the phone:

Cisco 79x1 SSH example

6. This example shows a distinctiveringlist.xml file that defines two phone ring types:

<CiscoIPPhoneRingList>

  <Ring>

     <DisplayName>Analog 1</DisplayName>

     <FileName>ringer1.pcm</FileName>

  </Ring>

  <Ring>

     <DisplayName>Analog 2</DisplayName>

     <FileName>ringer2.pcm</FileName>

  </Ring>

</CiscoIPPhoneRingList>

Sample Working Dialplan

(tested with 8.0.2 SR1, 8.2.2SR1 and SR3)

A sample dialplan and working config in file format can be found at http://www.reub.net/files/cisco-7941/SEP-my-mac.cnf.xml and http://www.reub.net/files/cisco-7941/DRdialplan.xml. Most users should start with this as their template.

Cisco 7961 with 8.3.3SR2 Configuration Examples.

After upgrading to 8.3.3SR2 if you use some of the below configurations you will find that you can no longer put any changes into the phones configurations and have them recognized.
Here is a working example for this firmware version and all previous 8.x versions:

$ASTERISK = IP Of Asterisk
$LABEL = Phone Label < 11 Characters
$EXTENSION = Extension
$PASSWORD = SIP Password

<device>
<fullConfig>true</fullConfig>
<deviceProtocol>SIP</deviceProtocol>
<sshUserId>user</sshUserId>
<sshPassword>pass</sshPassword>
<devicePool>
<name></name>
<dateTimeSetting>
<dateTemplate>M/D/YA</dateTemplate>
<timeZone>Eastern Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>$ASTERISK</name>
<ntpMode>Unicast</ntpMode>
</ntp>
</ntps>
</dateTimeSetting>
<callManagerGroup>
<name>5.0 Beta</name>
<tftpDefault>true</tftpDefault>
<members>
<member priority="0">
<callManager>
<name>ccm-beta-5-1</name>
<description>CallManager 5.0 Beta Pub - 5.0.1.032</description>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
<sipPort>5060</sipPort>
<securedSipPort>5061</securedSipPort>
<mgcpPorts>
<listen>2427</listen>
<keepAlive>2428</keepAlive>
</mgcpPorts>
</ports>
<processNodeName>$ASTERISK</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
<srstInfo>
<name>Disable</name>
<srstOption>Disable</srstOption>
<userModifiable>false</userModifiable>
<ipAddr1></ipAddr1>
<port1>2000</port1>
<ipAddr2></ipAddr2>
<port2>2000</port2>
<ipAddr3></ipAddr3>
<port3>2000</port3>
<sipIpAddr1>$ASTERISK</sipIpAddr1>
<sipPort1>5060</sipPort1>
<sipIpAddr2>$ASTERISK</sipIpAddr2>
<sipPort2>5060</sipPort2>
<sipIpAddr3></sipIpAddr3>
<sipPort3>5060</sipPort3>
<isSecure>false</isSecure>
</srstInfo>
<mlppDomainId>-1</mlppDomainId>
<mlppIndicationStatus>Default</mlppIndicationStatus>
<preemption>Default</preemption>
<connectionMonitorDuration>120</connectionMonitorDuration>
</devicePool>
<sipProfile>
<sipProxies>
<backupProxy>$ASTERISK</backupProxy>
<backupProxyPort>5060</backupProxyPort>
<emergencyProxy>$ASTERISK</emergencyProxy>
<emergencyProxyPort>5060</emergencyProxyPort>
<outboundProxy></outboundProxy>
<outboundProxyPort>5060</outboundProxyPort>
<registerWithProxy>true</registerWithProxy>
</sipProxies>
<sipCallFeatures>
<cnfJoinEnabled>true</cnfJoinEnabled>
<callForwardURI>x-cisco-serviceuri-cfwdall</callForwardURI>
<callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
<callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
<callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
<meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
<abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
<rfc2543Hold>false</rfc2543Hold>
<callHoldRingback>2</callHoldRingback>
<localCfwdEnable>true</localCfwdEnable>
<semiAttendedTransfer>true</semiAttendedTransfer>
<anonymousCallBlock>2</anonymousCallBlock>
<callerIdBlocking>2</callerIdBlocking>
<dndControl>1</dndControl>
<remoteCcEnable>true</remoteCcEnable>
</sipCallFeatures>
<sipStack>
<sipInviteRetx>6</sipInviteRetx>
<sipRetx>10</sipRetx>
<timerInviteExpires>180</timerInviteExpires>
<timerRegisterExpires>3600</timerRegisterExpires>
<timerRegisterDelta>5</timerRegisterDelta>
<timerKeepAliveExpires>120</timerKeepAliveExpires>
<timerSubscribeExpires>120</timerSubscribeExpires>
<timerSubscribeDelta>5</timerSubscribeDelta>
<timerT1>500</timerT1>
<timerT2>4000</timerT2>
<maxRedirects>70</maxRedirects>
<remotePartyID>true</remotePartyID>
<userInfo>None</userInfo>
</sipStack>
<autoAnswerTimer>1</autoAnswerTimer>
<autoAnswerAltBehavior>false</autoAnswerAltBehavior>
<autoAnswerOverride>true</autoAnswerOverride>
<transferOnhookEnabled>false</transferOnhookEnabled>
<enableVad>false</enableVad>
<preferredCodec>g711ulaw</preferredCodec>
<dtmfAvtPayload>101</dtmfAvtPayload>
<dtmfDbLevel>3</dtmfDbLevel>
<dtmfOutofBand>avt</dtmfOutofBand>
<alwaysUsePrimeLine>false</alwaysUsePrimeLine>
<alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail>
<kpml>3</kpml>
<phoneLabel>$LABEL</phoneLabel>
<stutterMsgWaiting>2</stutterMsgWaiting>
<callStats>false</callStats>
<offhookToFirstDigitTimer>15000</offhookToFirstDigitTimer>
<silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts>
<disableLocalSpeedDialConfig>false</disableLocalSpeedDialConfig>
<startMediaPort>16384</startMediaPort>
<stopMediaPort>32766</stopMediaPort>
<sipLines>
<line button="1">
<featureID>9</featureID>
<featureLabel>$EXTENSION</featureLabel>
<proxy>$ASTERISK</proxy>
<port>5060</port>
<name>$EXTENSION</name>
<displayName>$EXTENSION</displayName>
<autoAnswer>
<autoAnswerEnabled>2</autoAnswerEnabled>
</autoAnswer>
<callWaiting>3</callWaiting>
<authName>$EXTENSION</authName>
<authPassword>$PASSWORD</authPassword>
<sharedLine>false</sharedLine>
<messageWaitingLampPolicy>1</messageWaitingLampPolicy>
<messagesNumber>*97</messagesNumber>
<ringSettingIdle>4</ringSettingIdle>
<ringSettingActive>5</ringSettingActive>
<contact>$EXTENSION</contact>
<forwardCallInfoDisplay>
<callerName>true</callerName>
<callerNumber>false</callerNumber>
<redirectedNumber>false</redirectedNumber>
<dialedNumber>true</dialedNumber>
</forwardCallInfoDisplay>
</line>
</sipLines>
<voipControlPort>5060</voipControlPort>
<dscpForAudio>184</dscpForAudio>
<ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy>
<dialTemplate>dialplan.xml</dialTemplate>
<softKeyFile></softKeyFile>
</sipProfile>
<commonProfile>
<phonePassword></phonePassword>
<backgroundImageAccess>true</backgroundImageAccess>
<callLogBlfEnabled>2</callLogBlfEnabled>
</commonProfile>
<loadInformation>SIP41.8-3-3SR2S</loadInformation>
<vendorConfig>
<disableSpeaker>false</disableSpeaker>
<disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>
<pcPort>0</pcPort>
<settingsAccess>1</settingsAccess>
<garp>0</garp>
<voiceVlanAccess>0</voiceVlanAccess>
<videoCapability>0</videoCapability>
<autoSelectLineEnable>0</autoSelectLineEnable>
<webAccess>0</webAccess>
<daysDisplayNotActive>1,7</daysDisplayNotActive>
<displayOnTime>08:00</displayOnTime>
<displayOnDuration>10:30</displayOnDuration>
<displayIdleTimeout>01:00</displayIdleTimeout>
<spanToPCPort>1</spanToPCPort>
</vendorConfig>
<versionStamp></versionStamp>
<userLocale>
<name></name>
<uid></uid>
<langCode>en_US</langCode>
<version></version>
<winCharSet></winCharSet>
</userLocale>
<networkLocale></networkLocale>
<networkLocaleInfo>
<name></name>
<uid></uid>
<version>1.0.0.0-1</version>
</networkLocaleInfo>
<deviceSecurityMode>1</deviceSecurityMode>
<idleTimeout>0</idleTimeout>
<authenticationURL></authenticationURL>
<directoryURL></directoryURL>
<idleURL></idleURL>
<informationURL></informationURL>
<messagesURL></messagesURL>
<proxyServerURL></proxyServerURL>
<servicesURL>http://$ASTERISK/directory/directory.xml</servicesURL>
<dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
<dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
<dscpForCm2Dvce>96</dscpForCm2Dvce>
<transportLayerProtocol>4</transportLayerProtocol>
<capfAuthMode>0</capfAuthMode>
<capfList>
<capf>
<phonePort>3804</phonePort>
<processNodeName>ccm-beta-5-1</processNodeName>
</capf>
</capfList>
<certHash></certHash>
<encrConfig>false</encrConfig>
</device>





View count: 94815