Caller ID Name breaks PRI

[jdargence]

Hello,

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

interface Serial0/0/0:23

no ip address

encapsulation hdlc

isdn switch-type primary-5ess

isdn incoming-voice voice

isdn supp-service name calling

no cdp enable

With this configuration I don't get the names and when doing a q931 debug and making a incoming call I see an error in the output:

Version:1.0 StartHTML:0000000149 EndHTML:0000002483 StartFragment:0000000199 EndFragment:0000002449 StartSelection:0000000199 EndSelection:0000002449 Aug  5 22:39:54.604: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0274
     Bearer Capability i = 0x8090A2
         Standard = CCITT
         Transfer Capability = Speech 
         Transfer Mode = Circuit
         Transfer Rate = 64 kbit/s
     Channel ID i = 0xA98384
         Exclusive, Channel 4
     Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100
     Calling Party Number i = 0x2183, '619XXXXXXX'
         Plan:ISDN, Type:National
     Called Party Number i = 0x80, '206'
         Plan:Unknown, Type:Unknown
Aug  5 22:39:54.604: ISDN Se0/0/0:23 Q931: Received SETUP  callref = 0x8274 callID = 0x0BAF switch = primary-5ess interface = User
Aug  5 22:39:54.628: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x8274
     Channel ID i = 0xA98384
         Exclusive, Channel 4
Aug  5 22:39:54.640: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x8274
     Progress Ind i = 0x8188 - In-band info or appropriate now available
Aug  5 22:39:55.312: ISDN Se0/0/0:23 Q931: RX <- FACILITY pd = 8  callref = 0x0274
     Facility i = 0x9F8B0100A117020101020100800F44415247454E434520202020202020
Aug  5 22:39:55.312: ISDN Se0/0/0:23 **ERROR**: Ux_BadMsg: Invalid Message for call state 7, call id 0xBAF, call ref 0x8274, event 0x62
Aug  5 22:39:55.312: ISDN Se0/0/0:23 Q931: TX -> STATUS pd = 8  callref = 0x8274
     Cause i = 0x80E262 - Message not compatible with call state or not implemented
     Call State i = 0x07

If I change the isdn switch-type to primary-ni2c, the names come up on the phones and I can see them in the debug.  The problem with doing this is that things will work great for a few hours, but after some time (I haven't been able to determine exactly how long it takes), we lose the PRI completely.  No q931 messages and the only way to get them back is to shut and unshut the serial 0/0/0:23 interface.Since this is not a critical issue, I have left things as they are now, but I'm wondering why I can't get the names to come up when configuring 5ess as the switch type.  I've read some comments about how when the name is sent in the facility message it's an issue.  Is this true?  Is there a way I can make it work with the way my Telco sends the information or do I need to ask them to change this?Thanks

[paolo bevilacqua]

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.

So:

Leave switchtype NI

Send exact IOS used, and "show controllers T1".

[jdargence]

Nice!

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

It's a 2851 btw, not at 3851.

Here's the output of show controllers T1

show controllers t1

T1 0/0/0 is up.

  Applique type is Channelized T1

  Cablelength is long 0db

  No alarms detected.

  alarm-trigger is not set

  Soaking time: 3, Clearance time: 10

  AIS State:Clear  LOS State:Clear  LOF State:Clear

  Version info Firmware: 20090408, FPGA: 13, spm_count = 0

  Framing is ESF, Line Code is B8ZS, Clock Source is Line.

  CRC Threshold is 320. Reported from firmware  is 320.

  Data in current interval (434 seconds elapsed):

     0 Line Code Violations, 0 Path Code Violations

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

  Total Data (last 24 hours)

     0 Line Code Violations, 3 Path Code Violations,

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 1 Degraded Mins,

     1 Errored Secs, 1 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

T1 0/0/1 is down.

  Applique type is Channelized T1

  Cablelength is long 0db

  Transmitter is sending remote alarm.

  Receiver has loss of signal.

  alarm-trigger is not set

  Soaking time: 3, Clearance time: 10

  AIS State:Clear  LOS State:Clear  LOF State:Clear

  Version info Firmware: 20090408, FPGA: 13, spm_count = 0

  Framing is ESF, Line Code is B8ZS, Clock Source is Line.

  CRC Threshold is 320. Reported from firmware  is 320.

  Data in current interval (435 seconds elapsed):

     0 Line Code Violations, 0 Path Code Violations

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 435 Unavail Secs

  Total Data (last 24 hours)

     0 Line Code Violations, 0 Path Code Violations,

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 86400 Unavail Secs

0/0/0 is the one in use and 0/0/1 is not being used.Thanks!

[paolo bevilacqua]

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.

[jdargence]

Duh.  I'm sorry. 

Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)

Now would it matter if I was using ni2c vs ni?

I could try it with ni and see if that makes things better, but upgrading wouldn't be a bad idea to be on a known stable release.

Jorge

[paolo bevilacqua]

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.

[jdargence]

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.

[Brandon Svec]

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

[paolo bevilacqua]

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.

[David Smith]

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:

conf t

voice service voip

h323

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:

conf t

no logging console

logging buffered 10000000 debug

exit

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

[paolo bevilacqua]

Davismi2,

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.

[David Smith]

Oops, my mistake, sorry.  Yup, try primary-ni.

[Steven Holl]

Jorge,

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.

Good luck,

Steve