Call forwarding on CM4.13 sends incorrect NXX digits

[swharvey]

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?

Thanks,

-Scott

[fred.s.mollenkopf]

Scott,

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

[swharvey]

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.

-Scott

[fred.s.mollenkopf]

Scott,

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 , the following behavior applies:

? 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

CallManager release:

? 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.

Thanks

Fred

[swharvey]

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.

Example:

Dialer: 805-555-1111

Office: 805-777-2000

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.

-Scott

[swharvey]

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.

[fred.s.mollenkopf]

Scott,

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 in the field next to where you specify the number? or is it using a named CSS you created? Also I just thought that this might be something with the Numbering Plan on the Gateways, can you post what they are configured as? The default is Cisco CallManager.

Thanks

Fred

[fred.s.mollenkopf]

Scott,

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.

Thanks

Fred

[swharvey]

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.

-Scott

[fred.s.mollenkopf]

Scott,

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.

Thanks

Fred

[swharvey]

Yup you found it! Within each PRI is the Caller ID DN value

Here is what is currently in our setting:

805777XXXX

Can this value be changed without adversely affecting other inbound/outbound calls?

[fred.s.mollenkopf]

Scott,

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 in the CSS field of your CFA. Technically what you should do is create a CSS for CFA(this is so it doesn't abide by those funky rules I posted previously when using ). The CSS for CFA should reference a pattern that has a route list without the mask. Your normal direct dial patterns will match the pattern with the mask. But basically if you do it at the Gateway level, it'll always override that ANI with what you configure there.

Thanks

Fred

[Rob Huffman]

Hey Fred,

You really went the "extra mile" on this one! 5 points from this end for sure :)

Take care,

Rob