[SR-Users] Kamailio routing BYE back to originator

[Alex Balashov]

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/