[SR-Users] Kamailio routing BYE back to originator

Mon Jun 24 13:18:24 CEST 2019

Hi Alex,

Thanks so much, I owe you a beer at the next conference we’re both at!

You were completely correct, I was adjusting the contact header to reflect the trunks host unintentionally when passing through Kamailio, This was working fine on another trunk (that Asterisk was using) because Asterisk was sending the RPID, which (for some reason) that trunk accepts as superseding the Request URI over the contact header.

Thanks again!

Andrew

> On 24 Jun 2019, at 1:27 pm, Alex Balashov <abalashov at evaristesys.com> wrote:
> 
> 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:123 at domain.xyz>, then any end-to-end ACK, reinvite, BYE, etc. must
> have a request URI of sip:123 at domain.xyz. If the caller sent an INVITE
> with a contact of <sip:345 at domain.xyz> and the callee wishes to send a
> BYE to it, the request line must be:
> 
>   BYE sip:345 at 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 <andrew at 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 at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users