Scenario#45: 7841 SIP phone in Registration loop

I was working on this customer issue last week where they added a new 7841 phone but it was not registering properly or should I say it was registering briefly before unregistering.

Call Manager was which does not support 78XX phones so customer actually applied the device pack cmterm-devicepack9.1.2.12039-1.cop  so that they can add 78XX phones.

Looking at the logs I found that it is registering with Pub and not Sub even though Sub was the Primary CCM in Call Manager group. At Pub I can see something like this:


Via: SIP/2.0/TCP;branch=z9hG4bK739dd207
From: <sip:49715220XXXXX@>;tag=544a003629fd000a741be677-22e1dea8
To: <sip:49715220XXXXX@>
Call-ID: 544a0036-29fd0008-13a9ded8-614a41b9@
Max-Forwards: 70
Date: Tue, 17 Jun 2014 06:32:10 GMT
User-Agent: Cisco-CP7841/10.1.1
Contact: <sip:61131fd1-5eb6-b49e-5d2f-9f9aee1b125c@;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-544a003629fd>”;+u.sip!”SEP544A003629FD”;+u.sip!”622″

[Registration Accepted by Publisher]
SIP/2.0 202 Accepted
Via: SIP/2.0/TCP;branch=z9hG4bK6c29941b
From: <sip:544a003629fd@>;tag=544a003629fd000c3890afb1-54d723a2
To: <sip:>;tag=875713562
Date: Tue, 17 Jun 2014 06:32:10 GMT
Call-ID: 544a0036-29fd0006-22434855-1719a3c1@
CSeq: 1000 REFER
Contact: <sip:;transport=tcp>
Content-Length: 0




But then I noticed this further down:

08:32:16.866 |AppInfo  |SIPStationD(607) – setUaTypeAndCepn: uaType is CISCO_ENHANCED_PHONE

08:32:16.866 |AppInfo  |SIPStationD(607) – Received REGISTER from 4971522036708@

08:32:16.866 |AppInfo  |SIPStationD(607) – verifyAddressAndPort — Endpoint unregistered (expires=0), old ip:, new ip:


08:32:16.866 |AppInfo  |SIPStationD(607) – parseLoad: InactiveLoad= name is: [sip78xx.10-1-1-9.loads]

08:32:16.866 |AppInfo  |SIPStationD(607) – processReasonCode:  Processing phone provided reason code=[105]

08:32:16.866 |AppInfo  |SIPStationD(607) – DevStat-NewState : line 4971522036708: Registered ==> Unregistered


While on Subscriber this is what I saw:



[Registration Request]

Via: SIP/2.0/TCP;branch=z9hG4bK5fead06f
From: <sip:49715220XXXXX@>;tag=544a003629fd00020eea65f9-659c5963
To: <sip:49715220XXXXX@>
Call-ID: 544a0036-29fd0003-4c3d829b-12a9daae@
Max-Forwards: 70
Date: Wed, 11 Apr 2012 08:28:24 GMT
User-Agent: Cisco-CP7841/10.1.1
Contact: <sip:61131fd1-5eb6-b49e-5d2f-9f9aee1b125c@;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-544a003629fd>”;+u.sip!”SEP544A003629FD”;+u.sip!”622″
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.5.1
Reason: SIP;cause=200;text=”cisco-alarm:25 Name=SEP544A003629FD ActiveLoad=sip78xx.10-1-1SR1-4.loads InactiveLoad=sip78xx.10-1-1-9.loads Last=initialized”
Expires: 3600
Content-Type: multipart/mixed; boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 1203


08:31:40.497 |AppInfo  |SIPStationD(684) – setUaTypeAndCepn: uaType is CISCO_ENHANCED_PHONE

08:31:40.497 |AppInfo  |CcmdbStationRegistrationProfileBuilder::init – No typemodel table-entry for device SEP544A003629FD.

08:31:40.497 |AppInfo  |CcmdbStationRegistrationProfileBuilder::getBasicRegistrationProfile::init() – failed rc(1)

08:31:40.497 |AppInfo  |SIPStationD(684) – Registration profile error: Database error, sending registration reject and closing station

08:31:40.497 |AppInfo  |SIPStationD(684) – sendRegisterResp: non-200 response code 404, ccbId 336776, expires 4294967295, warning Database error

08:31:40.497 |AlarmErr |AlarmClass: CallManager, AlarmName: EndPointTransientConnection




So what does it tells us?

Subscriber is not accepting the registration from this 7841 as it does not see that phone type as a legitimate phone.

But hang on did the customer not applied the device pack? yes they did.

A quick phone call with customer revelaed some secrets… Yes they did applied the device pack but rebooted only the Publisher. He questioned me in amazement  “Do we need to reboot Subscribers as well?”


Anyways, issue was resolved after rebooting the Sub as well. The device pack although applies would not take affect until you reboot it. So remember that if you are going to apply a device pack then:

  1. Apply on all nodes
  2. Reboot all nodes in cluster starting from Publisher






7 thoughts on “Scenario#45: 7841 SIP phone in Registration loop

  1. Hi

    Thanks for your post.

    We have new deployment with slight higher cucm version which is along with default 7841 firmware sip78xx.10-1-1SR1-4. We have recently tried to upgrade 7841 to sip78xx.10-1-1SR2-1 and download status always shows Unknown. But the phone is registered as normal and active load ID shows phone load latest firmware. Any idea why download status shows Unknown? Whether this status effect anything?


  2. Hi Fei, If the latest firmware is active and you can confirm that from CUCM Web page and from phone itself then you may ignore that status. You may be hitting this Sev 4 bug CSCtr08964.

  3. Hello Ashar,

    I am a newbie in Cisco VoIP and your blog is very useful. On the above mentioned scenario i think database replication wouldn’t have done the trick ? If possible please revert…might clear my concepts as well.


  4. dears;

    i have the latest firmware sip78xx.10-3-1-12 but the phone is requested Load ID sip78xx.10-1-1-9 , also i have a problem which when the agent try to recieve the call , the call is drop once he picked up it.

  5. hi, can you please share a downloads link for the (cmterm-devicepack9.1.2.12039-1.cop) you used?
    as it’s removed from all cisco official download sites.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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

%d bloggers like this: