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.

Not getting Calling Number on 911 calls... CER

I can't see to figure this one out.  I am running CUCM 6.1.4 with CER 2.0.3.  We have multiple sites, so it works like this:

User in building A dials 911

911 matches the extension associated with RP911, which is the CTI port that CER is using

CER matches the phone to the location within it's database, and looks up the site prefix (i.e. 870) for that location

CER forwards the call to 870911

This matches route pattern 870.911

This route pattern strips the pre-dot, overwrites the calling number, and forwards out the correct gateway

At least this is how it's supposed to work.  And is working at most of my sites (all of which share the same CUCM cluster and CER server).  The problem is that when the call hits the gateway at this one location, no calling number is sent out.  I tested the route pattern (by dialing 123.911 directly, with the correct CSS), and that went out fine, with the correctly overwritten calling number.  It seems that it is only when the call is placed by the RP911 CTI port.  But that isn't all of it, because the other locations use that RP and they are working.

I took traces, and I see where the problem lies, but I don't know where it's getting set.  Here is a line from the trace of the successful call:

05/12/2010 11:46:17.705 CCM|Digit analysis: match(pi="2", fqcn="7635552656", cn="2656",plv="5", pss="E911-pt:RO-INTERNAL-PT:GV-INTERNAL-PT:LOGV-INTERNAL-PT:LOGV-PRIVATE-PT:LOBC-INTERNAL-PT:GV-911-PT:LOBC-911-pt:LOGV-911-pt:RO-911-PT:MG-911-PT:MG-INTERNAL-PT:RI-911-pt:RI-INTERNAL-PT:MI-911-pt:MI-INTERNAL-PT:MI-L2-PT:MI-LCL-PT:SL-911-PT:SL-INTERNAL-PT:HU-INTERNAL-PT:BC-INTERNAL-PT:LOGV-IPCC-PT:LOGV-LD-PT:LOGV-LCL-PT:LOGV-VM-PT:CW-BLOCK-TOLLFRAUD", TodFilteredPss="E911-pt:RO-INTERNAL-PT:GV-INTERNAL-PT:LOGV-INTERNAL-PT:LOGV-PRIVATE-PT:LOBC-INTERNAL-PT:GV-911-PT:LOBC-911-pt:LOGV-911-pt:RO-911-PT:MG-911-PT:MG-INTERNAL-PT:RI-911-pt:RI-INTERNAL-PT:MI-911-pt:MI-INTERNAL-PT:MI-L2-PT:MI-LCL-PT:SL-911-PT:SL-INTERNAL-PT:HU-INTERNAL-PT:BC-INTERNAL-PT:LOGV-IPCC-PT:LOGV-LD-PT:LOGV-LCL-PT:LOGV-VM-PT:CW-BLOCK-TOLLFRAUD", dd="870911",dac="0")|<CLID::StandAloneCluster><NID::10.142.128.14><CT::3,100,65,1.483117748><IP::10.128.101.144><DEV::SEP001BD460408E><LVL::State Transition><MASK::0800>

And from one that did not work:

05/12/2010 10:47:06.506 CCM|Digit analysis: match(pi="1", fqcn="7635552656", cn="2656",plv="5", pss="E911-pt:RO-INTERNAL-PT:GV-INTERNAL-PT:LOGV-INTERNAL-PT:LOGV-PRIVATE-PT:LOBC-INTERNAL-PT:GV-911-PT:LOBC-911-pt:LOGV-911-pt:RO-911-PT:MG-911-PT:MG-INTERNAL-PT:RI-911-pt:RI-INTERNAL-PT:MI-911-pt:MI-INTERNAL-PT:MI-L2-PT:MI-LCL-PT:SL-911-PT:SL-INTERNAL-PT:HU-INTERNAL-PT:BC-INTERNAL-PT", TodFilteredPss="E911-pt:RO-INTERNAL-PT:GV-INTERNAL-PT:LOGV-INTERNAL-PT:LOGV-PRIVATE-PT:LOBC-INTERNAL-PT:GV-911-PT:LOBC-911-pt:LOGV-911-pt:RO-911-PT:MG-911-PT:MG-INTERNAL-PT:RI-911-pt:RI-INTERNAL-PT:MI-911-pt:MI-INTERNAL-PT:MI-L2-PT:MI-LCL-PT:SL-911-PT:SL-INTERNAL-PT:HU-INTERNAL-PT:BC-INTERNAL-PT", dd="870911",dac="0")|<CLID::StandAloneCluster><NID::10.142.128.14><CT::1,200,15,1.4802197><IP::10.142.128.18><DEV::RP911><LVL::State Transition><MASK::0800>

Obviously, the PI is set to 2 when it worked and 1 when it didn't, but where on Earth could this be set?  It's not on the Route Pattern, because these both matched the same one.  And it can't be anything down-stream from the route pattern, like the route group or dial-peer because we see the difference here.  And I don't see how it could be on the device level, because this is working for other locations using RP911.

1 REPLY

Re: Not getting Calling Number on 911 calls... CER

TAC to the rescue again.  The problem was the Calling Party Selection field in the H.323 Gateway configuration within CUCM.  We had it set to First Redirect Number (External).  Once we changed that to Orginator and reset the gateway, it came through fine.  I wasn't even looking at the gateway configuration because I had keyed on the different PI values.

278
Views
0
Helpful
1
Replies