24 Jun
2019
24 Jun
'19
1:18 p.m.
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(a)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@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(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users