GXW4104 to FreePBX Caller ID issue


Thanks in advance for any help.

The on-premises setup is: Virgin Media (Chiton Router) connected to GXW4104 which is connected to FreePBX (Virtualbox) with the extensions on GXW4232. FreePBX 16.0.40, Asterisk 19.8.0, PBX Distro 12.7.8-2302-1.sng7. Although, I had the same problem on the older version of Asterisk.

The problem is: GXW4104 is able to detect the Caller ID but it is not passing on the Caller ID to Freepbx. I only know this after inspecting the GXW4104 syslog and Asterisk Log. However, on the Audio Capture page, the Caller ID shows as ‘Unknown’ during the same incoming call.

When I inspect the FreePBX Asterisk Log, the Caller ID is the trunk number.
I have set the Caller ID transport type to option 4 (Relay Via SIP P-Asserted-Identity)
I have tried all Caller ID Schemes and transport types
I have even set up a 5 second pause on the Inbound Route answering the call
The number of Rings Before Pickup is set to 2 but any more than 2 and it just keeps ringing (whish is odd) and so the call is not passed onto FreePBX. However, at 2 Rings Before Pickup it clearly finds the phone number of the incoming caller as I can see it in the syslog of the FXO gateway.

Any idea what’s happening to the Caller ID that I can see in the syslog? I’ve attached screenshots of the syslog.

Thanks again.

Test%20Call !


Check your GXW4104 firmware with what is available on the firmware portal. Check the caller ID on the GXW4104 is set for your expected PSTN CLID. You may need to verify that the Chiton Router is providing CLID to the same that you have set it up - it isnt sending US CLID is it?.

If you can 100% verify that the CLID is being presented as designed and that your settings are correct for the receipt of CLID then send a ticket to:



I had checked and it’s the latest firmware. It is definitely Bellcore/Telcordia. The Caller ID is shown when connected to a phone instead of the gateway. It is also in the Syslog of the GXW4104 at the start of the incoming call but nowhere else in any logs after that point.

My guess is that the call is being connected to the PBX before it finds the Caller ID because when I set the Number of Rings Before Pickup to more than 2, the gateway doesn’t pass the call to the PBX at all. The call is also picked up within 1 ring and not 2. I need a setting that delays the pickup in seconds (rather than number of rings) or a way to send the caller ID after connecting the call to the PBX.

I’ll send a ticket now. Thanks.

Or I would but the website says “We’re sorry but something went wrong. If you are the application owner check the logs for more information.”

I’ll try tomorrow.


Seconds is meaningless. The CID is sent based upon the protocol and the standard is sin227 for the UK. Depending on provider, it could be Bell.

Do a network capture (pcap, not syslog) of a call and examine to see what header is used.


