cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3076
Views
10
Helpful
15
Replies

Inbound Caller ID Name Not Displaying

DAVID BURKHART
Level 1
Level 1

I have a Cisco 2811 router with a T1 card that serviced a PRI. It was configured as an MGCP gateway. Caller ID Name and Number worked fine. I replaced it with an ISR4331 but configured it as an h.323 gateway. After placing the 4331 in service, incoming Caller ID Name no longer displays on phones (Caller ID Number works fine). I read an old post from 2010 that said only MGCP gateways could take the Caller ID Name; I'm hoping that's changes in 13 years. Any assistance would be appreciated. 

1 Accepted Solution

Accepted Solutions
15 Replies 15

H323 is getting deprecated, its recommend to move to sip.

 

Hope this link help you.

 

https://community.cisco.com/t5/collaboration-knowledge-base/mapping-isdn-caller-id-display-to-h323-sip-mgcp-protocols/ta-p/3162887

 

 



Response Signature


Might I be so bold and ask you what was the reason for not setting up the new gateway as MGCP? If that was working fine for you there really shouldn’t be any specific reason for you to change this and if you do H.323 is not the best path to go. As @Nithin Eluvathingal answered, H.323 is being deprecated in IOS, so it is really not recommended to use. The setup in the gateway for using SIP instead is very straightforward, you just set the protocol on the two dial peers used to send calls to or from your CMs to SIP and then create a SIP trunk in CM and put that into the Route Group used by the call routing you have in place for this gateway. Then you should do some other cleanup of not needed configuration in IOS used for H.323, but it’s not critical for the switch to SIP, so it can be done later.



Response Signature


@Roger Kallberg, I have three PRI circuits coming into three different locations. The vendor I used to help me get our infrastructure setup in the early 2000s used MGCP for the router managing the primary inbound circuit, and H.323 for the other two locations. Since I primarily manage CUCM, CUC and CER (as well as Exchange), and have only configured other routers for SRST, configuring these gateways is really beyond my experience and knowledge. I was able to replicate the configuration from one of the H.323 locations for this new 4331, but did not know that this protocol was being deprecated nor the limitations of supporting Caller ID Name. 

I have put the old 2811 router back into production as a temporary workaround, and will attempt to get this 4331 setup as @Nithin Eluvathingal has recommended using the referenced article. Thank you all for your assistance. 

Sounds like a viable plan. What you need to change on the dial peers to/from CM in the router is only this to make it use SIP.

dial-peer voice <number> voip
 session protocol sipv2
 dtmf-relay rtp-nte sip-kpml

There is nothing more needed in IOS, then in CM you'd need to create a SIP trunk with the IP of the router as the destination. If you'd like to use other more up to date configuration options on the dial peers and on the gateway in general and wants to get input on this please post the entire running config, minus any sensitive info like pw and so.

This document might be something that could be of value to you to read as it contains a lot of great information on how call routing works in IOS. In Depth Explanation of Cisco IOS and IOS-XE Call Routing 



Response Signature


Attached is the redacted running config. Since this router does not have any FXO ports, I do not believe I need many, or any, of the existing dial-peer statements. However, as I said, I merely brought this config forward from another h.323 router that does have FXO ports (needed for on-prem connectivity to a paging solution). 

There were/are some strange conditions on what protocols supported inbound caller ID on FXO ports, and which ones didn't. I couldn't tell you the last time I set up a new H.323 gateway or FXO port, so I think those brain cells have been archived to disk.

Those things wouldn't be applicable to a page control port since that would be strictly outbound calls.

I'm not worried about the caller ID information on the FXO ports; only the T1/PRI. 

Before we even start with any changes to your configuration I strongly recommend you to update IOS in your ISR4K gateway. The version you use is past end of everything. If you’re not using Smart Licensing I would recommend using the latest available 16.9 version, but if you do use Smart Licensing I would recommend using version 17.6.4. Once you have updated please post the running configuration again.



Response Signature


I indeed have Smart Licensing. Is this the version you're referencing?  isr4300-universalk9_npe.17.06.04.SPA.bin

Yes that’s the one.



Response Signature


Here's the post-upgrade running config. 

Per the shared content you still use the same version.

version 15.5

 



Response Signature


I installed isr4300-universalk9_npe.17.06.04.SPA.bin as instructed. From show run | include boot I get
boot-start-marker
boot system flash:isr4300-universalk9.17.06.04.SPA.bin
boot-end-marker
license boot suite AdvUCSuiteK9
I do see what you're referencing, but I followed the link below to get this applied. As I noted, I rarely have to work with routers so I'm afraid this is my Achille's heel. 

https://community.cisco.com/t5/networking-knowledge-base/how-to-upgrade-or-downgrade-the-ios-on-an-isr-or-similar-router/ta-p/3111919 

OK - I found this note with an article on managing IOS upgrades: "When you upgrade from Cisco IOS XE 3.x to 16.x image, you should first upgrade the rommon release to the 16.7(5r) rommon release. After upgrading to the 16.7(5r) rommon release, based on the IOS XE 16.x image, the rommon release can be auto-upgraded to a later rommon release." The original IOS was indeed isr4300-universalk9.03.16.04b.S.155-3.S4b-ext.SPA.bin, so it appears I need to get 16.7(5r) installed first, then reapply 17.06.04. 

You don’t need to reapply IOS, just update the rommon and then when you reload the router it should load the IOS referenced by the boot load statement.



Response Signature