Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Shared lines for all DNs. Callamanger 4.1.3

Dear All,

I faced a very strange issue.

All DNs in my CallManager have become marked as shared.

Even DNs that exists only on one phone.

Route Plan Report returns correct information but when I'm looking for line on every device, line is marked as shared.

Is it a database problem or something else?

P.S. Callamanager 4.1.3.

2 ACCEPTED SOLUTIONS

Accepted Solutions
Hall of Fame Super Silver

Shared lines for all DNs. Callamanger 4.1.3

Do you have Extension Mobility (UDP) profiles or softphones perhaps with the same DNs?

Chris

Shared lines for all DNs. Callamanger 4.1.3

This is interesting. I actually thought Chris was on to something because I recall seeing something similar to your issue when we enabled EM on the device. You don't have to have the EM service running for the issue to present itself.

It has been a while since I mucked with 4.1. So, I am going from memory. One of the first things I would attempt is seeing if I could find the redundant records by using Dependency Records.

If that didn't bear any fruit, I would go to the database. On a 4.1 system, you can RDP to the console and launch SQL Query Analyzer. I don't recall the sequence but possibly Start > Program Files > Enterprise SQL ?? > SQL Query Analyzer. Once loaded, you need to attach to your DB. Should be in a drop down or something. Maybe there is a tree rendered in the left hand pane? (That could be Enterprise Manager?). Anyway, connect to your DB somehow.

Then you can a query like the following:

SELECT d.name as 'devname', n.dnOrPattern, rp.name as 'routepartition' FROM numplan as n INNER JOIN devicenumplanmap as dmap on dmap.fknumplan=n.pkid inner join device as d on dmap.fkdevice=d.pkid where n.dnOrPattern='' order by n.dnOrPattern, d.name

The result should give you a list of DNs in numeric order and a device should be listed next to the DN. The query above just focuses on one DN. So, use a DN that your CM is reporting as a shared line. All you are looking for is more than one instance of the DN. To clarify, CUCM (and CM) store all numbers in a table called "Numplan". Entries are unique. Associations to devices are made by way of "DeviceNumPlanMap". When a DN is shared, there will be more than one reference to it in the "DeviceNumplanMap" table.

If you only see a single occurence then we can try this query:

SELECT d.name as 'devname', n.dnOrPattern, rp.name as 'routepartition' FROM numplan as n INNER JOIN devicenumplanmap as dmap on dmap.fknumplan=n.pkid left join device as d on dmap.fkdevice=d.pkid where n.dnOrPattern='' order by n.dnOrPattern, d.name

The above query is just checking for entries in DMAP and is not constraining the output by requiring an association with a particular device. If the first query only showed one entry and the second shows 2 then I expect that the second entry also shows a row where the value for device is blank. This would be a problem.

If you still don't see two entries then I would jump on a subscriber node and repeat the queries.

I'd also probably check replicaiton "just to be sure".

