When we implement call forwarding for an internal extension to say a cell phone, when a call is forwarded the caller id data shows the incorrect NXX digits (1st 3 digits), but correctly shows the last 4 digits of the originating call. Is there a way to configure Call Mgr so that it correctly forwards the full phone 7 or 10 digit caller ID data?
This might be a RDNIS issue or bug on your gateways. What type of gateway and version IOS are you using?
Um, check that just reread, and that would be ANI not DNIS. Sorry. The only thing I can thing of is that if digit manipulation is occuring between them or possibly a bug. Can you still post your exact version of the affected devices (CCM,Phone,GW). Also make sure your CFW isn't using a CSS that can select a Translation Pattern or Route List that might be manipulating the ANI. Remember in CCM 4.x CFW CSS acts different for offnet CFA, which I believe uses the line CSS, the rest use whats in the field next to the pattern. I will doublecheck that again in the SRND.
Please rate any helpful posts
Thanks Fred for the response. We have multiple gateways at various sites, but at our primary site we run 2851's on 12.4(9)T1. They are MGCP gateways.
Any other information you need to pin this down let me know.
Here was the thing on the CSS for CFW. I know it's not your issue but it could have potential so I wanted to be thorough.
When the Call Forward All calling search space is left as
? If Call Forward All is invoked from the IP phone, the call-forward calling search space becomes the
concatenation of the line and device calling search spaces of that IP phone.
? If Call Forward All is invoked from the User Options page, the behavior depends on the Cisco
? In Cisco CallManager Release 3.3(3) and earlier, the call-forward calling search space is copied
from the line calling search space only.
? In Cisco CallManager Releases 3.3(4) and 4.0(2) or later, the call-forward calling search space
becomes the concatenation of the line calling search space and the calling search space of the
"best-guess" device (that is, the last device from which the user invoked Call Forward All).
Note In Cisco CallManager Release 4.0(1), when the Call Forward All calling search space is left as
Cisco CallManager does not use the line or device calling search space of the line that invoked the
Forward All; instead, it uses the calling search space of the calling device that is being redirected.
So I don't fry my brain and try to understand exactly what was just said, where are you specifying the cell number to forward to (CFA,CFB,CFNA?) and are you using a CSS for the CFW. Then we should be able to determine if this is configuration that is causing your problem (ex. translation inline) or maybe a bug.
Woah Fred, that's some good stuff. So we can eliminate the CM 3.33 and earlier, since we are on CM 4.13. The instances of the NXX codes being translated are when the CFwdALL is used at the phone or through the webpage. So as an example, an outside line calling an office number that is call fowarded at the phone or at the webpage to a home phone gets the NXX translated, using the office phones NXX digits.
Cell Call ID with CFwdALL: 805-777-1111
If I use either the phone to call forward all, or the webpage to call forward, I get the same result.
I have sent a request to our LEC (TWTC) to see if they support and have RDNIS enabled on the switches that provide our PRI's.
Not sure if I answered all your questions, but let me know.
Correct on my last post...in the example I am forwarding to the Cell Phone, so any reference to the home phone is meant to read as the cell phone.
The RDNIS request isn't needed. I goofed and read that quick, so it's ANI that is the problem, not DNIS. I knew there were some RDNIS bugs with chopping some of the prefix digits but that shouldn't apply here.
Last question. Is the phone using the
Haha, this actually might be a quite simple one. On the gateway configuration, do you have a Caller ID DN specified of 805777XXXX? If not there then trace back through your Route List Details, Route Pattern and see if you might have one there. These would be in the Calling Party Transform Mask fields.
This might be the 2nd time today I've overcomplicated something. Hopefully thats it.
Good thought on the route-list, but sadly there are no entries in the Calling Party Transform Mask field in the Route List associated with the 2851's. In looking at our route patterns (there are several, 911, 411, international, 976 block etc), the only one I see that may be relevent is the local pattern 9.XXXXXXX, but it also has no calling party transform mask values defined.
Also, in your previous posting, what command syntax would I be looking for on the voice gatways for caller id settings? My thoughts are that since they are mgcp based, the call mgr will handle all call control and routing values.
Thanks for your continued thoughts on this.
Exactly, on the MGCP gateway configuration screen of the individual PRI, you will see a field called Caller ID DN. Let us know if this is set.
Yup you found it! Within each PRI is the Caller ID DN value
Here is what is currently in our setting:
Can this value be changed without adversely affecting other inbound/outbound calls?
You will need to move that back to the Route List Details. Then you can create another Unique Route List used by the Forwarding CSS. This gets back to my question whether or not you were using