Set outbound Caller ID Name

[Shawn Smith]

Hello All,

     Can CUCM manipulate the Caller ID name that is presented to a called number when calling to the PSTN?  If so is there good documentation on how to do it?  Thanks!

[Jaime Valencia]

You configure that at line level in CUCM.

Not sure exactly what you're trying to do.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[Shawn Smith]

Java,

     I am trying to manipulate the Caller ID Name that Displays out when users go out a certain PRI.  Example user 1, Device pool one uses PRI 1 to call out and it should show "Business 1".  User two, in device pool two uses PRI 2 to call out and it should show "Business 2".  Is there a way in CUCM to accomplish this without relying on Telco?  From what I can tell if I select "Display IE" at the gateway level, it will display the Calling Name associated with each DN.  Is this correct?  Thanks for the help!!

[Jaime Valencia]

Unless you set Business 1 and Business 2 on every single phone line you want to display that CNAM for outbound calls, there is no configuration in CUCM to modify or change the calling name.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[Jonathan Schulenberg · Accepted solution]

I am trying to manipulate the Caller ID Name that Displays out when users go out a certain PRI.  

Your original post said caller ID (i.e. ANI). Now you're talking about Caller ID Name (i.e. CNAM). On the telco side these are two very different things. For example, with ANI you can specify this in the ISDN SETUP or FACILITY IE of an outbound call. The telco switch will copy this value, assuming it matches the filter list applied (i.e. the DIDs you own) to that trunk group, into the SS7 messages for the call. The called party's telco switch will use the ANI value specified in the SS7 message for display purposes unless it is flagged for end-user blocking.

In the case of CNAM this process is very different. CNAM isn't carried in the SS7 messages. The called party's telco switch must perform a database query based on the calling ANI to get the name. This database is not updated in real-time and most telcos set it to the name on the bill. Only the telco can change this and it must be done per TN. Because of this it doesn't matter what you send for CNAM; it won't get passed along anyways*.

*The possible exception is intra-telco calls. In some cases carriers do pass this information inside their own network. If this is the case (the telco will actually advertise this as a feature to you) then you can play some tricks on the gateway. The prerequisite to this trick is doing SIP between CUCM and the gateway. You would then need to create two separate SIP trunks (i.e. separate route patterns and the like) so the router can differentiate between company A and B calls. On the gateway you can use a voice class sip-profile to manipulate the FROM header of the incoming SIP INVITE on the incoming VoIP dial-peer. CUCM will set it to the Alerting Name per-phone; however, you can override it once it gets to the router this way. I believe it would look like this; however, I'm writing this from memory so this may not be exactly correct:

voice class sip-profiles 1

request INVITE sip-header From modify "^\"\([A-Za-z0-9 ]+\)\"[ \t]+\(<.*\)$" "\"COMPANY A\" \2"

! What this is attempting to do is turn this:

! From: “JOHN DOE” <6085550100>;tag=12345

! into this:

! From: “COMPANY A” <6085550100>;tag=12345

! Then apply this to your incoming VoIP dial-peer.

You can keep things separate on the gateway by just prefixing a unique digit sequence on the CUCM route pattern. For example company A's route pattern may prefix 9A while company B prefixes 9B. You can use this to match two unique incoming dial-peers.

[Udit Mehrotra]

Check "Alerting Name" and "ASCII Alerting Name" here -

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/5_0_1/ccmcfg/b03dn.html

Also, a lot depends on your call flow. You might need to allow passing Calling Name at various places such as gateway page on CUCM, ISDN trunks, etc.

HTH

--

Udit

[Shawn Smith]

Udit,

     Thanks for your reply!  I have responded to an earlier reply, to hopefully clear up my question.  Thanks again!

[bifitch]

I would like to do the same thing with overriding the Calling Party Name on outgoing calls and it seems to be a feature missing in both CUCM and in IOS unless you use SIP.

You can remove the Calling Party Name. CUCM will normally send the Alerting Name on a MGCP PRI or H.323. In the Route Pattern under Calling Party Transformations you can set Calling Party Name to Restricted and it sends no name.

In IOS voice translation-rules let you change numbers and dial plans but not the name. The same is true for the serial interface ISDN commands.

[Ayodeji Okanlawon]

Jonathan,

Such an excellent answer. Thumbs up!

[sfriday02]

First of all I think Jonathan's answer is mostly right, but not really... 

1) If a call originates on an IP Phone switch and hasnt yet touched the PSTN, it will exit the  IP-PBX destined for the PSTN on a specific trunk. If there is no callerID attached, then the carrier will pad the Trunk Information associated with that service in all cases, or the BTN as a template on the trunk group on the originating Class4, or Class5 switch. Alternatively the carrier may in fact drop the call if you dont outpulse one (you actually have to do some interop testing with your carrier, but if you use ATT, Verizon, or any of the other regional Bells this is what will happen).

2) On a Site-To-Site call that never has touched the PSTN, it would depend on your pbx what actually gets attached to the signaling. In addition most gatekeepers and SBC's can override or overwrite this information. So ask your sales engineer or account rep for your hardware if you cant find the answer online.

3) IF you call your carrier, they can in fact override the Calling Party Information on all Trunk Groups (IE ATT, Verizon, or Centurylink can do this for you if they dont think you are pulling a fast one... like a Telemarketing scam). IF there is a specific attached number which can be queried from a Local or LD database, then the name associated with that number would then be attached downstream. (IE the carrier has to do this work for you).

For example you might want to map your inboundTF number on outbound calls, so that if someone tries to call you back they will get the right queue.

4) And although information can be passed into message streams upstream, in most cases it wont be, or you shouldnt assume anything, especially for smaller carriers who strip this data intentionally to get around FGD charges.

The rage in the IP Toll Bypass market is to buy flat rate IP trunks into a local market, and then pack it with terminating traffic to bypass specific tarrifs.

5) Which gets us back to SiteToSite Calls...and since I havent tested Jonathan's solution, Im willing to bet he's mostly right in regards to CME, and CUCM.

[sfriday02]

One Caveat... to my answer above... in my experience some carriers charge a premium or AIN feature charge for any special translations... which is why most call centers buy expensive SBCs because they really dont know what the use cases are until they are deep into a project. Acme/Oracle, Avaya, and Sonus can do just about anything either standard, or via special loads or patches which their engineers write... but all the Bellheads can spin a call around the world and bring it back before they hand it to you... so literally it comes down to your account rep. CUBE is essentially an extension of Call Manager so its more or less the same outcome.

[sfriday02]

One more option:

by setting the station-id number 800XXX1234

callerid will work on the remote end... assuming you own the tollfree number.