If the SQL queries are coming up "clean" (meaning, you don't see a shared line appearance) then it isn't coming from the DB and it is something else that is suspect. Perhaps RIS or DBLHelper. Though, I am not sure how likely that would be. On 4.1 I recall issues with CFA getting stuck (a DBLHelper issue) and with IP addresses/registration status missing (a RIS issue) but nothing related to erroneously reporting shared line appearances. Anyway, to clear it up you may need to restart some services (or the nodes themselves). Then you can do some bug searching to see if you can find root cause.

Now, if you find that the second query kicks out duplicate entries without a device association then the only way to remediate that is to clean up the devicenumplanmap table. Now that I think about it, I think that the schema requires a fkdevice entry but I would have to look at the data dictionary to be sure it is enforced. We can cross that bridge if you determine this is your issue.

HTH.

-Bill (http://ucguerrilla.com)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

6 REPLIES
Hall of Fame Super Silver

Shared lines for all DNs. Callamanger 4.1.3

Do you have Extension Mobility (UDP) profiles or softphones perhaps with the same DNs?

Chris

New Member

Shared lines for all DNs. Callamanger 4.1.3

Dear Chris, thank you for reply.

Extension mobility is not activated on the cluster.

Some lines are shared between softphone and IP phone, but Route Plan Report correctly shows all devices that share one line.

In my case not shared lines are marked as shared.

Shared lines for all DNs. Callamanger 4.1.3

This is interesting. I actually thought Chris was on to something because I recall seeing something similar to your issue when we enabled EM on the device. You don't have to have the EM service running for the issue to present itself.

It has been a while since I mucked with 4.1. So, I am going from memory. One of the first things I would attempt is seeing if I could find the redundant records by using Dependency Records.

If that didn't bear any fruit, I would go to the database. On a 4.1 system, you can RDP to the console and launch SQL Query Analyzer. I don't recall the sequence but possibly Start > Program Files > Enterprise SQL ?? > SQL Query Analyzer. Once loaded, you need to attach to your DB. Should be in a drop down or something. Maybe there is a tree rendered in the left hand pane? (That could be Enterprise Manager?). Anyway, connect to your DB somehow.

Then you can a query like the following:

SELECT d.name as 'devname', n.dnOrPattern, rp.name as 'routepartition' FROM numplan as n INNER JOIN devicenumplanmap as dmap on dmap.fknumplan=n.pkid inner join device as d on dmap.fkdevice=d.pkid where n.dnOrPattern='' order by n.dnOrPattern, d.name

The result should give you a list of DNs in numeric order and a device should be listed next to the DN. The query above just focuses on one DN. So, use a DN that your CM is reporting as a shared line. All you are looking for is more than one instance of the DN. To clarify, CUCM (and CM) store all numbers in a table called "Numplan". Entries are unique. Associations to devices are made by way of "DeviceNumPlanMap". When a DN is shared, there will be more than one reference to it in the "DeviceNumplanMap" table.

If you only see a single occurence then we can try this query:

SELECT d.name as 'devname', n.dnOrPattern, rp.name as 'routepartition' FROM numplan as n INNER JOIN devicenumplanmap as dmap on dmap.fknumplan=n.pkid left join device as d on dmap.fkdevice=d.pkid where n.dnOrPattern='' order by n.dnOrPattern, d.name

The above query is just checking for entries in DMAP and is not constraining the output by requiring an association with a particular device. If the first query only showed one entry and the second shows 2 then I expect that the second entry also shows a row where the value for device is blank. This would be a problem.

If you still don't see two entries then I would jump on a subscriber node and repeat the queries.

I'd also probably check replicaiton "just to be sure".

If the SQL queries are coming up "clean" (meaning, you don't see a shared line appearance) then it isn't coming from the DB and it is something else that is suspect. Perhaps RIS or DBLHelper. Though, I am not sure how likely that would be. On 4.1 I recall issues with CFA getting stuck (a DBLHelper issue) and with IP addresses/registration status missing (a RIS issue) but nothing related to erroneously reporting shared line appearances. Anyway, to clear it up you may need to restart some services (or the nodes themselves). Then you can do some bug searching to see if you can find root cause.

Now, if you find that the second query kicks out duplicate entries without a device association then the only way to remediate that is to clean up the devicenumplanmap table. Now that I think about it, I think that the schema requires a fkdevice entry but I would have to look at the data dictionary to be sure it is enforced. We can cross that bridge if you determine this is your issue.

HTH.

-Bill (http://ucguerrilla.com)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Hall of Fame Super Red

Shared lines for all DNs. Callamanger 4.1.3

WOW!

Awesome answer here Bill! +5 for providing such a great detailed

response here my friend SWEET!

Cheers!

Rob

PS: nice to see you back at CSC buddy.

"When it comes to luck you make your own  " 

- Springsteen

Shared lines for all DNs. Callamanger 4.1.3

Hey Rob,

Thanks for endorsement. Yeah, Dan Bruhn said I would be off of his Christmas Card list if I didn't get my butt in gear ;-) You know how I like those family pictures during the holidays.

I hope you are doing well.

HTH

-Bill
(b) http://ucguerrilla.com
(t) @ucguerrilla

Please remember to rate helpful responses and identify helpful or correct answers.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

New Member

Shared lines for all DNs. Callamanger 4.1.3

Dear All

I'm greatly appreciated for all answers.

But solution or workaround for my issue was ridiculous.

While operating with backups I have noticed, that lines are marked as shared only while accessing callmanger from windows7 box via IE 11. But lines are not marked as shared while accessing callmanager via RDP or directly from the console in both cases via IE 6.

It's even not a solution and I'm crazy about it.

184
Views
0
Helpful
6
Replies
CreatePlease login to create content