Incoming call issue

[MaxDaemon]

I've spent hours searching and trying to find a logical reason for this happening. Basically, we have had thousands of successful calls in the past year, but suddenly we have one single customer (on our mult-tenant) that can't receive calls from one single vendor.
My SIP provider swears it's something wrong with our configuration, and I don't know enough to argue with her. It so happens that my SIP provider is also my company, so it's better and worse.

The redacted info:
07/30/2025 11:48 AM
Unidentified Incoming Call. Review INVITE and adjust source identification:. INVITE sip:[email protected]:5060 SIP/2.0. Via: SIP/2.0/UDP xxx.xxx.29.169:5060;branch=z9hG4bK00Bcf0cdff1b77fdd6e. Max-Forwards: 70. Contact: "<calling company>"<sip:[email protected]:5060>. To: <sip:[email protected]>. From: "<calling company>" <sip:[email protected]>;tag=gK0018ce9c. Call-ID: [email protected]. CSeq: 26073 INVITE. Session-Expires: 1800. Min-SE: 90. Accept: application/sdp. Allow: INVITE, ACK, CANCEL, BYE, REGISTER, REFER, INFO, SUBSCRIBE, NOTIFY, UPDATE, OPTIONS, MESSAGE, PUBLISH. Content-Disposition: session; handling=required. Content-Type: application/sdp. Supported: timer, replaces. Privacy: none. P-Asserted-Identity: "<calling company>" <sip:[email protected];user=phone>. Remote-Party-ID: "<calling company>" <sip:[email protected];user=phone>;party=calling;privacy=off. Diversion: <sip:[email protected]:5060>;privacy=off;screen=no;reason=unknown;counter=1. Content-Length: 239. v=0. o=Sonus_UAC 271645 301691 IN IP4 xxx.xxx.29.169. s=SIP Media Capabilities. c=IN IP4 xxx.xxx.29.169. t=0 0. m=audio 43670 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=ptime:20

It kinda looks to me like we're diverting it and sending it back around, and it's not being accepted the second time. I'm willing to disable source identification, at least as a test, but can't find how to do that on v20.

I'm in hopes one of you big brains will have some suggestions.

Thanks in advance!

<added on edit> I also have a CallCentrics test trunk that if this vendor calls using that incoming trunk, it works fine. Just adding to the mix. The CallCentrics is purely for testing, though.

 

[YiannisH_3CX]

Hello @MaxDaemon

Unidentified Incoming Call. Review INVITE and adjust source identification:. INVITE

The error is pretty straight forward. The call source identification cannot match the inbound call to a trunk so the call fails.
You need to review the call source identification settings of the trunk using the invite message and see where the mistake is.
You can export the trunk settings, make your adjustments and import it back in.

If this started suddenly then either the provider changed something that broke call source identification or a second trunk was added with the same settings which clashes with this one. That would be the first things to check.

 

[iduncan]

is there a way to disable call source identification? I cant seem to find any documentation on how to do this.

 

[YiannisH_3CX]

The PBX will always try to perform call source identification one way or another so if you remove it from the template then you must be sure that your DIDs match the dialed numbers exactly.
You can export the template, fine the line that looks like this and delete it.

<field name="Source" custom="" parameter="ContactHost">$GWHostPort</field>

Then save the template, delete the existing trunk and navigate to Advanced--> Templates--> Provider Templates--> Import Provider and add the trunk again using the modified template.

 

[KyriacosS_3CX]

Could you share the SIP INVITE of a successful call vs a failed one? This might be something that can be tuned. Any possibility the specific DID of that tennant was added to more than one trunk?

 

[iduncan]

Could you share the SIP INVITE of a successful call vs a failed one? This might be something that can be tuned. Any possibility the specific DID of that tennant was added to more than one trunk?

We only have 1 trunk going into the PBX. Are you looking for the invite message we can find from 3cx, or are you looking for the invite from a pcap file from a capture?

 

[KyriacosS_3CX]

INVITE from PBX logs or pcap should be identical. Any would do. Just want to see what if any are the differences between an INVITE from a call that works OK vs one that doesn't are.

 

[iduncan]

