Toggle sidebar Toggle sidebar

Warning 30051 Unidentified Incoming Call. Review INVITE and adjust source identification

Status
Not open for further replies.

PV_Support

Premier Customer
Joined
Jan 20, 2022
Messages
21
Reaction score
8
Using 3CX Flowroute trunk system is in V20. Everything has been working great for years until V20. I have seen several post about this but no solution. The options to adjust the source identification are not available in V20. 3CX, how do you fix this?
 
If you're specifying the 3CX IP address in Flowroute, instead of the 3CX FQDN, that could cause this. Try changing your Flowroute configuration and set the 3CX FQDN instead.
 
That makes things worse. Now all incoming calls rings 1 time then is directed to voicemail.
 
I am using a supported Flowroute trunk that has worked for year on all previous versions. I have looked through all the support and no one has shared an actual solution. Are we stranded now that we have invested so much time and effort with V20 that it does not work to simply accept forwarded calls? This solution has made things worse. Now all calls, including direct calls are ringing once and going to voicemail.
 
The calls are going to your providers voicemail, or a 3CX voicemail?
If it is to a 3CX voicemail, then it would seem that the call is being accepted by the PBX, and I would check the 3CX Activity Log to see why it goes where it does.
 
  • Like
Reactions: edossantos_sipcaller
I believe I have an actual solution, though untested. I will confirm and then share the results because I am not the only one having this issue. 3CX should be more forthcoming with their support of a known issue.

For a Flowroute 3CX trunk to accept calls from a forwarded number the inbound caller ID setting must be just right. We had this issue with previous versions but 3CX made it easy to adjust the inbound parameters.

With the V20 update they intentionally removed the settings from the template that worked and removed access to easily adjust them. You now must download the template, add in what 3CX removed, upload the template, add a new trunk, then re-add your DID's to the trunk and put all the pieces back together since 3CX has removed any way to make this simpler. This may seem easy if you have a few DID's but I have to do this with several hundred.

Here is what needs to be added to the template:
<field name="Source" custom="" parameter="RequestLineURIUser">$LineNumber</field>
<field name="ParameterIn" custom="" parameter="RequestLineURIUser">$CalledNum</field>

I'll confirm this works and share with everyone.
 
  • Like
Reactions: iduncan, MaxDaemon, leejor and 2 others
This did not work. Flowroute was very helpful and did what they could but this is ultimately a 3CX issue.
We spent a couple of days troubleshooting with no improvement. Flowroute finally responded with the following:

In that case I am unsure why this issue would still be occurring. This is a somewhat common issue on 3CX and typically once I provide the two lines of text that I have already provided, which instruct the 3CX to read and identify calls from the Request Line URI, the customer makes the change and it resolves the issue. I know you already mentioned they are not helpful but all I can really suggest at this point is reaching out to 3CX for further support as this is inherently their issue. Someone should be able to assist with adjusting your inbound parameters via the XML file, alternatively I'm not sure if using 3CXV18 is an option as this point but this call source identification setting used to be directly within the UI on this version 18.

We have support with 3CX but they have yet to respond to this known issue with a solution. Our business is suffering since we were forced to update to V20.
 
Have you tried opening a ticket with 3CX? I'm sure you will get this sorted out this way.
 
I'm having the issue and am not getting anywhere. I've been down for 2 days now.
 
TPR3CX said:
I'm having the issue and am not getting anywhere. I've been down for 2 days now.
Click to expand...
BTW, we tried the two lines given above on our test server just in the past hour or two, and it's working for us - on our test server.

We have yet to try it on a 'real' server. Again, as mentioned above, making all those DID reconnects is a royal pain.

We'll likely do it on a small live server tonight and see how that goes.

It would sure be a nice if there was a way to make it simpler than completely rebuilding a trunk.
 
I found the problem but I don't know how to fix it. The issue is that the server has been upgraded and moved to a new public IP address. As it's normally done with upgrading 3CX major versions, we installed the new version (V20), then did a restore from backups. The new server with a public IP of 52.x.x.x is giving an ACK 200 Response with the old IP of 216.x.x.x. There is another thread on her with some who had the same issue but never explained exactly how it was fixed so here we are again. How do I get my shiny new V20 3CX server with public IP 52.x.x.x to stop sending ACKs with the old 2.16.x.x.x public IP?

