Your name please…

One of the woes we voice engineers deal with on nearly every deployment is the compelling need users have to not only see the calling number of the individual bothering them via telephone, but also the name.  I assume this is so they can add the names of the really annoying callers to a list that gets mailed to the North Pole every December.  (hey, those telemarketers deserve that coal they get in their stockings, no question about it…)

While every deployment is different and I am far too lazy to outline every possible configuration for calling name to show up for users, I will highlight the importance of the command set below being in the router configuration if you are dealing with H323 gateways, calling name is being delivered in the Facility IE, and your inbound calling name isn’t being displayed on the phone*:

voice service voip
h225 display-ie ccm-compatible

How will you know you need this command set?

Well, let’s say you’ve done your due diligence and confirmed with the carrier that calling name *is* being sent. Please don’t skip this step, you will beat your head against your desk until unconscious when you find you’ve been troubleshooting a calling name issue for days and the customer never ordered the service on the line.

Let’s say you have also confirmed, with my favorite debug of all time debug isdn q931, that you are seeing calling name in the debug.  In some cases, like the one we are discussing, calling name may be coming in the Facility IE, and you should see it clearly in the debug**.  It will look something like this:

RX <- FACILITY pd = 8  callref = 0x018C
Facility i = 0x9F8B0100A117020101020100800F41524E4F4C4420414D592020202020
Protocol Profile =  Networking Extensions
Component = Invoke component
Invoke Id = 1
Operation = CallingName
Name Presentation Allowed Extended
Name = AMY

Typically if you have gotten this far and your inbound calling name is still not showing, you are nearly there.  Adding the aforementioned h225 display-ie ccm-compatible command should do the trick.

Note that if you are dealing with a gateway running really old IOS, you may not see this command available.  You’ve got to be on at least version 12.4(20)T or else you will be one sad panda. Once you enter these commands, you’ll not only see calling name in the debugs, but your customer should see it on the phone as well and think you are a miracle worker, as we voice engineers often are.

*If you love yourself you’ll be dealing with H323 voice gateways and not MGCP. MGCP, however, does have some nifty check boxes to get  Facility IE calling name working – however, that remains material for another blog post.

**If you don’t see calling name in the debug, then you likely need to enter a few commands to make the Facility IE delivery work. Your serial interface should look something like this:

interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn supp-service name calling
isdn outgoing display-ie

Try the above commands if you are seeing something like the debug output below. Also be certain that your switch type supports Facility IE, not all switch types do. On a related note, switch type must be agreed upon between yourself and the carrier, don’t believe you can change one end and the other end will just work. It’s voice mind you, rarely do things just *work*…

Facility i = 0x9F8B0100A11D02010106042B0C0900801254656C65547261636B204F7574626F756E64
Protocol Profile =  Networking Extensions
Component = Invoke component, Unsupported operation

***Additional FWIW – I recently did an upgrade from 6.1 to 8.6 and inbound calling name wasn’t a problem on 6.1 without the ccm-compatible command, but after the upgrade calling name only worked with this command added. I also found this link from 2010 to helpful when troubleshooting this type of issue:

Published March 3/26/2013

11 thoughts on “Your name please…

  1. The longish hex strings in the Facility IE data represents the ascii character codes of the calling name. Just a heads up that what appears to be your full name is in there in case you didn’t intend for that.

  2. A long time since your last post! So glad i’ve been checking back regularly! It’s these kind of ‘not a problem until you have them’ type posts that are the most useful. Thx 🙂

  3. Interesting…
    I used the following on my H323 gateway when it didn’t work:
    voice service voip
    h225 timeout ntf 575

    I had to play with the timer number, but ‘ntf’ worked for me.

    I like your way better though. Will have to try it. 🙂

    1. this is great, I need something to try for a customer that has a 3725 that can’t upgrade to an IOS high enough. Maybe this will help.

  4. I am implementing this soon. Can you post the config for MGCP? Voice Gateway is 2921 Router

    1. Ken, you need to be sure you are using a switch type that supports Calling Name in the facility IE and then on the PRI configuration in Call Manager, look for PRI Protocol Type Specific Information and check the boxes for Display IE Delivery and Send Calling Name in Facility IE.

  5. Good tip. I was searching for a solution to my problem and got to know this post.

    The problem i face with the FXO setup is, calling NUMBER is showing in the “debug vpm signal” and also in ”debug voip ccapi in out” in the voice gateway but yet the CIPC/7941 registered to CUCM shows UNKNOWN NUMBER. Traces collected from CUCM suggests no ANI received.

    Hope there is no version comparability….Any help on what i should be looking at ?

    (Ext 3008)7941/CIPC — MGCP — CUCM6 — h323 — 1751v — FXO — Incoming

    Yes very old 1751v VG 🙂 with IOS : 12.4(25d)
    CUCM – (Prefer version 6 as it uses low CPU resource running in vmware)

    debug vpm signal :
    *Mar 1 12:37:22.731: [2/0] get_fxo_caller_id:Caller ID received. Message type=129 length=15 checksum=44
    *Mar 1 12:37:22.731: [2/0] Caller ID String 43 43 39 31 39 36 39 3x 3x 3x 3x 34 39 39 44
    *Mar 1 12:37:22.731: [2/0] get_fxo_caller_id calling num=CC919698191499D calling name=
    debug voip ccapi in out :

    *Mar 1 12:48:31.079: //9/77EF0EE3800E/CCAPI/cc_api_display_ie_subfields:
    —– ccCallInfo IE subfields —–
    cisco-ani=CC91969xxxx499D —–> have masked my number 🙂

  6. This helped me for the opposite reason! I had a customer who could not send outbound faxes…the crazy thing is it worked up until a certain point and nothing changed on the GW.

    I ran a debug isdn q931 on a working and non working site….realized the non working site had the Facility ID etc….

    A google search led me here —- I REMOVED supp-service name calling and voila…faxes are flowing.

    Still don’t know what caused it to STOP working in the first place, but that is a battle for another day

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s