Solved: ANI/CLID on forwarded calls

Nelson Serrao · ‎03-19-2010

I have been browsing through the posts and found a few that talk about the originating caller ID not being displayed on calls coming in from the PSTN destined to the IP Phone and then forwarded onwards to another PSTN destination like a mobile phone.

Most of them relate back to a restriction imposed by the telco which prevent sending out a CLID outside the DID range registered to that trunk.

However, in this case the customer has migrated to a CUCM solution and claims that it has stopped working ever since. The previous non Cisco solution displayed the caller id on forwarded calls.

H.323 gateways have been deployed and I have checked that in CUCM the Calling Party Selection is configured with "Originating Number".

For testing, I created translation rules on the gateway to mask CLID on all outbound calls with a number outside the DID range.

In this case the q931 debug showed the call being forwarded with the CLID specified in the translation pattern but on the mobile phone the CLID displayed the first number in the DID range. This tells me that it must have happened on the exchange switch but then the question is how did it work before the customer migrated to CUCM.

Is there any special configuration required to get this working or any flag to be enabled so the ANI is recognized as one that is of a forwarded call?

Or is this a CUCM limitation?

paolo bevilacqua · ‎03-19-2010

I don't believe it ever worked.

Call telco and ask them "can I send ANI of another subscriber" ?

Make sure you customer is present when they answer.

View solution in original post

paolo bevilacqua · ‎03-19-2010

I don't believe it ever worked.

Call telco and ask them "can I send ANI of another subscriber" ?

Make sure you customer is present when they answer.

Jonathan Schulenberg · ‎03-22-2010

This does work with UCM; however, be sure that you are clear: ANI (aka Caller ID Number) can be sent to the provider but CNAM (aka Caller ID Name) cannot. Behind the scenes CNAM works entirely different than ANI and providers cannot pass this along with the SS7 data for the call.

For testing, I created translation rules on the gateway to mask CLID on all outbound calls with a number outside the DID range.

In this case the q931 debug showed the call being forwarded with the CLID specified in the translation pattern but on the mobile phone the CLID displayed the first number in the DID range.

This behavior is exactly what happens when the provider is filtering outbound call ANI to the DID range(s) assigned to that circuit.

paolo bevilacqua · ‎03-22-2010

Singularly, users can pass calling name in Canada.

Actually they are better to do so, because apparently, telco will not overwrite a default one.

Nelson Serrao · ‎03-25-2010

Thanks for all the responses. I should have mentioned this earlier that I work for the telco so I spoke to the ISDN group and they werent surprised when I described the problem.

Apparently, originating called id can be presented on the forwarded call if private number re routing is supported. I am guessing this is the terminology they use. My understanding of the situation now is that the earlier solution may have worked because the PABX was doing a blind transfer of the call and hence no problem was faced in presenting the originating ANI.

Incase of CUCM, the call is accepted and another call leg is created for the call to be forwarded. Have verified this using q931 messages. This makes sense because the call needs to be retrieved and sent to voicemail if not answered. Is this right?

Allowing any CLID to be sent on the trunk does have legal implications for obvious reasons but now my thinking is beginning to go wild and am wondering if there is any provision in ISDN to identify a redirected call.

Dont think it exists but am hoping someone would surprise me by proving me wrong. If something like that prevails, it would be easy to convince service providers that originating CLID should be allowed on calls that are redirected. The CLID info of the desk phone would still be there incase calls need to be traced.