We have a 7.1 CME on a 3851 that has been running well for the past month. We are currently receiving number caller ID from the Telco and it is getting displayed on the phones. We would like to get caller name to come up on the phones along with the number.
The Telco has confirmed that the PRI switch uses 5ess, so here is my pertinent PRI configuration:
isdn switch-type primary-5ess
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24
Names don't show in 5ess mode because according to cisco definitions, a true 5ess never sends names in facility IE and the code doesn't have the decoding hooks.
Leave switchtype NI
Send exact IOS used, and "show controllers T1".
ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)
You have reported rommon, IOS version is actually the very first line from "show version".
Anyway, I recommend you update to either 12.4(22)YB6, or 15.0(1)M3.
Both are CME 7.1, both are very stable, both should get you the PRI working as "primary-ni" without any problem.
Duh. I'm sorry.
Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)
primary-ni2c is a special switch type for SP purposes, present only in SP images, that you should not be using.
You should run the code indicated above with "primary-ni" (sorry, I had indicated "ni2" before), and you will have no problems after that.
Thanks for the suggestions.
I upgraded our 2851 to 15.0(1)M3 on Tuesday and last night I changed the switch-type to primary-ni. Everything was fine after 4 hours, but 6:30 hours after that we discovered the PRI was dead again. We followed our usual procedure to recover, shut interface and change switch-type back to primary-5ess and we were back up.
Is there a way to make the caller ID names work with 5ess? Maybe by requesting the provider to change the way they send the information?
I still don't understand why this breaks. I don't know what to debug to try to find out what the issue is.
You can't just change the ISDN protocol on one side. You service provider needs to match on their end. Are you just changing it on one side?
Brandon, in no event a switch mismatch setting is supposed to break a voice port to make it non-useable but having the ability to start it again with config changes.
This is just not acceptable in to the way ios is supposed to work and be resilient.
So, since it seems this is happening reproducibly, I think TAC must have a look to it and escalate as necessary until resolution.
The switch is set to ni, the router also, there is no reason it stops operating unless a bug.
As you can see the time differential between the SETUP and the FACILITY that contains calling name is ~700 ms.
Is this GW H323 or MGCP?
If H323 try configuring:
voice service voip
h225 timeout ntf 1000
This will buffer the h225 SETUP for 1 second so you can receive calling name and send it to CUCM before processing the call and sending back ALERTING.
If this still fails, please send:
no logging console
logging buffered 10000000 debug
debug isdn q931
debug h225 q931
debug h225 asn1
This is just a hunch...it may work, but may not, I'm not entirely sure IOS can support receiveiving calling name in a subsequent FACILITY when a call is in call state 7, which is CALL RECEIVED.
You can also try changing your switchtype to primary-ni which does support recieving name in FACILITY.
Hope that helps, -Dave
As stated at the top of the thread. OP has CME, not CM.
The issue will be (I hope) be resolved applying the recommendations I made above.
If it were me, this is what I would do:
I would first call the provider and ask what ISDN protocol they have this circuit provisioned for, just for verification sake. Note that I am not asking you to ask them 'Am I configured for National?' Make them actually look at the configuration and tell you what they are configured for. I wouldn't proceed until you have a clear answer of a) switch type and b) that calling name is provisioned on this circuit. It may not hurt to make sure you're talking to an engineer that actually knows ISDN--most Level 1 telco support engineers only think at the physical layer and run BERT tests.
If they say they are on a 5E, they're either not sending calling name, or they don't know what they are talking about and they're looking in the wrong spot. If you take a look at the 5E spec (TR 41459), there is *no* mention of a mechanism to send calling name. Also, our engineering documents make no mention of CNAME on a 5E switch, for this very reason. So to put it simply, you're never getting CNAME working on a 5E switch.
CNAME in a facility on a national switch is specified with SR-4994 11.6.2 and we do support that, as has been mentioned. I find it extremely strange that you simply stop receiving q.931 after several hours of normal operation when configured for national. Once you know you have a circuit with CNAME provisioned and know the correct switch type, stay on that configuration and troubleshoot through any issues. When calls stop working on the circuit, call the provider and call TAC and raise the SR as a P2--maybe the provider sees the D channel down during this time. If you can get the provider to come out and put a device in the middle that will sniff q.931 messages, that will be conclusive if it is an issue with our side not receiving the q.931 message, or the provider not sending it, when the calls stop working.