In-dialog requests carry a UDP Via when sent over TCP (RFC 3261 §18.1.1) #151

Summary

In-dialog requests (BYE, re-INVITE, UPDATE, INFO, PRACK, …) always get a Via built from the endpoint's first listener. On an endpoint that listens on UDP first and TCP as well, a dialog established over TCP sends its re-INVITE and BYE over the TCP flow (or towards a ;transport=tcp route / remote target) but with Via: SIP/2.0/UDP …. Peers may drop the mismatched request or send the response over UDP.

Reproduced on current main (3ea35cd, 0.6.12).

Expected

RFC 3261 §18.1.1 / §8.1.1.7: the Via header field value names the transport the request is actually sent over. The initial INVITE already picks the listener matching the target transport (make_invite_request), and REGISTER does the same since 0c2dcc1 (#141); in-dialog requests do not.

What happens

DialogInner::make_request (src/dialog/dialog.rs) builds the Via with get_via(None), i.e. from the first listener, regardless of the transport the request will use.

Example (UAC with UDP bound first, TCP second, call established over TCP, then a re-INVITE):

a re-INVITE sent over TCP must carry a TCP Via, got: SIP/2.0/UDP 127.0.0.1:54356;branch=z9hG4bK…;rport

Same result when the route set is a ;transport=tcp;lr Record-Route instead of the reused flow.

A fix with tests is in the linked PR.