Hello Andrew, Kamailio's routing of in-dialog requests is per standard RFC 3261 prescriptions and isn't terribly complicated.
General principles of in-dialog requests (which includes a BYE): 1. The request URI of an in-dialog request must be set to the Contact URI of the remote party. For example, if the callee answered with a 200 OK and a Contact of <sip:1...@domain.xyz>, then any end-to-end ACK, reinvite, BYE, etc. must have a request URI of sip:1...@domain.xyz. If the caller sent an INVITE with a contact of <sip:3...@domain.xyz> and the callee wishes to send a BYE to it, the request line must be: BYE sip:3...@domain.xyz SIP/2.0 No exceptions. 2. The actual network and transport-layer destination of an in-dialog request can be altered by Record-Route headers inserted into the initial INVITE by Kamailio. The purpose of Record-Route headers is to tell both sides that subsequent in-dialog requests should be shunted through the intermediate proxy; the default behaviour would be to send them directly to each other in a manner that bypasses the proxy. 3. Kamailio's stock NAT traversal handling makes use of an ;alias parameter which can be appended to the Contact / Request URI of the dialog parties, but it should be stripped off by handle_ruri_alias() and so should not hamper this exchange. In my experience, the #1 problem with handling of in-dialog requests on the part of endpoints/user agents (UAs) is that they sometimes do not honour requirement #1, and will tend to target requests to @proxy rather than @remote_UA as per above. A SIP packet capture of the entire call leg should reveal what's going on fairly straightforwardly. -- Alex On Mon, Jun 24, 2019 at 01:20:13PM +1000, Andrew White wrote: > Hi all, > > I’ve done some digging and realised that outbound calls I initiate Asterisk > -> Kamailio -> Trunk are receiving the BYE correctly. However the previously > provided flow was Drachtio -> Kamailio -> Trunk. > > I suspect the dialog is not being initialised correctly in some way from > Drachtio. I can make changes as required here, but I need help spotting the > difference between the two. > > I ran a kamcmd dlg.list on a test call Asterisk -> Kamailio -> Trunk, and > another one on Drachtio -> Kamailio -> Trunk, here are the results (with IPs > anonymised and replaced with pseudo hostnames): > > Asterisk -> Kamailio -> Trunk: > https://pastebin.com/WkFefUGB <https://pastebin.com/WkFefUGB> > > Drachtio -> Kamailio -> Trunk: > https://pastebin.com/G3bzNYY0 <https://pastebin.com/aX5hdqUE> > > I don’t know the inner workings of Kamailio dialogs well, but these look very > similar to me. Am I on the right track here, is there other debug information > I can dump to compare what’s happening and why this BYE its going to the > wrong end? > > Thanks, > > Andrew > > > On 23 Jun 2019, at 5:39 pm, Andrew White <and...@uconnected.com.au> wrote: > > > > Hi team! > > > > I’ve recently found an issue in my Kamailio setup. It appears when the > > trunk replies to call in progress with a BYE, we relay it immediately back > > to them: > > > > https://i.imgur.com/h5fusau.png <https://i.imgur.com/h5fusau.png> > > > > The only differences in the second BYE is the Route header is removed and > > replaced with a Via header referencing the Kamailio machine, and the From > > URI is rewritten to show the Kamailio hostname. > > > > > > I’m unsure what steps I can take here, as all of my out of dialog messages > > (180, 200, ACK) are forwarded along with no issue. It seems only the in > > dialog are having this issue. > > > > Here’s my WITHINDLG and RELAY: > > > > def ksr_route_relay() > > if KSR.is_method_in("IBSU") then > > if KSR::TM.t_is_set("branch_route") < 0 then > > KSR::TM.t_on_branch("ksr_branch_manage") > > end > > end > > if KSR.is_method_in("ISU") then > > if KSR::TM.t_is_set("onreply_route") < 0 then > > KSR::TM.t_on_reply("ksr_onreply_manage") > > end > > #KSR.info <http://ksr.info/>("Onreply route: > > #{KSR::TM.t_is_set("onreply_route")}") > > end > > > > if KSR.is_INVITE() then > > if KSR::TM.t_is_set("failure_route") < 0 then > > KSR::TM.t_on_failure("ksr_failure_manage") > > end > > end > > > > if KSR::TM.t_relay() < 0 then > > KSR::SL.sl_reply_error() > > end > > exit > > end > > > > def ksr_route_withindlg() > > return if KSR::SIPUTILS.has_totag() < 0 > > > > if KSR::RR.loose_route() > 0 then > > ksr_route_dlguri() > > if KSR.is_BYE() then > > #KSR.setflag($myenv['FLT_ACC'].to_i) > > #KSR.setflag($myenv['FLT_ACCFAILED'].to_i) > > elsif KSR.is_ACK() then > > ksr_route_natmanage() > > elsif KSR.is_NOTIFY() then > > KSR::RR.record_route() > > end > > ksr_route_relay() > > exit > > end > > > > if KSR.is_ACK() then > > #KSR.info <http://ksr.info/>("Handling an ACK within dialog") > > if KSR::TM.t_check_trans() > 0 then > > ksr_route_relay() > > exit > > else > > exit > > end > > end > > #KSR.info <http://ksr.info/>("404ing within dialog") > > KSR::SL.sl_send_reply(404, "Not here"); > > exit > > end > > > > I suspect I must be sending this to the wrong branch somehow, but I’m > > unsure how to correct this. The call gets originally initiated from > > Kamailio writing a custom RURI and To header before calling t_relay(). I’m > > wondering if I’m somehow initiating the dialog incorrectly and as such the > > BYE doesn’t know where to go. > > > > Thanks! > > > > Andrew > > > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- 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/ _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users