Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Tech Tip: Getting the Original Caller ID When Using Mobility / Single Number Reach (SNR)

I've seen several cases about this on TAC and PDI, for both ISDN and SIP, the problem description would be something like:

 

When calling your desk phone (IP Phone) 555-444-3333 from a PSTN number like 555-777-8888 after the configured time the call is forwarded to a cell phone 555-444-7777, so call from 555-777-8888 to 555-444-3333 display on the cell phone as an incoming call from the pilot number of the company 555-111-2222

But would like to have the originating number displayed (555-777-8888).

 

The problem here is that if you take a 'debug isdn q931' or 'debub ccsip messages' from your gateway you will notice that CUCM sends the correct caller ID, but you still see the pilot number of the company on your cell phone, WHY???

 

The answer is that your TELCO will not allow you to 'inject' any caller ID that you want, they will allow you to use the caller ID of one of the numbers that you own, if you send something else then the TELCO will force the main number to be presented.

 

NOW, how do I fix that?

 

Well, there is no 'fix' for this as this is a TELCO policy, they do this mostly for emergency services policies like 911, so the emergency service can get the correct caller ID, BUT, if your TELCO supports the "CLIP - no screening" ISDN feature/supplementary service this will be possible, now this feature means:
CLIP: Calling Line Identification Presentation (Caller ID).
CLIP - no screening: CLIP can be modified by the caller out of the bounds of it's assigned number space.

For SIP, there is no specific feature to support this, you may just send the original caller ID on the 'From' header, or use the 'Diversion Header' to indicate the original caller ID.

 

Now, when using this feature, the TELCO will let you inject any caller ID that you want like 555-555-5555, so it will let you use the original calling number as the caller ID, or any number that you want.

I have seen that some TELCOs either for ISDN or SIP just don't like this, I have seen this a lot with Verizon, even when they say that you just need to use the 'Diversion Header' they keep rejecting the call, and they only accept the call when the call is sent from one of the DIDs.

 


Now, I did some research and found that AT&T supports this feature with the "Legacy S PRI - Original SBC PRI Service" product.

For SIP you need to ask them to enable this.

 

Another possible solution is to get a separate PRI's with disclosure that, this trunk will not be used for emergency purpose. That way service providers will allow them to use a CLID that is different than the numbers they own.

 

In any case, the best practice is that if you are planning to change providers, ask the new provider about this feature and test it BEFORE you change providers, TAC receives a lot of cases about this and the only thing we can do is to either show the cus that we are sending the correct number or change the number for one of the DIDs.

Finally if none of these options are available you could send the number of the phone that were originally called just like if your desk ip phone were calling your cell phone, if you use the settings Calling Party Number "Use Last Redirecting Party (External)" it will use the ip phone external mask number as the calling number.

 

 

 

 HTH.

Christian Nuche.

TAC UC Tech Lead

Version history
Revision #:
1 of 1
Last update:
‎05-13-2014 08:54 AM
Updated by:
 
Labels (1)
Everyone's tags (3)
Comments

Hi,

thank you for your post, I'm facing more or less the same issue, the only difference is that I have a ucce platform, a customer calls a service and the script associated performs a label ( means a transfer ) to a mobile number, we need to display the original calling number on the mobile. We are sending to the provider the original calling number but It replaces It with the main number of the pri. The provider told us that It can enable the service called the no clip screening If we support such service. Now I realized that the answer is yes but I wonder If we have to configure something on the gateway to support the "clip no screening".

We have a Cucm with a sip trunk to the cube and the pstn is a e1 configured with the isdn q931.

Cisco Employee

Hi,

If you are sending the desired CLID info, then you already support that.

At this point your TELCO only needs to stop overwriting the CLID info.

 

HTH.

 

Regards,

Christian Nuche

TAC Eng.