Outbound to Avaya IP Office trunk returning 404 + Q.850 cause 1 — config check?

[amal.progbiz]

Hi all,

Looking for a sanity check on a SIP trunk between 3CX V20 and an Avaya IP Office R10 customer PBX. The trunk is half-working: inbound calls from Avaya land on our IVR fine, but every outbound call to Avaya gets rejected with 404. I've spent a few hours on this and want to confirm I'm not missing something on the 3CX side before pushing back on the Avaya admin.

Setup

• 3CX: version 20.0.8.1121, Standard edition, on Debian (DigitalOcean droplet, dedicated public IP)
• Remote PBX: Avaya IP Office 10.0.0.1.0 build 53, dedicated public IP, SIP 5060 TCP, IP-based authentication
• Trunk: generic SIP Trunk gateway in 3CX, transport TCP, no auth (IP-peer)
• Outbound rule: catch-all (empty mask) routing to this gateway, no digit strip / prepend, originator group __DEFAULT__
• Inbound rule: trunk → IVR → extension. Working in production.

What I see when ext dials anything outbound

3CX sends to Avaya (sample, dialed <digits&gt:

<div data-xf-p="1" data-gutter=""><div data-xf-p="1" data-line-type="context" data-column-number="1" data-line-index="0"></div><div data-xf-p="1" data-line-type="context" data-column-number="2" data-line-index="1"></div><div data-xf-p="1" data-line-type="context" data-column-number="3" data-line-index="2"></div><div data-xf-p="1" data-line-type="context" data-column-number="4" data-line-index="3"></div><div data-xf-p="1" data-line-type="context" data-column-number="5" data-line-index="4"></div><div data-xf-p="1" data-line-type="context" data-column-number="6" data-line-index="5"></div><div data-xf-p="1" data-line-type="context" data-column-number="7" data-line-index="6"></div><div data-xf-p="1" data-line-type="context" data-column-number="8" data-line-index="7"></div><div data-xf-p="1" data-line-type="context" data-column-number="9" data-line-index="8"></div></div><div data-xf-p="1" data-content=""><div data-xf-p="1" data-line="1" data-line-type="context" data-line-index="0"><span>INVITE sip:&lt;digits&gt;@&lt;avaya-ip&gt;:5060;transport=TCP SIP/2.0</span></div><div data-xf-p="1" data-line="2" data-line-type="context" data-line-index="1"><span>Via: SIP/2.0/TCP &lt;3cx-ip&gt;:5060;branch=z9hG4bK-...;rport</span></div><div data-xf-p="1" data-line="3" data-line-type="context" data-line-index="2"><span>Max-Forwards: 70</span></div><div data-xf-p="1" data-line="4" data-line-type="context" data-line-index="3"><span>Contact: &lt;sip:&lt;trunk-did&gt;@&lt;3cx-ip&gt;:5060;transport=TCP&gt;</span></div><div data-xf-p="1" data-line="5" data-line-type="context" data-line-index="4"><span>To: &lt;sip:&lt;digits&gt;@&lt;avaya-ip&gt;:5060;transport=TCP&gt;</span></div><div data-xf-p="1" data-line="6" data-line-type="context" data-line-index="5"><span>From: "&lt;trunk-did&gt;" &lt;sip:&lt;trunk-did&gt;@&lt;avaya-ip&gt;:5060;transport=TCP&gt;;tag=...</span></div><div data-xf-p="1" data-line="7" data-line-type="context" data-line-index="6"><span>CSeq: 1 INVITE</span></div><div data-xf-p="1" data-line="8" data-line-type="context" data-line-index="7"><span>User-Agent: 3CXPhoneSystem 20.0.8.1121 (1121)</span></div><div data-xf-p="1" data-line="9" data-line-type="context" data-line-index="8"><span>Remote-Party-ID: "&lt;trunk-did&gt;"&lt;sip:&lt;trunk-did&gt;@&lt;avaya-ip&gt;:5060&gt;;party=calling</span></div></div>

Avaya replies (always, regardless of &lt;digits&gt:

<div data-xf-p="1" data-gutter=""><div data-xf-p="1" data-line-type="context" data-column-number="1" data-line-index="0"></div><div data-xf-p="1" data-line-type="context" data-column-number="2" data-line-index="1"></div><div data-xf-p="1" data-line-type="context" data-column-number="3" data-line-index="2"></div><div data-xf-p="1" data-line-type="context" data-column-number="4" data-line-index="3"></div><div data-xf-p="1" data-line-type="context" data-column-number="5" data-line-index="4"></div></div><div data-xf-p="1" data-content=""><div data-xf-p="1" data-line="1" data-line-type="context" data-line-index="0"><span>SIP/2.0 100 Trying</span></div><div data-xf-p="1" data-line="2" data-line-type="context" data-line-index="1"><span>...</span></div><div data-xf-p="1" data-line="3" data-line-type="context" data-line-index="2"><span>SIP/2.0 404 Not Found</span></div><div data-xf-p="1" data-line="4" data-line-type="context" data-line-index="3"><span>Server: IP Office 10.0.0.1.0 build 53</span></div><div data-xf-p="1" data-line="5" data-line-type="context" data-line-index="4"><span>Reason: Q.850;cause=1;text="Unallocated (unassigned) number"</span></div></div>

What I've already tested from the 3CX side

1. Dialed-number variations— every format I can think of, all return the same 404:
   • 3-digit, 4-digit, 8-digit, 9-digit, 11-digit, 13-digit
   • With and without +
   • With and without 9 prefix (their PRI shortcode)
   • With and without 00 international prefix
   • Even the trunk's own DID — 404
2. Transport — switched the trunk from TCP to UDP: Avaya goes completely silent (zero responses to 10 INVITEs over 30s of SIP retransmits). Back on TCP → instant 100 Trying + 404. So Avaya's SIP service for this trunk appears TCP-only.
3. Reachability — Avaya sends OPTIONS keepalives to us on TCP/5060 and we 200 OK them. SIP transport is healthy both directions.
4. Firewall — host (nftables) and cloud firewall both open TCP/5060 + UDP/5060 from 0.0.0.0/0. No filtering on our side.
5. 3CX outbound rule — catch-all, no transformation. CDR confirms zero outbound calls connect; eventlog records each as remote 404.

My reading

100 Trying is provisional — Avaya can't generate it without having received and parsed the INVITE. So the INVITE is reaching Avaya, getting parsed, and then their dial-plan layer returns 404 + Q.850 cause 1 ("Unallocated number"). The 404 itself carries Server: IP Office 10.0.0.1.0 build 53 — i.e. the rejection identifies as Avaya's own SIP stack.

My read of the SIP spec and the IPO community threads I've found: the 404 is decided inside Avaya after the INVITE is parsed, the dial-plan/Incoming-Call-Route layer on the SIP Line has nothing matching the User part we send, and there is no header rewriting or transport tweak on the 3CX side that bypasses it. The customer's Avaya admin needs to add a SIP URI entry with Local URI = * plus an Incoming Call Route with Destination = "." on their SIP Line. There's also the known IPO R10 caching bug on ICR Line Group ID changes.

What I'd like to check with the community

1. Is there any 3CX-side configuration I might have missed — different transport, header rewrite, outbound rule transform, separate caller-ID format, etc. — that could make Avaya's existing dial plan accept the call without their admin touching the IPO config?
2. Has anyone else seen an Avaya-IPO trunk where inbound works but outbound 404s, and is there a 3CX-side workaround you've used?
3. Anything in the INVITE above that looks off to a fresh pair of eyes? Specifically, the format of From / Contact / Remote-Party-ID using the trunk DID — Avaya-friendly?

Happy to share sanitized packet captures and config screenshots if helpful.

Thanks in advance.

 

[PhoneMan123]

Does the Avaya admin have anything in the ICR section to route with? They need to either have a wildcard match or an entry for whatever you are sending in the invite. That's pretty basic stuff on the Avaya side if it's setup as a SIP trunk. I'd try to get him to add a test ICR like 1234 and have them route it to an AA or extension and see if it goes through when you call 1234 and send it across the trunk.

 

[leejor]

On a "normal" SIP trunk,and I may be wrong, but I would think you'd have to be sending the digits in a DID format/message, for the Avaya to recognize and route an incoming number. 3CX won't be doing that.

If you were trying the same thing in the 3CX direction, it would require the use of a Bridge trunk. Is there the equivalent in the Avaya?