I’ve got my Asterisk/FreePBX setup working with two Grandstream HT-503 gateways. The two PSTN lines from Comcast do have Caller ID: it was displaying on the previous system.
I’ve seen notes to configure the HT-503s to transfer after two rings
to give the caller ID info time to insert and I’ve done this.
However still no caller ID display on the phones.
Any ideas on where to look?
If anyone has any ideas, I would really appreciate it. Even though FreePBX can be it own thing I don’t seem to be getting any answers over at their forum and am turning here for help.
I have done a packet capture and sent that off to Grandstream tech support. We have confirmed that CID information is being provided by my HT-503s. Then I was told to look in the asterisk logs for CNAM information. Nothing I can see other than internal device names.
Does anyone have any ideas of where CID information might be filtered or masked? Even if it’s specific to a pure asterisk setup it may get me going in the right direction.
Many thanks.
Caller ID can be overridden in the channel driver configuration file, or the dialplan, but the default is to pass it through.
Channel drivers may support more than one way of signalling caller ID and you may have to configure accordingly.
Is this SIP. If so what is the contents of the From: header you are receiving? What header is carrying the correct caller ID? Are you overriding the From header on the phone side?
Have you checked the setting of trustrpid and sendrpid?
The device is a Grandstream HT-503 using SIP. The from header returned looks like:
From: "Martinez CA" <sip:9253351111@10.0.2.28>;tag=993770341
SIP Display info: "Martinez CA"
SIP from address: sip:9253351111@10.0.2.28
SIP from address User Part: 9253351111
SIP from address Host Part: 10.0.2.28
SIP from tag: 993770341
trustrpid is set to yes and sendrpid is set to no for everything in sip_additional.conf.
Where is chan_sip configured? Does the header above look right for chan_sip?
Unless you have a calerdid line in the incoming sip.conf, you should be capturing it OK, so I would say it most likely something in the dialplan that is breaking it… What actually gets sent in the outgoing From header. Are there any Remote-Party-ID or P-Asserted-Identity headers in the incoming request.
What is the value of ${CALLERID(all) a the start of the dial plan and immediately before the DIal or the AGI that implements the Dial?
I searched the packet capture. No Remote-Party-ID or P-Asserted-Identity headers at all.
Being FreePBX, the dial plans are kinda complex. I’m trying to unwind them and understand what’s going on with my trunks. But I don’t see any CALLERID setting for these trunks. I could be missing one though. I am looking at the “PEER Details” for the trunk I am working with. This sets up the inbound connection:
host=10.0.2.22
username=09253131111
secret=something
type=peer
port=5060
disallow=all
allow=ulaw
dtmfmode=rfc2833
context=from-trunk
trustrpid=yes
sendrpid=no
And is passed to the inbound route. Maybe something here?
What I see on the phone is the Inbound Route description and the DID number. I think I’ll try removing the description and see if that removes the CID being overwritten. However I need the DID number to match the trunk with the Inbound Route. That also happens to be the username.
If username does anyhing at all on a non-dynamic peer, it is likely to break outgoing callerd-ID over From, and require you to use RPID or PAI, if one of those is supported.
I really appreciate all your help on this David. The username is needed in this configuration. My HT-503 sends the call to asterisk using an “unconditional call forward” setting. This is going to a configured extension. That configured extension then rings all the others, in this case through an inbound route and a ring group. So the username is needed to identify the receiving extension.
Thinking about this (and looking through the dialplans at your prompting) I think what I’m seeing on my phones is the Name and Number of the configured extension instead of the CID information sent by the HT-503. Is there any way to get an extension to forward CID information when receiving an external call instead of overwriting it with it’s own identity?
By changing the name of the configured extension I confirmed that, yes, it is the name and number of the extension that is displayed on the phones. I just need to get that removed and get the CID information transmitted from the PSTN line to be allowed through.
I’ve been doing some more work on this. By setting sip debugging on I can reconfirm that caller id information is getting through:
INVITE sip:09253131111@10.0.2.28:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.22:5062;branch=z9hG4bK603400837;rport
Route: <sip:10.0.2.28:5060;lr>
From: "Martinez CA" <sip:9253352222@10.0.2.28>;tag=1605496159
To: <sip:09253131111@10.0.2.28:5060>
Call-ID: 444913955-5062-31@BA.A.C.CC
CSeq: 301 INVITE
The From: line is correct. But then a bit later:
[2016-04-22 14:53:31] VERBOSE[2045][C-00000004] chan_sip.c: Sending to 10.0.2.22:5062 (NAT)
[2016-04-22 14:53:31] VERBOSE[2045][C-00000004] chan_sip.c: Using INVITE request as basis request - 444913955-5062-31@BA.A.C.CC
[2016-04-22 14:53:31] VERBOSE[2045][C-00000004] chan_sip.c: Found peer 'HomeLine' for '9253352222' from 10.0.2.22:5062
[2016-04-22 14:53:31] WARNING[2045][C-00000004] chan_sip.c: username mismatch, have <HomeLine>, digest has <09253131111>
[2016-04-22 14:53:31] NOTICE[2045][C-00000004] chan_sip.c: Failed to authenticate device "Martinez CA"
Something going back to the HT-503 (at 10.0.2.22). Does this look right? I’ve been struggling with these failed to authenticate messages. I had experimented with Privacy Manager but all it did was block calls with this message. I thought I turned it off.
You need to change the section name to match the name the device is actually using, or possibly set authuser.
SOLVED!
Short answer, I was pointing my incoming calls at an extension. Pointing my HT-503s at the trunk that was configured for outbound calls allowed the Caller ID info to display.
So the long version. I was following the wiki page here:
And these instructions do work. You end up with a functional system. But as the page says, caller id has not been addressed. The author has the user create an extensions and then forward incoming calls - the Unconditional Call Forward step - to that extensions. This works but your calls will be formatted as if they are internal calls. The Caller ID information is stripped and replaced with the extension information.
Instead, I deleted those two extensions and pointed my HT-503s to the trunks that I setup. They were setup at port 5062 and interestingly I changed one HT503 to forward to port 6052 but forgot the other and it was still going to port 6050. Both still worked inbound. I think Asterisk was smart enough to match up the username that was setup as long as the unneeded extensions were removed.
I did not configure the “Inbound” portion of the trunk. They both still worked.
Side note, Your trunk needs to have its name set to the same number id string the HT-503 is sending as a user. This needs to be set in both the General page and the SIP Settings page.
I realize this is all pretty FreePBX specific. But hopefully it can provide help to someone stuck in my same rut.
Thank you everyone who gave input. Talking to those with an Asterisk viewpoint is very valuable.
This all sounds like FreePBX stuff as trunk is not a term that Asterisk uses and extension in Asterisk only refers to something that appears in extensions.conf.
Yes, it’s FreePBX. But I still appreciate the help I got here. Diving into all the detailed Asterisk dialplan stuff underlying FreePBX helped me figure out what was going on. Thanks again for your help.
Hey kbocek,
I tried to make changes you suggested but for some reason they do not work. Inbound calls are never realized. The confusing part is the “secret” that you are specifying in FXO port and under Peer Details. What secret do they refer to? Trunks cannot have secrets configured, only extensions.
It seems that because FXO port is not getting registered the forwarding to trunk doesn’t take place. I am using the latest firmware of HT503.
-Melos
Secret is the password.
Asterisk makes no distinction between trunks and extensions.
ITSPs normally require you to give them a password, but will not authenticate themselves to you, and certainly not with the same password. Therefore entries for ITSPs normally require remotesecret, rather than secret, although an older way is with a combination of secret and “insecure = invite”, the latter preventing your requesting the ITSP to authenticate itself.