Okay, so the header:
Message Header
Via: SIP/2.0/UDP;branch=z9hG4bKdcf2b4f5cc57f983
P-Asserted-Identity: “” <sip:unknown@>
SIP PAI display info: “”
SIP PAI Address: sip:unknown@
SIP PAI User Part: unknown
SIP PAI Host Part:
From: “”<sip:4002@>;tag=3dd356a51f478930
To: <sip:myphonenumber@>;tag=as240ba0d7
Contact: <sip:4002@;transport=udp>
Call-ID: 0193aa235445c414e8371983fab44274@
[Generated Call-ID:



CSeq: 21763 ACK
User-Agent: Grandstream GXW4104 (HW 2.3, Ch:7)
Max-Forwards: 70
Content-Length: 0

It was also saying unknown on the Audio Capture page on the gateway during the call but I can clearly see the caller ID phone number in the gateway’s syslog as mentioned previously.

I’ll send this to the helpdesk.


The CID is likely 4002. The from header is one that is typically used, but the pcap seems truncated so not sure all is revealed.


The 4002 in the From Header is the GXW4104’s SIP User ID set up in the User Account on the gateway. The only other place that appears is in the Trunk Name on the FreePBX that corresponds to those accounts. I presume it uses that when the Caller ID is unknown as shown in the header. The CID setting fields on the Freepbx inbound routes have been left blank.

I still can’t access helpdesk.grandstream.com for some reason. I’ve tried clearing cookies and resetting password but every time I log in or try to change the password, it says “We’re sorry, but something went wrong.” and “If you are the application owner check the logs for more information.”


I understand what value is there, but From is typical. Others might be PAI or RPID.


I managed to get it fixed by the helpdesk team, they used an older firmware version ( instead of Only took them 10 minutes with a remote connection.

Haven’t tried them all but it also works with different schemes and transport types but has to be set to 4 rings before pickup. I’ve set up a welcome message on the FreePBX to play to customers as it means it takes longer for their call to be answered.


Hello everyone,

I recently encountered a similar issue as discussed in this thread, related to the caller ID on the GXW4104. After reading about the solution found by a user here, I feel even more frustrated with Grandstream’s technical support.

I reached out to Grandstream and was in communication with a representative named Daniel. Despite providing him with all the relevant information, including logs and tests I conducted, the response I received was that “nothing could be done” and suggested the problem was with my provider.

It’s evident, based on this thread and my own experience, that the problem is the same. I’m attaching some relevant logs to corroborate this:
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] FXO_CID: Port: 0 ---------- CID Reporting (FSK)-----------
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] FXO_CID: Port: 0 Date and time: 09200723 (MMDDHHMM)
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] FXO_CID: Port: 0 Number: 9847XXXXX
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] FXO_CID: Port: 0 Redirection from number: 4220XXXX
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] FXO_CID: Port: 0 ---------- CID Reporting (end) ----------
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] FXO_CID: Port: 0 Capture completed. Starts @ 0x80E5DC00 len=0000BB80
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] FXO_CID: Port: 0 Finish cid analysis.
Sep 20 07:24:18 grandstream.localdomain GS_LOG: [00:0B:82:F4:0A:33][000][9660000XXXX][] 400 sip.c Sess: 0 allocated for Port(acct): 0 ln#: 1809 Grandstream GXW4104

I’m glad that some of you have found solutions here, but I wanted to express my complete dissatisfaction with Grandstream’s technical support. It’s unacceptable that, faced with an evident and solvable problem, we are left without an adequate solution.

For those considering Grandstream products in the future, I suggest weighing the quality of technical support before making a decision.



Assistance for any product and brand is limited to providing assistance only on its own products,
you’ve probably had a lack of support from your PBX provider or provider,
therefore you must always check and complete the explanations, giving feedback on the assistance provided by both parties, otherwise the reader will never be able to understand what you are saying.


Thank you for your feedback.

I understand that assistance for any product is typically limited to its own scope. However, my main issue revolves around the Grandstream product itself and its inability to function as expected, especially when other devices have had no issues under the same conditions. My frustration is not solely based on the product’s functionality but also on the responses and guidance I received from Grandstream’s technical support.

While I agree that a complete picture involving all parties is beneficial, my main point of contention here is with the Grandstream device and its support. The references to the PBX or provider are to give context, but the core issue remains with the Grandstream device’s Caller ID functionality.

I’ve been informed multiple times that “nothing can be done”, but evidence from this very forum thread suggests otherwise. This particular issue was resolved for another user, which clearly indicates that a solution is indeed possible.

I urge Grandstream to re-evaluate my situation and provide a solution based on the precedent set in this thread. I have made a significant investment in your product, and I expect it to function as advertised. The evidence suggests that with the right support and guidance, my issue can be resolved.

I appreciate everyone’s input here and look forward to a more comprehensive response from Grandstream.


if that were the case, there would probably be such a quantity of complaints from installers that you would be right,
and I don’t think that’s the case-

In my 37 years of experience, where I still have a lot to learn, I have often solved problems of other installers, where according to them the problem could not be solved, the product had to be thrown away;
eventually with patience I solved it.
Not because I am better than them, but because in my opinion these people have probably chosen the wrong job.

