Not at all! Forcing subsequent in-dialog messages to go to the same destination is inherent to correct proxy behaviour; it just requires some additional logic that is part of typical Kamailio boilerplate. (You can only get away with having a 'minimalistic' config for so long. :) Check this out: https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L658-L698 You'll want to put that near the top of your config, well before you handle any initial INVITEs. A simplified version that will work for your purposes: if(has_totag()) { if(loose_route()) { if(!t_relay()) sl_reply_error(); exit; } else if(is_method("ACK")) { if(t_check_trans()) { if(!t_relay()) sl_reply_error(); exit; } exit; } sl_send_reply("404", "Not here"); } -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

"Loose routing" of in-dialog requests is a complex, byzantine topic in SIP proxy science. :-) The highlights: 1. Requests which are scoped inside a "call" occur within a dialog -- e.g. end-to-end ACK, INFO, BYE, etc. This is to distinguish them from "initial" requests, which are subject to an original routing decision. In contrast, in-dialog requests follow an essentially predetermined (see #6) "route set". The most salient characteristic of an in-dialog request is a ';tag=xxxxx' parameter in the 'To' header. A tag will always be present in the 'From' header, but is only present in the 'To' header on in-dialog requests; 2. In-dialog requests are, by default, directed to a Request URI that is equal to the Contact URI of the other party. This implies that they would normally flow around the proxy; 3. The Record-Route header added by the proxy to the initial INVITE changes that. It says, "No, you need to shunt your in-dialog requests through me." The Record-Route header is copied into the 200 OK that is sent back to the calling party, so that it knows about the shunt, too. 4. There can be multiple Record-Route headers if multiple proxies are in the path; 5. In the construction of an in-dialog request, the Record-Route headers are turned into a stack of Route headers; these then traverse intermediate proxies, with each proxy stripping off Route headers that refer to itself ("hey, that's me!"), and forwarding the request to the next hop based on the next available Route header. Vitally, the Request URI is kept the same, and continues to match the remote Contact URI; the Route hops only have the effect of changing the destination on a practical (that is, network and transport) level; 6. The Contact URI at which a dialog party is targeted, known as the "remote target", can be changed in a re-INVITE or UPDATE, which are known as "target refresh" requests. These requests are better known for changing media parameters, but this is another thing they can do, though it is seldom done; In essence, loose_route() implements the logic behind #5. The other parts of this whole stanza concern the relationship between ACKs and transactions. The function t_check_trans() has very different behaviour that is highly contextually sensitive, depending on what is being checked, and does more than its name might imply: https://kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.f.t_check_trans -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/