Troubleshoot Inbound CNAM

The following document will show you how to troubleshoot incorrect inbound CNAM cases. This includes verifying the invite from name from the call trace, ensuring that CNAM dip is working and getting the caller's name resolved from the dip, and checking the caller's name agains openCNAM as a second verification of the caller's name

Requirements

• Access to OpenCNAM
• Call trace without CNAM

As of writing this guideline, the system is using Bandwidth CNAM dip via connection level and it's not using openCNAM. OpenCNAM is used to check caller's name but it doens't mean it matches the CNAM in Bandwidth database.

1. 1
   Speak to the client and get a call trace of the issue, the correct CNAM, and the incorrect CNAM that they saw on their phone.
2. 2
   Open the call trace a click on the first leg.

3. Check the name that the FROM name shows as

1. 1

   If the CNAM on the call trace matches the incorrect CNAM that the client saw, Move to the check OpenCNAM section and verify that the CNAM received in the From sip header matches the CNAM queried from OpenCNAM.

2. 2

   If the CNAM on the call trace does not match the incorrect CNAM that the client saw, check if the phone has a local directory that could be changing the CNAM.

3. 3

   If the CNAM on the call trace matches the correct CNAM that the client provided, there are no issues.

4. 4

   If the CNAM on the call trace does not match the correct CNAM that the client provided, Move to the check OpenCNAM section

   

If CNAM is only affecting the device or certain users then you may be looking at firmware issues.

1. 1
   Check to make sure that CNAM is working. Follow "Check CNAME" from Step 1 to 3.
2. 2
   If the 1st SIP Invite header FROM field doesn't contain the caller's name, then check the CNAM DIP Query which is in the second switch logic of the trace.

CNmsUaSessionStateQueryCname(20210720144326027167)::ProcessSBusEntry - ((SessionKey):(Sa3XzuNZaZuk1VS4261100) (ani):(12392736773) (dnis):(+13053860540) (name):(Schilling Eric))
CNmsUaSessionStateQueryCname(20210720144326027167)::TranslateCname ani=<12392736773> dnis=<+13053860540> CName=<Schilling Eric> Translated CName=<Schilling Eric>

1. 1
   Now check the SIP Invite towards the device if FROM name contains caller's name. If you confirm in Step 2 that the CNAM value is translated to the correct name, then expect that same value to be in the invite towards the device as show below.

INVITE sip:1004@70.230.15.145:1511 SIP/2.0
Via: SIP/2.0/UDP 162.217.10.21:5060;branch=z9hG4bKCdzs36V42oJ8VPMP2611D3
Call-ID: 20210720144326027473-49dafb6eb588d21fef6db82761ff121e
Contact: <sip:162.217.10.21:5060;transport=udp>
CSeq: 201 INVITE
Expires: 120
From: "Schilling Eric" <sip:12392736773@162.217.10.201>;tag=Cdzs36V42oJ8VPMP2611D3

1. 1

   If this SIP invite towards the device doesn't contain the From: <Caller's Name> after you confirm that the CNAM exists via invite or CNAM Dip, then check the device firmware. Update the firmware of the device and Verify the CNAM again.

2. 2

   Log in or create an account on https://opencnam.com

3. 3

   Click on CNAM Delivery.

3. Click on CNAM Query Tool.

4. Enter the caller number.

5. Click on Run CNAM Query.

6. Check the Query result for the CNAM that is being given.

If the CNAM that we received in the call trace is the same as the one that shows up on OpenCNAM then let the client know that we don't control off-net CNAM. The caller would need to update his CNAM with his provider. If the CNAM that we received in the call trace is not the same as the one that shows up on OpenCNAM then escalate the case to T2.