In your case I don’t know anything, and I don’t even want to judge, I’m just saying that it’s not always correct to speak badly of a product without having the right reasons to prove what you say.

That’s all,
Good work.



The individual telling me that the problem cannot be solved is, specifically, a support engineer from Grandstream named Daniel. The Caller ID works flawlessly with my carrier using Digium cards and the Dinstar gateway. The former has broken down after years of use, and the Dinstar has other issues, but not with the Caller ID. I noticed you have a “guru” title for Grandstream on this forum, but I’m unsure if you are directly affiliated with them or not. The device works in all aspects except for sending the caller ID, and the problem is identical to the one described in this forum, as can be seen from the logs I shared. I thought the solution would be a quick fix with a downgrade, but Daniel refused, stating the device was “old”, even though I purchased it just two months ago. I can provide more information if you’re willing to assist in any way. The support team even requested a video showing the Caller ID appearing on an analog phone without issues, and they conducted numerous tests that confirmed my PBX is correctly set up. The issue is that the Grandstream, despite detecting the incoming number in the syslog, sends the analog line number, which is incorrect. Only in the syslog I shared can you clearly see the incoming number, but it’s obviously not practical to rely on logs to identify numbers that should be sent to the PBX and displayed on the final extension. If you have the capability or know someone who can provide a solution, I’m open to discussing it.


you are confusing the forum with Grandstream support,
and it’s not even correct to name names publicly,
he might say the same thing about the way you behave,
I therefore invite you not to start unnecessary controversies,

in case of problems you can report them directly to Grandstream, they will give you the appropriate explanations and answers.


Thank you,


Thank you for your comment, Daniano. It’s essential to understand that my frustration did not arise without reason. I directly reached out to Grandstream’s technical support, as you suggest, and did not receive satisfactory answers. Therefore, I decided to seek help here. I mentioned Daniel because he was my support contact at Grandstream and is relevant to this conversation. I am unaware of his technical skill level; perhaps you know, but he clearly did not show a willingness to help, which reflects poorly on the company as a whole.
My primary goal is to find solutions. As a customer, I have the right to express my dissatisfaction with a product and the support I’ve received. If it was inappropriate to mention names, even if I did not provide surnames, I apologize. However, that does not diminish the validity of the issues I’ve faced.
Instead of focusing on the forum’s procedural matters or defending Grandstream, a company that has so far let me down, it would be more productive to concentrate on the technical problem I’ve outlined. If you’re not in a position or unwilling to assist with the technical situation I’ve described, I would appreciate it if you stated so directly.


@fabianbur Instead of registering the GS Gateway to the Asterisk PBX, have you tried using a softphone as a test to see if everything is normal with the PBX or if it is normal with the Gateway?

Did GS support ask you to try with that approach? This method would slate the issue one direction or the other.

As a customer myself, it can be difficult to gain assistance sometimes from supplier chains and for the reseller to sell you the component should give you the right as a customer to return it to them for money back.


I have several SIP lines in the FreePBX central, all connected to various extensions that work correctly, sending and receiving calls between them. I was asked to change the configuration I had with pjsip trunks to a single SIP trunk. I consider this approach somewhat outdated, but I tried it nonetheless. The result, however, was the same: the caller ID was not being sent correctly. In GS, instead of displaying properly, the analog line number receiving the call appeared, and that same number was incorrectly sent as the caller ID.

We verified that everything was functioning correctly in my phone system, but the support team never wanted to acknowledge this. They also did not accept that there might be an issue with the GS. Their response was that the problem was with my telephony provider, and they suggested trying other providers. This is not an option for me since I need to keep my current numbers.

Additionally, as I mentioned earlier, I tested the caller ID with an analog phone and sent them a video as proof, where it was detected without any issues. Therefore, I cannot understand the inflexibility of the GS support regarding this matter.