No CNAM on Outbound caller id. Only CNUM and location (City, State)

I’m using Bandwidth that required the Contact header and add a p-asserted-identity header to the INVITE with your caller ID information. The receiving end see the phone number and city, state. no CNAM

My setup
Extension > Advance > Send RPID: "Send P-Asserted-Identity Header
Trunk > Sip Settngs > peer details > sendrpid=pai
Settings > Advance Setting > Sip Sendrpid: pai
Settings > Astrisk SIP Setting > Sip Setting (chan_pjsip) > Caller ID into Contact Header: Yes
I’m testing on both pjsip and sip extensions

I tried setting the caller ID on Extension, Outbound or Trunk (not all at the same time)
Extension > Outbound CID “myname”<9165551212>
Route > Router CID: “myname”<9165551212> & Overide Extension: Yes
Trunk > Outbound CallerID: “myname”<9165551212> & CID Options: Force Trunk CID
Same result. It only show the phone number, city and state

One thing I’ve notice (line #16 below)
From: “PBX1 101” sip:[email protected]
While the Outbound CID on the extension is set for “myname”<9165551212>
PBX1 is the server host name and 101 is the extension
Extension 101 display name is “MyName”

How do I change “PBX1 101” <sip:[email protected]… to “myname”<[email protected]

00 INVITE sip:[email protected]:5160 SIP/2.0
01 SIP/2.0 401 Unauthorized
02 ACK sip:[email protected]:5160 SIP/2.0
03 INVITE sip:[email protected]:5160 SIP/2.0
04 SIP/2.0 100 Trying
05 SIP/2.0 183 Session Progress
06 OPTIONS sip:[email protected]:5060 SIP/2.0
07 SIP/2.0 200 OK
08 SIP/2.0 200 OK
09 ACK sip:10.0.0.101:5160 SIP/2.0
10 BYE sip:[email protected]:5060 SIP/2.0
11 SIP/2.0 200 OK

12 pbx1*CLI> pjsip show history entry 0
13 <— History Entry 0 Received from 10.0.0.18:5060 at 1652306908 —>
14 INVITE sip:[email protected]:5160 SIP/2.0
15 Via: SIP/2.0/UDP 10.0.0.18:5060;received=10.0.0.18;branch=z9hG4bK4071026270
16 From: “PBX1 101” sip:[email protected];tag=2104256583
17 To: sip:[email protected]
18 Call-ID: [email protected]
19 CSeq: 1 INVITE
20 Contact: sip:[email protected]:5060
21 Content-Type: application/sdp
22 Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
23 Max-Forwards: 70
24 User-Agent: Yealink SIP-T27P 45.82.0.30
25 Allow-Events: talk,hold,conference,refer,check-sync
26 Supported: replaces
27 Content-Length: 286
28 Content-Type: application/sdp
29 Content-Length: 286

Thanks

In the US, the traditional (TDM) PSTN transmitted only the calling number. The terminating carrier looked up the number in a distributed Line Information DataBase (LIDB). Most calls still work that way, though when a call goes IP end-to-end, the name is taken from the appropriate SIP header. So, to cover all cases, you have to set both.

Bandwidth has an API to set the LIDB:

You can probably also set it from the web portal, though I’m not a Bandwidth customer and don’t know the details. Of course, both of these only apply to numbers you purchased from Bandwidth.

Stewart,

The LIDB is setup, it works and confirmed. Bandwidth recommend Contact header, and if possible add a p-asserted-identity header to the INVITE with caller ID information. This ensure that under normal circumstances the caller ID will be displayed.

Your first post shows SIP only to/from the extension. What would be more useful is SIP to/from the trunk, in particular the INVITE sent to the trunk. Confirm that both the From and PAI headers have the desired caller name. It might take some work to get it in Contact, as that is non-standard.

A useful test is calling e.g. an AT&T or Verizon landline, which would almost certainly be querying the LIDB. If it shows only City/State, the LIDB probably did not get set correctly. You could also check the LIDB at e.g. Twilio (or any other provider with a reliable lookup service and not using Bandwidth).

Stewart

That is exactly what I’m trying to figure out. How to get it in Contact.

LIDB works and confirmed. I called an AT&T and Bandwidth and it shows the name and number. I also test it using calleridtest.com and it also shows the name and number.

But when I called Verizon Cell or T-mobile, I only see number , State and City.
It is my understanding not all term carrier pull the CNAM from LIDB.

For a test, set Contact User on a pjsip trunk, confirm with pjsip logger that the header is as Bandwidth wants and see what VZW shows. If you still don’t see the name, IMO Bandwidth gave you BS; ask them for a better solution, if one exists. If the test succeeds, write a predial hook to set Contact dynamically.

What should I put on the Contact Users on the pjsip trunk…
Should I put “myname”<9165551212>?

It would be so unusual for the Contact header to include a display name that it may well not be supported. Even the contact user setting is only there because providers abuse SIP. From the point of view of the SIP protocol, the user part of the Contact header is only meaningful to the entity sending it.

The normal abuse of the Contact header is to contain the account name, not a caller ID.

As pointed out, you only provided the detailed trace for the wrong INVITE, so you need to provide the INVITE from Asterisk to Bandwidth. My suspicion is that your reference to PBX1 101 is based on the false premise that you are looking at the correct INVITE. Your summary trace does not appear to include the correct INVITE at all, otherwise I would have told you the line number. Also, it helps to provide these traces from the Asterisk logs.

As has already been pointed out, you may also have unrealistic expectations about the PSTN.

David, is this the correct invite info from asterisk to bandwidth

On this example the caller ID is set on the extension
“myname” <9165551212

Line 7734 it shows From: “PBX1 101” (PBX1 is the server and 101 is the extension
Line 7767 show the same as 7734
Line 7938 shows From: “myname” sip:[email protected]
Line 7947 shows P-Asserted-Identity: “myname” <sip:[email protected]
Line 7943, 7983 show the same as 7938

7731 [2022-05-15 02:05:00] VERBOSE[2737] res_pjsip_logger.c: <— Received SIP request (1151 bytes) from UDP:10.0.0.18:5060 —>
7732 INVITE sip:[email protected]:5160 SIP/2.0
7733 Via: SIP/2.0/UDP 10.0.0.18:5060;branch=z9hG4bK2681100091
7734 From: “PBX1 101” sip:[email protected]:5160;tag=496803802
7735 To: sip:[email protected]:5160
7736 Call-ID: [email protected]
7737 CSeq: 2 INVITE
7738 Contact: sip:[email protected]:5060
7740 Content-Type: application/sdp
7741 Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
7742 Max-Forwards: 70
7743 User-Agent: Yealink SIP-T27P 45.82.0.30
7744 Allow-Events: talk,hold,conference,refer,check-sync
7745 Supported: replaces
7746 Content-Length: 286
7747
7748 v=0
7749 o=- 20158 20158 IN IP4 10.0.0.18
7750 s=SDP data
7751 c=IN IP4 10.0.0.18
7752 t=0 0
7753 m=audio 12428 RTP/AVP 0 8 18 9 101
7754 a=rtpmap:0 PCMU/8000
7755 a=rtpmap:8 PCMA/8000
7756 a=rtpmap:18 G729/8000
7757 a=fmtp:18 mode=20
7758 a=rtpmap:9 G722/8000
7759 a=sendrecv
7760 a=rtpmap:101 telephone-event/8000
7761 a=fmtp:101 0-15
7762
7763 [2022-05-15 02:05:00] VERBOSE[2738] res_pjsip_logger.c: <— Transmitting SIP response (296 bytes) to UDP:10.0.0.18:5060 —>
7764 SIP/2.0 100 Trying
7765 Via: SIP/2.0/UDP 10.0.0.18:5060;rport=5060;received=10.0.0.18;branch=z9hG4bK2681100091
7766 Call-ID: [email protected]
7767 From: “PBX1 101” sip:[email protected];tag=496803802
7768 To: sip:[email protected]
7769 CSeq: 2 INVITE
7770 Server: FPBX-15.0.23(16.17.0)
7771 Content-Length: 0
7772
7773
7936 INVITE sip:[email protected] SIP/2.0
7937 Via: SIP/2.0/UDP 73.220.172.215:5160;rport;branch=z9hG4bKPj5a6c2646-a92a-4ac0-8315-906d8d5c326e
7938 From: “myname” sip:[email protected];tag=241ef512-5e4e-4a9b-ac32-3eb2f11826e5
7939 To: sip:[email protected]
7940 Contact: sip:[email protected]:5160
7941 Call-ID: a7179b9a-536d-43e8-8739-09edb2e444f3
7942 CSeq: 11919 INVITE
7943 Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
7944 Supported: 100rel, timer, replaces, norefersub, histinfo
7945 Session-Expires: 1800
7946 Min-SE: 90
7947 P-Asserted-Identity: “myname” sip:[email protected]
7948 Max-Forwards: 70
7949 User-Agent: FPBX-15.0.23(16.17.0)
7950 Content-Type: application/sdp
7951 Content-Length: 341
7952
7953 v=0
7954 o=- 577021793 577021793 IN IP4 73.220.172.215
7955 s=Asterisk
7956 c=IN IP4 73.220.172.215
7957 t=0 0
7958 m=audio 12928 RTP/AVP 0 8 9 3 111 101
7959 a=rtpmap:0 PCMU/8000
7960 a=rtpmap:8 PCMA/8000
7961 a=rtpmap:9 G722/8000
7962 a=rtpmap:3 GSM/8000
7963 a=rtpmap:111 G726-32/8000
7964 a=rtpmap:101 telephone-event/8000
7965 a=fmtp:101 0-16
7966 a=ptime:20
7967 a=maxptime:150
7968 a=sendrecv
7969
7970 [2022-05-15 02:05:01] VERBOSE[2737] res_pjsip_logger.c: <— Received SIP response (341 bytes) from UDP:67.123.123.123:5060 —>
7971 SIP/2.0 100 Trying
7972 Via: SIP/2.0/UDP 10.0.0.101:5160;branch=z9hG4bKPj5a6c2646-a92a-4ac0-8315-906d8d5c326e;rport=5160
7973 From: “myname” sip:[email protected];tag=241ef512-5e4e-4a9b-ac32-3eb2f11826e5
7974 To: sip:[email protected];tag=gK0ca47c4e
7975 Call-ID: a7179b9a-536d-43e8-8739-09edb2e444f3
7976 CSeq: 11919 INVITE
7977 Content-Length: 0
7978
7979
7980 [2022-05-15 02:05:02] VERBOSE[2737] res_pjsip_logger.c: <— Received SIP response (789 bytes) from UDP:67.123.123.123:5060 —>
7981 SIP/2.0 183 Session Progress
7982 Via: SIP/2.0/UDP 10.0.0.101:5160;branch=z9hG4bKPj5a6c2646-a92a-4ac0-8315-906d8d5c326e;rport=5160
7983 From: “myname” sip:[email protected];tag=241ef512-5e4e-4a9b-ac32-3eb2f11826e5
7984 To: sip:[email protected];tag=gK0ca47c4e
7985 Call-ID: a7179b9a-536d-43e8-8739-09edb2e444f3
7986 CSeq: 11919 INVITE
7987 Contact: sip:[email protected]:5060
7988 Allow: INVITE,ACK,CANCEL,BYE,OPTIONS
7989 P-Asserted-Identity: tel:+19161234567
7990 Content-Length: 230
7991 Content-Disposition: session; handling=required
7992 Content-Type: application/sdp
7993
7994 v=0
7995 o=Sonus_UAC 873683 24523 IN IP4 67.231.4.7
7996 s=SIP Media Capabilities
7997 c=IN IP4 67.231.4.7
7998 t=0 0
7999 m=audio 43944 RTP/AVP 0 101
8000 a=rtpmap:0 PCMU/8000
8001 a=rtpmap:101 telephone-event/8000
8002 a=fmtp:101 0-15
8003 a=sendrecv
8004 a=ptime:20

I’m still not getting outbound CallerID. Does this log match with what Bandwidth is saying that "they saw that the From header had “myname” on it, but the Contact header only had the originating number.

I appreciate lettings me know that I was looking at the wrong header info. I hope I got the right info this time.

This is the one, although I have had to correct some things which are I think the result of your not marking it up as pre-formatted text, rather than errors in the actual message. I’ve left out the SDP, as it is not relevant here.

Assuming “myname” is what you want as CNAM, this is correct, and your problem is most likely fundamental to the use of the PSTN, and cannot be resolved for a PSTN destination.

My caller ID was set to “myname” <9165551212>
As soon as I remove the space between " & < the format looks a lot better
But I’m still not getting caller ID CNUM.

(01)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 73.220.173.49:5160;rport;branch=z9hG4bKPj7e8bef55-7140-47eb-94ef-fbb3c7e37695
From: “myname” <sip:[email protected]>;tag=50d61ae3-ceab-4a6d-b4f1-a75a5dd93b88
To: <sip:[email protected]>
Contact: <sip:[email protected]:5160>
Call-ID: ed274f88-5313-46b5-973a-0c93370d9a8b
CSeq: 15335 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: “myname” <sip:[email protected]>
Max-Forwards: 70
User-Agent: FPBX-15.0.23(16.17.0)
Content-Type: application/sdp
Content-Length: 341

(02)
[2022-05-15 21:26:44] VERBOSE[2839] res_pjsip_logger.c: <— Received SIP response (341 bytes) from UDP:67.123.123.123:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.101:5160;branch=z9hG4bKPj7e8bef55-7140-47eb-94ef-fbb3c7e37695;rport=5160
From: “myname” <sip:[email protected]>;tag=50d61ae3-ceab-4a6d-b4f1-a75a5dd93b88
To: <sip:[email protected]>;tag=gK0cb60307
Call-ID: ed274f88-5313-46b5-973a-0c93370d9a8b
CSeq: 15335 INVITE
Content-Length: 0

(03)
[2022-05-15 21:26:46] VERBOSE[2839] res_pjsip_logger.c: <— Received SIP response (790 bytes) from UDP:67.123.123.123:5060 —>
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.0.0.101:5160;branch=z9hG4bKPj7e8bef55-7140-47eb-94ef-fbb3c7e37695;rport=5160
From: “myname” <sip:[email protected]>;tag=50d61ae3-ceab-4a6d-b4f1-a75a5dd93b88
To: <sip:[email protected]>;tag=gK0cb60307
Call-ID: ed274f88-5313-46b5-973a-0c93370d9a8b
CSeq: 15335 INVITE
Contact: <sip:[email protected]:5060>
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS
P-Asserted-Identity: <tel:+19163978509>
Content-Length: 231
Content-Disposition: session; handling=required
Content-Type: application/sdp

Is this normal under (03) SIP/2.0 183 Session Progress
The P-Asserted-Identity: was change to just number

Based on the above log, is it more likely the issue is with Bandwidth and there nothing I can do on the PBX server?

You were originally complaining that it was setting CNUM but not CNAM. Which is it.

Asterisk is handling your caller ID settings correctly. The lack of CNAM at the destination is a limitation of the PSTN.

Yeah, I thought this was about CNAM not displaying. You cannot control the terminating carrier’s logic on doing CNAM lookups in a national database.

If your calls are display city, st to callers then that means you haven’t submitted CNAM to the LIDBs for people to get a name when they do a CNAM dip.

Not every carrier honors what CNAM is presented to them automatically.

Sorry about the typo. I meant name “CNAM”

LIDB is configure and it show the correct CNAM and CNUM

But like what you said, I can not control the terminating carrier’s logic on doing CNAM lookups so I was trying to do is make sure I covered both LIDB and header.
Which I think I already do and it’s really now the limitation of the PSTN.

Possibly, VZW doesn’t provide proper CNAM to all accounts. Please confirm that a call from e.g. an AT&T landline to a VZW phone does display the correct name, while your Bandwidth call to the same phone does not. Of course, be sure that neither number is in the destination phone’s contacts.

VZW Caller-ID Name is only available on certain wireless devices and by subscription only on those. See: Verizon Caller Name ID

In many cases, the calling name will appear only if you have it stored in your contact list.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.