Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Users might experience few discrepancies in Search results. We are working on this on our side. We apologize for the inconvenience it may have caused.
New Member

IOS Calling Party Name and CallManager

Does anyone have Calling Party Name working with CCM3.2? What is your gateway configuration? Using NI3, H323, MGCP, etc?

6 REPLIES
New Member

Re: IOS Calling Party Name and CallManager

Facitiles Information Element (which carries name in PRI-National) is NOT supported until CM 3.3.

Network-Specific Facilities

"Cisco CallManager Release 3.3 supports outbound call-by-call delivery of AT&T Network-Specific Facilities including Software-Defined Network (SDN) and Megacom services. Support extends to 4ESS and 5ESS switches.The supported voice gateways include Cisco Catalyst 6000 8-port PRI card (WS-6608-T1), Cisco VG200, Cisco 26XX, Cisco 36XX, and Cisco 37XX with PRI ISDN interface configured on NM-HDV or NM-HDV2 network modules. "

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_3/rel_note/332cmrn.htm

New Member

Re: IOS Calling Party Name and CallManager

Also, the CO switch needs to be compliant to the GR-1367 spec, which adds the capability to deliver Calling Name (and a couple other more minor features) to a PRI running National ISDN, using a Facility IE.

Specifically, CallManager 3.3(3) when it's released will be able to decode and display the Calling Name when using MGCP PRI gateways.

New Member

Re: IOS Calling Party Name and CallManager

A co-worker said the callingpartyname is a bug in CCM and that 3.3(4) would fix it. We already have NI2 with Facility IE delivery, but CallManager doesn't seem to work. There is a CCO article about MGCP and CCM and callingpartyname but we use H323/NM-HDV/IOS.

Does anyone have the CCM bug id for callingpartyname to track?

New Member

Re: IOS Calling Party Name and CallManager

How about inbound?

New Member

Re: IOS Calling Party Name and CallManager

Here is the published Cisco bug ID on this problem. The issue revolves around Call Manager looking for caller name in the wrong information element (Display IE) in the ISDN Q.931 SETUP message. Telco's provide caller name over the same information element as they do caller ID number(which is the facilities IE). At this point, call manager only supports name delivery across the Display Information Element.

CSCdt95817

Bronze

Re: IOS Calling Party Name and CallManager

I'm currently on CCM 3.3, but I had Calling Party Name working while on CCM 3.2. You will need to us National ISDN (not NI2) and MGCP.

We have two Gateways, a VG200 and a 6608 8-port T-1 blade that is in a Cat. 6509. I have Name display working on the VG-200 (using MGCP) in both directions between the SL-100 PBX and the CCM. On the 6608 blade, I have Name display working on inbound calls only (SL-100 to the CCM).

I found that the CCM 3.2 will only accept the Name display in the Display Information Element. Originally I had the PRI between the VG200 and the SL-100 (same software as a DMS-100) defined as NI2. I found out that the NI2 protocol will put the Name display in the Facility Information Element and therefore will not work with the CM. I then went back and redefined the PRI as NTNAPRI. I also found out that QSIG also uses the Facility Information Element to pass the Name display so QSIG will not work either. This I understand is now working on CCM 3.3, but I haven't played with it.

When we got the VG200, initially I couldn't get the Name display working between the SL-100 and the CM. After changing the PRI protocol to NTNAPRI, I set the following items on the Gateway: Protocol Side: User (SL-100 PRI trunk is set to Network) Calling Party Selection: Originator Channel IE Type: Use Number when 1B MCDN Channel Number Extension Bit Set to Zero: Checked Interface Identifier Present: Checked Interface Identifier Value: Zero (This matches the PRI trunk as defined on the SL-100) Note: This value on the SL-100 is assigned to the first T-1, if you have a second T-1 in the trunk group it would be assigned a 1 and so forth. Display IE Delivery: Checked Redirecting Number IE Delivery Inbound: Checked Presentation Bit: Allowed Called Party IE Number Type Unknow: CCM Calling Party IE Number Type Unknow: CCM Called Numbering Plan: Unknown Calling Number Plan: Private PRI Protocol Type: PRI DMS-100 Send Extra Leading Character in Display IE: Checked Setup non-ISDN progress indicator IE Enable: Checked Line Coding: B8ZS

Framing: ESF

Clock: External

Note: The Called Numbering Plan and the Calling Number Plan were the two fields I was playing with when I got the Name Display to work. I'm not convinced that these two fields couldn't be defined as something else. Let me explain. When you make a field change on the Gateway, you then do an Update and then Gateway reset. On the SL-100 we have an alarm panel that sounds when a T-1 goes down. When you reset the Gateway it will cause the T-1 to go down for 20-30 seconds while the Gateway resets. One of the things that bothers me when configuring the Gateway is that the Gateway isn't consistent. Sometimes I get an alarm, but not always when I reset the Gateway. The day I got the Name display working I was making changes to the fields Called Numbering Plan and Calling Number Plan. However, I wasn't getting an alarm on the trunk when I was doing a reset on the Gatway. This was puzzling me, so I decided to do a route pattern change. We have two prefixes assigned in the SL-100: 766 and 755. All of the IP sets are using 766 prefix. So I had set up the 755 prefix for testing, I had a route pattern defined for the IP users of 6XXXX for calling the SL-100 and this was pointed at the 6608 blade. I also had 5XXXX route pattern set up on the VG200 for calling the SL-100. What I decided to do was to change the 6XXXX pattern to the VG200. After the Gateway reset I had Name display working. So I guess what I am trying to say in all the above is that as you make changes in the Gateway, you need to make sure that it is indeed reseting. Just pressing the reset button on screen doesn't necessarilly mean that the Gateway actually resets in all casses. This was very frustrating. Good Luck.

942
Views
0
Helpful
6
Replies
CreatePlease to create content