AFAIK, H323 has been supporting inbound caller ID name for long now. It actually depends on the Switch type. What is the switch type for the PRI you have ??
I have always been told and in fact have seen inbound caller ID on a PRI not work with H.323. Do you have a document that talks about this?
Switch type NI2
Unfortunately I've not been able to find a document which states this. And from the Caller ID, I believe you are referring to Calling Party Name. And I guess the reason you were informed that Cisco does not support Calling Party Name, could be because calling party name received in the form of Facility IE is not support when you configure your PRI with NI2 to work on H323. At the same time, if Calling Party Name inbound is received in Display IE, it works great.
So if you are looking at Facility IE support for Name, then yes, it does not work with H323. It works with MGCP. And on the other hand if it is Display IE, that works from both MGCP and H323.
I hope this helps
Well, you dont have to do anything. It is your Telco which needs to. In the first place, do we know how they send it. Do a "debug isdn q931" on the router which has the PRI for a test call and see how it is being received. Incase it is not being received as a part of the Setup message in Display IE field, then you need to contact your Telco and have them send it in that format
Here's the deal on CNAM:
The only place where I've found that caller name was delivered in display IE instead of facility IE was in Canada.
However, the capability to transmit caller name back to CM with H.323 is already in IOS 12.4(11)XW
H.323 Name Display
Calling name display information may be populated in ISDN messages in the Display Information Element (IE) of a Q.931 Setup or Notify message, or in the Facility IE of a Q.931 Setup or Facility message. The Cisco IOS gateway places this information into the same field of the corresponding H.323 message.
Cisco Unified Communications Manager (CUCM) interprets calling name information (for purposes of name display on IP phones registered with CUCM) only in the Display IE of the H.323 Setup and Notify messages. Name display information delivered in an H.323 Facility message is not interpreted by CUCM. Some ISDN switch types (for example, NI2) send a "name-to-follow" indication in the Q.931 Setup message and deliver the calling name subsequently in the Facility IE of a Q.931 Facility message. When a Cisco IOS gateway is connected to such an ISDN switch, and interoperating with CUCM using the H.323 protocol, CUCM is unable to display calling name on the IP phones.
Beginning with Cisco IOS Release 12.4(11)XW, two new modes of operation are introduced on the Cisco IOS gateways:
?When a Q.931 Setup message with a "name-to-follow" indication is received from an ISDN switch, an H.323 Setup message with no name information is sent to CUCM. When the subsequent Q.931 Facility message is received with calling name information, it is mapped by the gateway to an H.323 Notify Display IE so that CUCM can interpret it correctly and display it on the IP Phone.
?When a Q.931 Setup message with a "name-to-follow" indication is received from an ISDN switch, the gateway can buffer the setup message until the subsequent Q.931 Facility message with calling name information is received. The name information from the Q.931 Facility message is now placed into the H.323 Setup message Display IE and sent to CUCM. If the buffer timer expires before the Q.931 Facility message is received, an H.323 Setup is sent with no name information and, if it subsequently arrives, the information is sent on using an H.323 Notify message.
This software operation is transparent to CUCM and works with all releases, although CUCM 4.2 or later is recommended.
At one point I found a note that this feature was also in 12.4(15)T. That document has vanished, and the feature is definately not in that release.
I have not been able to get an answer from my rep when/if this feature will go into the T series....
We have been using the T chain/series for a good long time and for a lack of a better reason, we trust it.
I was/am willing to consider another chain, if I could find out what features or stability I might give up. I did look to see what was the focus/intent of the XW chain, sadly without learning anything useful.
XW is focused on voice. Being now to the 8th maintenance release, lot of bugs have been fixed and is stable to use. I have quite a few installations and no new problems with it.