Failed inbound call:
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:[REDACTED_CALLED_NUMBER]@[REDACTED_DST_IP]:5060 SIP/2.0
Method: INVITE
Request-URI: sip:[REDACTED_CALLED_NUMBER]@[REDACTED_DST_IP]:5060
Request-URI User Part: [REDACTED_CALLED_NUMBER]
Request-URI Host Part: [REDACTED_DST_IP]
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP [REDACTED_SRC_IP]:5060;branch=z9hG4bK[REDACTED_BRANCH]
Transport: UDP
Sent-by Address: [REDACTED_SRC_IP]
Sent-by port: 5060
Branch: z9hG4bK[REDACTED_BRANCH]
From: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP]>;tag=[REDACTED_TAG]
SIP from display info: "[REDACTED_NAME]"
SIP from address: sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP]
SIP from address User Part: [REDACTED_CALLER_NUMBER]
SIP from address Host Part: [REDACTED_DST_IP]
SIP from tag: [REDACTED_TAG]
To: <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP]>
SIP to address: sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP]
SIP to address User Part: [REDACTED_CALLER_NUMBER]
SIP to address Host Part: [REDACTED_DST_IP]
Call-ID: [REDACTED_CALL_ID]@[REDACTED_SRC_IP]
[Generated Call-ID: [REDACTED_CALL_ID]@[REDACTED_SRC_IP]]
CSeq: [REDACTED_CSEQ] INVITE
Sequence Number: [REDACTED_CSEQ]
Method: INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,UPDATE,OPTIONS,MESSAGE,PUBLISH
Contact: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_SRC_IP]:5060>
SIP C-URI display info: "[REDACTED_NAME]"
Contact URI: sip:[REDACTED_CALLER_NUMBER]@[REDACTED_SRC_IP]:5060
Diversion: <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_SRC_IP]:5060>;privacy=off;screen=no;reason=unknown;counter=1
P-Asserted-Identity: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP];user=phone>
SIP PAI display info: "[REDACTED_NAME]"
SIP PAI Address: sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP];user=phone
SIP PAI User Part: [REDACTED_CALLER_NUMBER]
SIP PAI Host Part: [REDACTED_DST_IP]
SIP PAI URI parameter: user=phone
Privacy: none
Remote-Party-ID: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP];user=phone>;party=calling;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (remote-party-id)]
[Unrecognised SIP header (remote-party-id)]
[Severity level: Note]
[Group: Undecoded]
Accept: application/sdp
Supported: timer,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 239
Content-Disposition: session; handling=required
Content-Type: application/sdp
Message Body

 

[iduncan]

successful inbound call:
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:[REDACTED_CALLED_NUMBER]@[REDACTED_DST_IP]:5060 SIP/2.0
Method: INVITE
Request-URI: sip:[REDACTED_CALLED_NUMBER]@[REDACTED_DST_IP]:5060
Request-URI User Part: [REDACTED_CALLED_NUMBER]
Request-URI Host Part: [REDACTED_DST_IP]
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP [REDACTED_SRC_IP]:5060;branch=z9hG4bK[REDACTED_BRANCH]
Transport: UDP
Sent-by Address: [REDACTED_SRC_IP]
Sent-by port: 5060
Branch: z9hG4bK[REDACTED_BRANCH]
From: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP]>;tag=[REDACTED_TAG]
SIP from display info: "[REDACTED_NAME]"
SIP from address: sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP]
SIP from address User Part: [REDACTED_CALLER_NUMBER]
SIP from address Host Part: [REDACTED_DST_IP]
SIP from tag: [REDACTED_TAG]
To: <sip:[REDACTED_CALLED_NUMBER]@[REDACTED_DST_IP]>
SIP to address: sip:[REDACTED_CALLED_NUMBER]@[REDACTED_DST_IP]
Call-ID: [REDACTED_CALL_ID]@[REDACTED_SRC_IP]
[Generated Call-ID: [REDACTED_CALL_ID]@[REDACTED_SRC_IP]]
CSeq: [REDACTED_CSEQ] INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,UPDATE,OPTIONS,MESSAGE,PUBLISH
Contact: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_SRC_IP]:5060>
SIP C-URI display info: "[REDACTED_NAME]"
Contact URI: sip:[REDACTED_CALLER_NUMBER]@[REDACTED_SRC_IP]:5060
P-Asserted-Identity: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP];user=phone>
SIP PAI display info: "[REDACTED_NAME]"
SIP PAI Address: sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP];user=phone
Privacy: none
Remote-Party-ID: "[REDACTED_NAME]" <sip:[REDACTED_CALLER_NUMBER]@[REDACTED_DST_IP];user=phone>;party=calling;privacy=off
[Expert Info (Note/Undecoded): Unrecognised SIP header (remote-party-id)]
[Unrecognised SIP header (remote-party-id)]
[Severity level: Note]
[Group: Undecoded]
Accept: application/sdp
Supported: timer,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 239
Content-Disposition: session; handling=required
Content-Type: application/sdp
Message Body

 

[iduncan]

Both of these are the invite direct from the pcap file while I ran a capture doing my testing.

 

[KyriacosS_3CX]

Could you PM the raw PCAP file to me?

 

[iduncan]

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.

Hi all, My colleague discovered the thread home to this suggestion, and I tried this on our test server and it worked. And, subsequently enough, has MASSIVELY cleaned up other unreported failures by our customers. Our logs as of today are the cleanest they have been in a long time! Just thought I would share an update!