FOOD FOR THOUGHT "Incredible" issue with INVITE originating from Twilio

[mr401b]

Need your help, spent 2 days debugging this and have no clue what happens. Was working fine before wit Asterisk 16.
The issue: INVITES from Twilio SIP trunks completely invisible to pjsip. But they come and are visible in tcpdump (and no firewall set).
All trunks (DIDWW, Voip.ms and Twilio) configured similarly with "inbound match" on IP (and based on tcpdump trace the match should happen)
Inbound calls from Voip.ms and DIDWW work fine and they are visible to pjsip debug trage (pjsip set logger on / set logger verbose on)
For twilio only the outbound calls work and sip options originated from Incredible PBX

On the tcpdump trace clearly there is no SIP answer to the INVITEs UDP packets - INVITEs come in every few seconds and nothing happens
My Incredible PBX 2025 works fine outbound /inbound with DIDWW and Voip.ms. Twilio inbound calls work as well fine if initiated from the trunk "Originate test call".
Only inbound calls routed through the twilio trunk (to same DIDs on my Incredible PBX) are "invisible" to pjsip

In the pjsip "advanced" for the trunk I am matching on either IP or username (which is defined in the trunk pjsip settings / general as the +1438vvvzzzz visible in the attached traces)

The only 2 INVITE differences I see are the "From:" header and the P-Asserted-Identity header (missing in the working test call)

In the working test call
From: <sip:[email protected]>;tag=48407581 ... etc

In the ignored INVITE
From: <sip:[email protected]:5060;isup-oli=00;pstn-params=9084818088>;tag=76030578_c3356d0b ... etc

Thank you in advance for any idea on how to debug and fix this odd behavior

P.S.
- the FQDNs, IPs, DIDs are anonymized for security
- the IP filters in trunk / pjsip / advanced were double checked against the source IPs
(true the test call is coming from a different range but both ranges are covered by the "match IP")
- INVITE "invisible" to PJSIP means that with full debug logging (pjsip set logger on / logger verbose on / logger method on) can see e.g. the SIP OPTIONS being exchanged (always initiated locally) but not the invite.
- with same logging options the test call INVITE appears just fine in the log

 

[mr401b]

Hi, just had a very interesting conversation with the Twilio AI support agent. Honestly I am impressed. I have provided the SIP traces and the agent immediately suggested that the issue most likely is with the INVITE parsing deep down in the PJSIP stack where apparently no parsing error is being logged. And the parsingt error, according to the Twilio agent is triggered by the extra attributes in the From header.

From: <sip:[email protected]:5060;isup-oli=00;pstn-params=9084818088>;tag=76030578_c3356d0b_c0d924a7-b138-4b0f-a18e-2df0133c7434
SIP from address: sip:[email protected]:5060;isup-oli=00;pstn-params=9084818088
SIP from address User Part: +1514xxxyyyy
This is what the AI agent says
Copy code block
INVITE sip:[email protected] SIP/2.0
This is standard.
Most Likely Causes for Silent Drop
Malformed or Unexpected URI Parameters: The From header’s use of semicolon-separated parameters inside the URI is a common culprit. Some Asterisk versions expect only hostort, not extra parameters, in the From URI.
Contact Header Format: The plus sign before the IP address in the Contact header is non-standard and could confuse the parser.
Header Length or Order: Some SIP stacks are sensitive to header order or line length, but your example does not appear excessively long.
Next Steps & Suggestions
Test with a Simplified INVITE:

Try removing the isup-oli and pstn-params from the From URI, or move them to header parameters if possible.
Change the Contact header to use a standard user part (e.g., a number or “user”).
Compare with a Working INVITE:

Therefore is there a solution to this issue of "malformed INVITE" (from PJSIP standpoint)?

 

[Samot]

Hi, just had a very interesting conversation with the Twilio AI support agent. Honestly I am impressed. I have provided the SIP traces and the agent immediately suggested that the issue most likely is with the INVITE parsing deep down in the PJSIP stack where apparently no parsing error is being logged. And the parsingt error, according to the Twilio agent is triggered by the extra attributes in the From header.

From: <sip:[email protected]:5060;isup-oli=00;pstn-params=9084818088>;tag=76030578_c3356d0b_c0d924a7-b138-4b0f-a18e-2df0133c7434
SIP from address: sip:[email protected]:5060;isup-oli=00;pstn-params=9084818088
SIP from address User Part: +1514xxxyyyy
This is what the AI agent says
Copy code block
INVITE sip:[email protected] SIP/2.0
This is standard.
Most Likely Causes for Silent Drop
Malformed or Unexpected URI Parameters: The From header’s use of semicolon-separated parameters inside the URI is a common culprit. Some Asterisk versions expect only hostort, not extra parameters, in the From URI.
Contact Header Format: The plus sign before the IP address in the Contact header is non-standard and could confuse the parser.
Header Length or Order: Some SIP stacks are sensitive to header order or line length, but your example does not appear excessively long.
Next Steps & Suggestions
Test with a Simplified INVITE:

Try removing the isup-oli and pstn-params from the From URI, or move them to header parameters if possible.
Change the Contact header to use a standard user part (e.g., a number or “user”).
Compare with a Working INVITE:

Therefore is there a solution to this issue of "malformed INVITE" (from PJSIP standpoint)?

That was completely wrong about the front header. Having the wrong contact user was probably the culprit.