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:
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.
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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...