Client INVITE 2xx auto-ACK opens a new connection to the Record-Route/Contact target instead of reusing the existing flow (connection-oriented transports / RFC 7118) → multi-second stall

[yashsntl]

Summary

With a UAC running over a single outbound connection-oriented transport (WS/WSS/TCP/TLS), receiving a 200 OK to an INVITE blocks Transaction::receive() for the full TCP connect timeout (~21s on Windows) when the dialog's Record-Route/Contact target is not directly reachable from the client.

The root cause: on a 2xx the client INVITE transaction auto-sends ACK, and that ACK resolves its target via TransportLayer::lookup(), which opens a brand-new connection to the ACK target instead of reusing the connection the 2xx arrived on. When that target is an address the client cannot reach (very common behind any record-routing proxy/B2BUA that advertises an internal address), the connect blocks for the OS connect timeout, and the 200 OK is only surfaced to the TU after send_ack returns.

Environment

• rsipstack 0.5.15
• Transport::Wss, a single outbound WebSocket connection to a record-routing proxy
• Client consumes responses via a while let Some(msg) = transaction.receive().await loop

Steps to reproduce

1. UAC establishes one outbound WS/WSS connection to a proxy and REGISTERs.
2. UAC sends an INVITE and receives 100/183 promptly over that same connection.
3. The 200 OK carries Record-Route/Contact pointing at an address the client cannot reach directly (e.g. the server's internal address — 192.0.2.10:5060;transport=ws as a placeholder).
4. transaction.receive() does not return the 200 OK for ~21 seconds.

Observed diagnostic log:

rsipstack::transport::transaction: transition key=c.INVITE_... from=Proceeding to=Completed
rsipstack::transport::transport_layer: lookup target key=Some(...) src=WS 192.0.2.10:5060 target=WS 192.0.2.10:5060
   <~21s gap, no frames received>
   (200 OK finally delivered to the application)

The 200 OK frame itself arrives on the existing connection essentially immediately; the delay is entirely the new-connection attempt to the unreachable target. (Verified independently: a raw TCP connect to that target address fails after ~21.0s — the Windows SYN-retransmit connect timeout — matching the stall duration exactly.)

Root cause (code references, v0.5.15)

• src/transaction/transaction.rs — on_received_response: on a 2xx, the ClientInvite transaction transitions to Completed and calls send_ack(connection).
• src/transaction/transaction.rs — send_ack (~448–520): for a 2xx it derives the ACK target from the response/Request-URI and calls transport_layer.lookup(target, ...) rather than reusing the connection the 2xx arrived on (which is passed in).
• src/transport/transport_layer.rs — lookup (~266–332): if no entry in connections: HashMap<SipAddr, SipConnection> matches target, it opens a NEW connection via WebSocketConnection::connect / TcpConnection::connect / TlsConnection::connect. For an unreachable target this blocks for the OS connect timeout.

Provisional responses (183) and non-INVITE transactions (e.g. the BYE 200 OK) are delivered in well under a millisecond, because they do not trigger this target lookup/connect — only the 2xx INVITE auto-ACK does.

Expected behavior

Per RFC 7118 §5 (SIP over WebSocket) and general connection-oriented transport handling, in-dialog requests and the 2xx ACK must reuse the existing flow the dialog was established on. The client should never dial the Record-Route/Contact address on a connection-oriented transport.

Suggested fix

In send_ack, for a 2xx ACK prefer the connection the response arrived on (already passed in as connection) before falling back to lookup; and/or have lookup reuse the established connection for connection-oriented transports when one exists for the flow.

Workaround

Build the TransportLayer manually, set TransportLayer.outbound to the proxy/flow address, and pre-register the connection with add_connection so lookup resolves to the existing connection (since lookup uses outbound.unwrap_or(destination)). This avoids the new-connection attempt, but the underlying send_ack/lookup behavior still seems worth fixing for connection-oriented transports.

[yeoleobun]

The 200 OK carries Record-Route/Contact pointing at an address the client cannot reach directly (e.g. the server's internal address — 192.0.2.10:5060;transport=ws as a placeholder).

Could you tell which proxy will have this behaviour, and it would be better provide the 200 OK sip message.

[kneliba]

I hit the same send_ack issue, but in a slightly different setup where rsipstack is used to build a record-routing proxy.

It inserts its own address into the Record-Route and on a 2xx the client transaction's auto-ACK resolves the target from the response's Record-Route via transport_layer::lookup() and sends the ACK to rsipstack's own address. Then it loops instead of going upstream, and the 200 OK retransmits until the call drops.

Provisionals, PRACK, and BYE are fine and only the 2xx auto-ACK re-resolves a target and misroutes.

For the 2xx ACK, if it prefers the connection the response arrived on rather than lookup(ack.destination()) then the issue goes away. For UDP that means sending to the address the 200 came from. Gating the target resolution on "no arrival connection" fixed it in local testing.

Adding as a second independent repro.

[yashsntl]

@yeoleobun Thanks for looking at this — answers to both questions:

1. Which proxy: an OpenSIPS-based record-routing edge proxy with a B2BUA behind it (a hosted-telephony WebSocket edge that normally serves SIP.js browser clients). The key detail: the proxy record-routes and sets the B2BUA Contact to a real public address on port :5060, but the client's actual WSS flow terminates on :443 — so the advertised Record-Route/Contact target is not the connection the dialog was established on. This is normal and compliant for a WSS edge: RFC 7118 expects the client to send everything (including the 2xx ACK) back over the flow it established, so the :5060 RR/Contact address is only meaningful server-side and isn't something the client should dial. Any record-routing proxy/B2BUA fronting WebSocket clients (typical OpenSIPS/Kamailio WS deployments) presents this shape.

2. The 200 OK (real captured message; our public IPs masked as **, tags/Call-ID/number shortened — header structure, params, ports and transports are verbatim). The RR/Contact host (**:5060) is the same proxy address that later appears in the BYE's top Via — but that Via shows the flow is actually transport=WSS … rport=443:

SIP/2.0 200 OK
Via: SIP/2.0/TCP 0.0.0.0;branch=z9hG4bK6286522e1cb64cb9;rport=50223;received=**.**.**.**
Record-Route: <sip:**.**.**.**:5060;transport=ws;lr;ftag=8a87abd2;did=707.c5d0efb6>
Contact: <sip:b2bua@**.**.**.**:5060>
To: <sip:+XXXXXXXXXXX@number.example.com>;tag=ece1c309
From: <sip:user@example.com>;tag=8a87abd2
Call-ID: <redacted>
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 563

(answer SDP omitted — WebRTC audio, not load-bearing for the routing bug)

The dialog's real flow is on :443, which the far-end BYE makes explicit — same :5060 host in the top Via, but transport=WSS;received=**.**.**.**;rport=443:

BYE sip:+XXXXXXXXXXX@**.**.**.**:50223;transport=WS SIP/2.0
Via: SIP/2.0/WS **.**.**.**:5060;branch=z9hG4bKb373.81c0e816.0;transport=WSS;received=**.**.**.**;rport=443
Via: SIP/2.0/UDP <carrier-internal>;branch=...;rport=5064
Contact: <sip:b2bua@**.**.**.**:5060>
CSeq: 2 BYE

With that 200 OK, make_ack builds the 2xx ACK's route set from the Record-Route and the remote target from Contact, so ack.destination() resolves to the :5060 address — and in send_ack the arrival connection parameter is replaced by transport_layer.lookup(ack.destination()). Our connection map is keyed on the :443 edge, so the :5060 target misses and lookup() calls WebSocketConnection::connect() to :5060, which the client can't establish. That dial blocks for the OS connect timeout (~21 s on Windows), and since on_received_response awaits send_ack before returning the response, Transaction::receive() only surfaces the 200 OK after the timeout.

3. On @kneliba's repro and fix — we confirm the same mechanism from the UAC side, and the suggested direction matches what we validated in production: our workaround forces lookup to resolve to the arrival flow (TransportLayer.outbound = <flow addr> + add_connection before building the endpoint). With it active, our latest capture shows the 2xx ACK going out on the existing flow 1 ms after the 200 OK (ACK sip:b2bua@**.**.**.**:5060, Route: <sip:**.**.**.**:5060;transport=ws;lr;…>), media connects immediately, no ~21 s stall — running live for several weeks now with no regressions on REGISTER / provisionals / BYE.

So: in send_ack, preferring the connection the 2xx arrived on (it's already passed in as the connection parameter) and only falling back to lookup() when there's no arrival connection would fix both failure modes — the UAC stall here and @kneliba's proxy ACK self-loop — and is what RFC 7118 requires for WebSocket flows. For UDP the route-set target stays the correct default per RFC 3261, with @kneliba's "send to the 200's source address" a sensible symmetric-NAT fallback. Happy to test a patch against our live setup.