Force caller-id to be the originally called number?

[voip7372]

CUCM version 14

I've already tried various options to get this to work, using the fields on the directory number (DN), SIP profiles (in CUCM, assigned to the phone and SIP trunk), but so far I haven't found the correct combination of settings to get it to work. Here's what we need...

When someone from an internal phone or an external number (external call that enters via a PSTN SIP trunk - CUBE router) calls a DN assigned to a CTI port that is forwarded to an external number, the user related to that CTI port/DN wants to see their own DN as the calling party number, not the number of the person that's really calling them. I know this is the opposite of what most people normally want to see. The reason for this request is, it's an after hours support number and the on-call person wants to see the support number so it's easy to know it's a call for support and therefore something they should answer quickly. 

I know this can be a bit tricky when dealing with call forwarding and not wanting to affect the caller-id for everyone else that's using call forwarding. There are seemingly lots of places in CUCM during the call flow that can affect the calling party number that's being displayed and trying to find the correct combo of settings to change it ONLY for this one person is my challenge.

So, what would be the most simple, reliable and safe (no affecting other users) way to force the originally called DN to be the number that is always shown as the calling party number (caller-id) for a forwarded call to that number, for just one phone/DN? 

[Jonathan Schulenberg]

Edit: My original suggestion wouldn’t work; I spoke too soon.

A Lua script on the CUCM SIP trunk could probably do this but not many understand that, so difficult to support. Another way is to create a dedicated dial-peer on CUBE for the remote support phone number and use a translation-profile on it to overwrite the calling number.

[voip7372]

Thank you. The other complication is that the number they forward the calls to will change now and then, depending on who's on call. The on call person logs in to the CUCM user page and changes the forwarding number when it's his turn on duty. 

I'll make some test calls to get some call logs in CUBE and see what info is there in the debug and think about maybe using a SIP profile like you mentioned to remove the diversion header or update the number in it, if possible. I was hoping to keep whatever changes we need only inside CUCM and avoid making CUBE changes, but if that's the only way we can make it work, I can live with that.

[b.winter]

In the SIP trunk to CUBE / VGW:
Calling Party Selection --> Last or First Redirect number, whatever suits you better.

[voip7372]

I think that would affect ALL calls out that gateway/trunk, so I really can't use that setting.

[voip7372 · Accepted solution]

I think I figured out a way to do this, in CUBE. I looked at some old notes/working examples of SIP profiles I used in the past for various things and I found one that I could alter to fit this scenario. I made a test call and it works   On my mobile phone when I answer the call, I see the correct +E.164 number as the caller-id when I call the number in CUCM that's forwarded. So just to visualize that. Let's say 82005555 is the internal DN that's forwarded (and the correct +E.164 number related to that DN is +16142225555). The DN is forwarded to 9-1-614-555-1212 for example (external mobile number). When a call comes in for DN 82005555 and it forwards to the an external number, the number shown for caller-id is +16142225555, which is what we want to see. 

Configure new SIP profile to look for any calls with a specific number in the Diversion header (82005555 in my sample).
Then, copy that number in the Diversion header over to the From header.
Finally, replace the modified number in the From header with the correct external +E.164 type number to be presented to the PSTN (so the person receiving the call sees the real number, not the internal 8 digit number, which would be confusing/not look right):
config t
voice class sip-profiles 2
request ANY sip-header Diversion copy "(82005555)" u01
request ANY sip-header From copy "sip:(.*)@" u02
request ANY sip-header From modify "sip:(.*)@" "sip:\u01@"
request ANY sip-header From modify "sip:@" "sip:\u02@"
request ANY sip-header From modify "82005555" "+16142225555"

Apply the new SIP profile to the outgoing dial peers (these outgoing dial peers did not already have a SIP profile applied, fortunately):
dial-peer voice 123 voip
voice-class sip profiles 2

[Maren Mahoney]

Thank you for sharing your solution! It is a good one.

[voip7372]