BTW, since we are on AWS as well, important tip everyone, do not route your PBX traffic through the AWS Firewall. Instead, put your PBX in a subnet where the gateway is an IGW- resource and rely on Security Groups and Network ACLs for firewalling.

With that being said, @KyriacosS_3CX , if you can tell me where on V20 I have to dig into to find that old public IP and change it to the new one, that would be fantastic and I can finally close this issue. It's not in the Trunk config in the admin console. There are two locations in the admin console where the public IP is listed and both have the new IP. it's gotta be buried in a config file somewhere.

Thanks!
 
TPR3CX said:
I found the problem but I don't know how to fix it. The issue is that the server has been upgraded and moved to a new public IP address. As it's normally done with upgrading 3CX major versions, we installed the new version (V20), then did a restore from backups. The new server with a public IP of 52.x.x.x is giving an ACK 200 Response with the old IP of 216.x.x.x. There is another thread on her with some who had the same issue but never explained exactly how it was fixed so here we are again. How do I get my shiny new V20 3CX server with public IP 52.x.x.x to stop sending ACKs with the old 2.16.x.x.x public IP?

BTW, since we are on AWS as well, important tip everyone, do not route your PBX traffic through the AWS Firewall. Instead, put your PBX in a subnet where the gateway is an IGW- resource and rely on Security Groups and Network ACLs for firewalling.

With that being said, @KyriacosS_3CX , if you can tell me where on V20 I have to dig into to find that old public IP and change it to the new one, that would be fantastic and I can finally close this issue. It's not in the Trunk config in the admin console. There are two locations in the admin console where the public IP is listed and both have the new IP. it's gotta be buried in a config file somewhere.

Thanks!
Click to expand...
Just off the top of my head, but if you're running Linux, the IP address will likely have to be changed in the server from the command line. I'm NOT a Linux expert, and have to be told how to get into stuff, but I remember having to do this early on if we moved the server to a different IP.

Anyone - feel free to correct me!
 
MaxDaemon said:
Just off the top of my head, but if you're running Linux, the IP address will likely have to be changed in the server from the command line. I'm NOT a Linux expert, and have to be told how to get into stuff, but I remember having to do this early on if we moved the server to a different IP.

Anyone - feel free to correct me!
Click to expand...
It's a windows 2025 server. That old public IP is buried somewhere and it's being referenced in the ACK responses.
 
TPR3CX said:
It's a windows 2025 server. That old public IP is buried somewhere and it's being referenced in the ACK responses.
Click to expand...
DNS?
 
Hello @KyriacosS_3CX ,
I'm still waiting for a fix on this issue, but after further thought, I believe the issue potentially more serious. It appears that when you do a restore to another system that will have a different IP address, in a high availability configuration where a failover occurs, the secondary machine will not be able to accept calls because it will be sending out ACK replies with the IP address of the primary, hence potentially no failover at all.

This is what FlowRoute gave showing my 3CX V20 in AWS with IP address 52.xxx.xxx.xxx sending out as ACK replies...

SIP/2.0 200 OK

Via: SIP/2.0/TLS 34.226.36.35:5061;branch=z9hG4bK49fe.ab29adba2fb67aba77737bd2aed90324.0
Require: timer

Contact: "Spiro Balourdos"

To: sip:[email protected] ;tag=26568d48
From: "REDACTED" sip:[email protected] ;tag=gK0c663005

Call-ID: [email protected]

CSeq: 726407 INVITE
Session-Expires: 21600;refresher=uac
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Content-Type: application/sdp
Supported: replaces, timer
User-Agent: 3CXPhoneSystem 20.0.6.724 (724)
Content-Length: 284

v=0
o=3cxPS 295077675008 540427681793 IN IP4 216.xxx.xxx.xxx <-THIS IS THE IP OF THE OLD SERVER WHICH IS TURNED OFF IN MY DATA CENTER

s=3cxPS Audio call
c=IN IP4 216.xxx.xxx.xxx <-THIS IS THE IP OF THE OLD SERVER WHICH IS TURNED OFF IN MY DATA CENTER
t=0 0
m=audio 9014 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=sendrecv
========================================================
 
@KyriacosS_3CX is there a way we can get some sort of escalation? My 3CX partner has even opened a case with 3CX and have not received any responses.
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,980
Messages
590,104
Members
164,908
Latest member
FarizQasimov
3CX Logo Footer Copyright © Sitemap Privacy
Top Bottom