Re: [SR-Users] Kamailio routing BYE back to originator

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@domain.xyz, then any end-to-end ACK, reinvite, BYE, etc. must have a request URI of sip:123@domain.xyz. If the caller sent an INVITE with a contact of sip:345@domain.xyz and the callee wishes to send a BYE to it, the request line must be:

BYE sip:345@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@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