You're welcome. I know how frustrating it can be when I come here looking for a solution and I think I found one already in the forum, but then there's no detail or not enough detail or explanation and therefore I can't use it. I like to give the details, if it's short enough to share. 

I wish I didn't have to do this in CUBE, but since it's a special purpose and not likely to grow, I'm OK to use it. It would be a lot better though if I could easily do this in CUCM (just for this one DN/user). That would be easier and more visible to the system admins. 

[Maren Mahoney]

Have you examined Single Number Reach (formerly Mobile Connect) as an alternate solution? I'm wondering if there is a way to use the Calling Party Transformation CSS on the Remote Destination Profile to do what you want. If the only number associated with the RDP is the 82005555 number, you could have the Calling Party Transformation CSS capture all caller IDs and change them to +16142225555. I think that would work, but don't have the ability to test it.

SNR can be enabled/disabled in the End User GUI just like call forwarding. And it can be enabled/disabled on the physical handset as well just like CFWDALL. Each user can have their own Remote Destination Profile with the same 82005555 number associated, but different Remote Destinations. 

If the transformation CSS doesn't work like I'm thinking it's a no-go, but it does mean that you'd be doing it in CUCM and not in the CUBE.

Maren

[voip7372]

Edit: removed this comment since the last one I made above is more relevant.

[voip7372]

I did some quick/basic testing using a Remote Destination Profile (RDP) for Single Number Reach (SNR) and a Remote Destination associated with the Remote Dest Profile. I think that will work, as long as you can get CUCM to properly match the 'Calling Party Transformation Patterns' (in Call Routing > Transformation > Transformation Pattern > Calling Party Transformation Pattern).

It seems that if you make the transformation pattern too generic, it doesn't want to match, even if that's the only entry in the partition inside the CSS you're using for the Calling Party Transformation CSS on the Remote Dest Profile. Using the wildcard X to keep the pattern generic, but 'specific' enough to match. For example, I used \+XXXXXXX! and that is enough to match a number like +16141112222 or whatever. In the case I have, I could probably use two patterns to catch the internal calling party numbers like 8XXXXXXX and \+XXXXXXX! to match any external +E.164 type calling party number. I haven't tried this on the cluster where I needed it, but I did try it on the cluster I use every day with with a test phone I already had configured (phone, RDP and remote destination) and it seems to work fine. In the Calling Party Transformation Pattern, I simply add the number I want to see in the 'Calling Party Transformation Mask' field. Now, when I call that phone/number and the Remote Dest Profile/SNR sends the call to the PSTN, I can see the caller-id I wanted to see.  So yeah, I think that's a good idea and should work (just need to be careful to make sure the Calling Party Transformation Pattern you use matches correctly, then it seems OK/works.

[Maren Mahoney]

One thing to note with SNR is that CUCM will want to send the original caller's CLID out to the SNR target. So for this to work for this service call number you'd have to capture all CLIDs and change it to the single desired one (using, as you pointed out, a not-too-generic pattern that still captures everything). This means that SNR could only be used for this purpose and not for a personal line as calls to that line that also ring out to the remote destination would have the CLID overridden. 

So, giving it more thought, if you can't use a trunk-based Calling Party Transformation CSS to convert the specific 82005555 to +16142225555 your solution of doing that in the CUBE is the way to go.

One thing I like about Cisco Unified Communications is that there is usually more than one way to do something, which makes it fun!

Maren

[voip7372]

---

@Maren Mahoney wrote:

One thing I like about Cisco Unified Communications is that there is usually more than one way to do something, which makes it fun!

---

Ha. I've told my colleagues in the past: "The nice thing about CUCM is there are a hundred ways to do the same thing....but the problem with CUCM is, there are a hundred ways to do the same thing." LOL

Overall it's a good thing. We have options. But sometimes the array of options can get confusing. I 'grew up' on Avaya Communication Manager and I can say for sure, once you get to a certain size system, it's much easier to use CUCM because there are lots of call routing/manipulation options that you just can't do in Avaya (since I last worked on it anyway, several years ago).