date:20211111

Re: [SR-Users] Kamailio dropping ACKs

2021-11-11 Thread Sergey Safarov

In my opinion, the carrier that you send a call, send ACK to RURI different
than Contact header value in your "200 OK".

On Fri, Nov 12, 2021 at 8:17 AM ‪M S‬  wrote:

> No, i didn't mean to add RR to SIPp, which is an endpoint. The problem is
> with your kamailio, which is a sip proxy here. Just look at default
> kamailio.cfg file that is shipped with RPM package. You will get the idea.
> It has lots of comments which explains most of the stuff in there.
>
> As for SIPp, the default call scenario is fine. However, you may want to
> add RTP stuff there for proper call setup (i.e. with audio).
>
> --
> Muhammad Shahzad Shafi
> Tel: +49 176 99 83 10 85
>
>
> Sent from my Huawei P40 5G phone
>
>
>  Original message 
> From: Emilio Panighetti 
> Date: Fri, 12 Nov 2021, 05:49
> To: ‪M S‬ 
> Cc: "Kamailio (SER) - Users Mailing List" 
> Subject: Re: [SR-Users] Kamailio dropping ACKs
>
> You’re right that SIPp is not adding record route.
> I tried adding the ‘rrs’ flag as shown on the default scenarios but did
> not work.
> Working SIPp scenarios would be appreciated.
>
> Thanks
>
> On Nov 11, 2021, at 2:42 PM, ‪M S‬  wrote:
>
> Seems you forgot to add record route to invite, as a result there is no
> Route header in ACK, so loose route fails.
>
> Additionally there is no contact alias, so routing via alias also fails.
>
> Also it seems you are not creating SIP transactions and dialogs in script,
> you just blindly receiving sip request from one end and throwing it out to
> the other end!
>
> So only possible way to route ACK is to set destination URI, same way you
> do for INVITE. You will have to do that for EVERY sip request, unless you
> make your script intelligent enough to create and recognize sip
> transactions & dialogs properly.
>
> Hope this helps.
>
> --
> Muhammad Shahzad Shafi
> Tel: +49 176 99 83 10 85
>
> Sent from my Huawei P40 5G phone
>
>
>  Original message 
> From: Emilio Panighetti 
> Date: Thu, 11 Nov 2021, 18:44
> To: "Kamailio (SER) - Users Mailing List" 
> Subject: [SR-Users] Kamailio dropping ACKs
>
> Working on a proof of concept with Kamailio 5.5.2 (Installed
> via kamailio-5.5.2-0.el8.centos.x86_64 RPM from rpm.kamailio.org).
> Also note that this is using the LUA interface
>
> Running a simple SIPp scenario without registration. Routing is set with
> in Lua:
> KSR.dbg("EP: ksr_route_relay Check for Base Route\n");
> if KSR.is_INVITE() and KSR.siputils.has_totag() < 0 then
> KSR.dbg("EP: ksr_route_relay Base Route\n");
> --KSR.sl.send_reply("503", "OLGX Debug");
> KSR.setdsturi("sip:192.168.1.14:5060");
> --KSR.pv.sets("$du", "sip:192.168.1.12:5062");
> end
>
> The problem is that Kamailio is dropping the ACK to the 200 OK from the
> UAS. Wireshark shows that the UAS is retransmitting the 200 OK and the ACK
> is not being forwarded from the UAC to the UAS.
>
> 
> Within the Lua config script:
>
> -- Handle requests within SIP dialogs
> function ksr_route_withindlg()
> if KSR.siputils.has_totag() < 0 then return 1; end
> KSR.dbg("EP: ksr_route_withindlg has to-tag, it is within a dialog\n");
>
> -- sequential request within a dialog should
> -- take the path determined by record-routing
> if KSR.rr.loose_route() > 0 then
> ksr_route_dlguri();
> if KSR.is_BYE() then
> KSR.setflag(FLT_ACC); -- do accounting ...
> KSR.setflag(FLT_ACCFAILED); -- ... even if the transaction
> fails
> elseif KSR.is_ACK() then
> -- ACK is forwarded statelessly
> KSR.dbg("EP: ksr_route_withindlg Forwarding ACK\n");
> ksr_route_natmanage();
> elseif KSR.is_NOTIFY() then
> -- Add Record-Route for in-dialog NOTIFY as per RFC 6665.
> KSR.rr.record_route();
> end
> KSR.dbg("EP: ksr_route_withindlg loose route calling
> ksr_route_relay\n");
> ksr_route_relay();
> KSR.dbg("EP: ksr_route_withindlg exit\n");
> KSR.x.exit();
> end
> if KSR.is_ACK() then
> if KSR.tm.t_check_trans() > 0 then
> -- no loose-route, but stateful ACK;
> -- must be an ACK after a 487
> -- or e.g. 404 from upstream server
> KSR.dbg("EP: ksr_route_withindlg is ACK calling
> ksr_route_relay\n");
> ksr_route_relay();
> KSR.dbg("EP: ksr_route_withindlg exit\n");
> KSR.x.exit();
> else
> -- ACK without matching transaction ... ignore and discard
> KSR.dbg("EP: ksr_route_withindlg Unknown ACK exit\n");
> KSR.x.exit();
> end
> end
> KSR.sl.sl_send_reply(404, "Not here");
> KSR.dbg("EP: ksr_route_withindlg exit after 404\n");
> KSR.x.exit();
> end
>
> And logs for the ACK:
>
> Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: 
> [core/udp_server.c:493]: udp_rcv_loop(): received on udp socket:
> (106/100/385) [[ACK

Re: [SR-Users] Kamailio dropping ACKs

2021-11-11 Thread ‪M S‬

No, i didn't mean to add RR to SIPp, which is an endpoint. The problem is with your kamailio, which is a sip proxy here. Just look at default kamailio.cfg file that is shipped with RPM package. You will get the idea. It has lots of comments which explains most of the stuff in there.As for SIPp, the default call scenario is fine. However, you may want to add RTP stuff there for proper call setup (i.e. with audio).--Muhammad Shahzad ShafiTel: +49 176 99 83 10 85Sent from my Huawei P40 5G phone Original message From: Emilio Panighetti Date: Fri, 12 Nov 2021, 05:49To: ‪M S‬ Cc: "Kamailio (SER) - Users Mailing List" Subject: Re: [SR-Users] Kamailio dropping ACKsYou’re right that SIPp is not adding record route.I tried adding the ‘rrs’ flag as shown on the default scenarios but did not work.Working SIPp scenarios would be appreciated.ThanksOn Nov 11, 2021, at 2:42 PM, ‪M S‬  wrote:Seems you forgot to add record route to invite, as a result there is no Route header in ACK, so loose route fails. Additionally there is no contact alias, so routing via alias also fails. Also it seems you are not creating SIP transactions and dialogs in script, you just blindly receiving sip request from one end and throwing it out to the other end!So only possible way to route ACK is to set destination URI, same way you do for INVITE. You will have to do that for EVERY sip request, unless you make your script intelligent enough to create and recognize sip transactions & dialogs properly.Hope this helps.--Muhammad Shahzad ShafiTel: +49 176 99 83 10 85Sent from my Huawei P40 5G phone Original message From: Emilio Panighetti Date: Thu, 11 Nov 2021, 18:44To: "Kamailio (SER) - Users Mailing List" Subject: [SR-Users] Kamailio dropping ACKsWorking on a proof of concept with Kamailio 5.5.2 (Installed via kamailio-5.5.2-0.el8.centos.x86_64 RPM from rpm.kamailio.org).Also note that this is using the LUA interfaceRunning a simple SIPp scenario without registration. Routing is set with in Lua:    KSR.dbg("EP: ksr_route_relay Check for Base Route\n");    if KSR.is_INVITE() and KSR.siputils.has_totag() < 0 then        KSR.dbg("EP: ksr_route_relay Base Route\n");        --KSR.sl.send_reply("503", "OLGX Debug");        KSR.setdsturi("sip:192.168.1.14:5060");        --KSR.pv.sets("$du", "sip:192.168.1.12:5062");    endThe problem is that Kamailio is dropping the ACK to the 200 OK from the UAS. Wireshark shows that the UAS is retransmitting the 200 OK and the ACK is not being forwarded from the UAC to the UAS.Within the Lua config script:-- Handle requests within SIP dialogsfunction ksr_route_withindlg()    if KSR.siputils.has_totag() < 0 then return 1; end    KSR.dbg("EP: ksr_route_withindlg has to-tag, it is within a dialog\n");    -- sequential request within a dialog should    -- take the path determined by record-routing    if KSR.rr.loose_route() > 0 then        ksr_route_dlguri();        if KSR.is_BYE() then            KSR.setflag(FLT_ACC); -- do accounting ...            KSR.setflag(FLT_ACCFAILED); -- ... even if the transaction fails        elseif KSR.is_ACK() then            -- ACK is forwarded statelessly            KSR.dbg("EP: ksr_route_withindlg Forwarding ACK\n");            ksr_route_natmanage();        elseif KSR.is_NOTIFY() then            -- Add Record-Route for in-dialog NOTIFY as per RFC 6665.            KSR.rr.record_route();        end        KSR.dbg("EP: ksr_route_withindlg loose route calling ksr_route_relay\n");        ksr_route_relay();        KSR.dbg("EP: ksr_route_withindlg exit\n");        KSR.x.exit();    end    if KSR.is_ACK() then        if KSR.tm.t_check_trans() > 0 then            -- no loose-route, but stateful ACK;            -- must be an ACK after a 487            -- or e.g. 404 from upstream server            KSR.dbg("EP: ksr_route_withindlg is ACK calling ksr_route_relay\n");            ksr_route_relay();            KSR.dbg("EP: ksr_route_withindlg exit\n");            KSR.x.exit();        else            -- ACK without matching transaction ... ignore and discard            KSR.dbg("EP: ksr_route_withindlg Unknown ACK exit\n");            KSR.x.exit();        end    end    KSR.sl.sl_send_reply(404, "Not here");    KSR.dbg("EP: ksr_route_withindlg exit after 404\n");    KSR.x.exit();endAnd logs for the ACK:Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (106/100/385) [[ACK sip:service@192.168.1.15:5060 SIP/2.0 0D  0A Via: SIP/2.0/UDP 192.168.1.12:5060;branch=z9hG4bK-1091869]]Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:677]: parse_msg(): SIP Request:Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:679]: parse_msg():

Re: [SR-Users] Kamailio dropping ACKs

2021-11-11 Thread Emilio Panighetti

You’re right that SIPp is not adding record route.
I tried adding the ‘rrs’ flag as shown on the default scenarios but did not 
work.
Working SIPp scenarios would be appreciated.

Thanks

On Nov 11, 2021, at 2:42 PM, ‪M S‬  wrote:

Seems you forgot to add record route to invite, as a result there is no Route 
header in ACK, so loose route fails. 

Additionally there is no contact alias, so routing via alias also fails. 

Also it seems you are not creating SIP transactions and dialogs in script, you 
just blindly receiving sip request from one end and throwing it out to the 
other end!

So only possible way to route ACK is to set destination URI, same way you do 
for INVITE. You will have to do that for EVERY sip request, unless you make 
your script intelligent enough to create and recognize sip transactions & 
dialogs properly.

Hope this helps.

--
Muhammad Shahzad Shafi
Tel: +49 176 99 83 10 85

Sent from my Huawei P40 5G phone


 Original message 
From: Emilio Panighetti mailto:emil...@operalogic.com>>
Date: Thu, 11 Nov 2021, 18:44
To: "Kamailio (SER) - Users Mailing List" mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Kamailio dropping ACKs
Working on a proof of concept with Kamailio 5.5.2 (Installed via 
kamailio-5.5.2-0.el8.centos.x86_64 RPM from rpm.kamailio.org 
).
Also note that this is using the LUA interface

Running a simple SIPp scenario without registration. Routing is set with in Lua:
KSR.dbg("EP: ksr_route_relay Check for Base Route\n");
if KSR.is_INVITE() and KSR.siputils.has_totag() < 0 then
KSR.dbg("EP: ksr_route_relay Base Route\n");
--KSR.sl.send_reply("503", "OLGX Debug");
KSR.setdsturi("sip:192.168.1.14:5060");
--KSR.pv.sets("$du", "sip:192.168.1.12:5062");
end

The problem is that Kamailio is dropping the ACK to the 200 OK from the UAS. 
Wireshark shows that the UAS is retransmitting the 200 OK and the ACK is not 
being forwarded from the UAC to the UAS.


Within the Lua config script:

-- Handle requests within SIP dialogs
function ksr_route_withindlg()
if KSR.siputils.has_totag() < 0 then return 1; end
KSR.dbg("EP: ksr_route_withindlg has to-tag, it is within a dialog\n");

-- sequential request within a dialog should
-- take the path determined by record-routing
if KSR.rr.loose_route() > 0 then
ksr_route_dlguri();
if KSR.is_BYE() then
KSR.setflag(FLT_ACC); -- do accounting ...
KSR.setflag(FLT_ACCFAILED); -- ... even if the transaction fails
elseif KSR.is_ACK() then
-- ACK is forwarded statelessly
KSR.dbg("EP: ksr_route_withindlg Forwarding ACK\n");
ksr_route_natmanage();
elseif KSR.is_NOTIFY() then
-- Add Record-Route for in-dialog NOTIFY as per RFC 6665.
KSR.rr.record_route();
end
KSR.dbg("EP: ksr_route_withindlg loose route calling 
ksr_route_relay\n");
ksr_route_relay();
KSR.dbg("EP: ksr_route_withindlg exit\n");
KSR.x.exit();
end
if KSR.is_ACK() then
if KSR.tm.t_check_trans() > 0 then
-- no loose-route, but stateful ACK;
-- must be an ACK after a 487
-- or e.g. 404 from upstream server
KSR.dbg("EP: ksr_route_withindlg is ACK calling ksr_route_relay\n");
ksr_route_relay();
KSR.dbg("EP: ksr_route_withindlg exit\n");
KSR.x.exit();
else
-- ACK without matching transaction ... ignore and discard
KSR.dbg("EP: ksr_route_withindlg Unknown ACK exit\n");
KSR.x.exit();
end
end
KSR.sl.sl_send_reply(404, "Not here");
KSR.dbg("EP: ksr_route_withindlg exit after 404\n");
KSR.x.exit();
end

And logs for the ACK:

Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (106/100/385) 
[[ACK sip:service@192.168.1.15:5060 SIP/2.0 0D  0A Via: SIP/2.0/UDP 
192.168.1.12:5060;branch=z9hG4bK-1091869]]
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 
(request) flags 1
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:677]: parse_msg(): SIP Request:
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:679]: parse_msg():  method:  
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:681]: parse_msg():  uri: 

Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:683]: parse_msg():  version: 
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name 
[Via] type 1
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, 
 = ; state=16
Nov 11

Re: [SR-Users] Kamailio dropping ACKs

2021-11-11 Thread ‪M S‬

Seems you forgot to add record route to invite, as a result there is no Route header in ACK, so loose route fails. Additionally there is no contact alias, so routing via alias also fails. Also it seems you are not creating SIP transactions and dialogs in script, you just blindly receiving sip request from one end and throwing it out to the other end!So only possible way to route ACK is to set destination URI, same way you do for INVITE. You will have to do that for EVERY sip request, unless you make your script intelligent enough to create and recognize sip transactions & dialogs properly.Hope this helps.--Muhammad Shahzad ShafiTel: +49 176 99 83 10 85Sent from my Huawei P40 5G phone Original message From: Emilio Panighetti Date: Thu, 11 Nov 2021, 18:44To: "Kamailio (SER) - Users Mailing List" Subject: [SR-Users] Kamailio dropping ACKsWorking on a proof of concept with Kamailio 5.5.2 (Installed via kamailio-5.5.2-0.el8.centos.x86_64 RPM from rpm.kamailio.org).Also note that this is using the LUA interfaceRunning a simple SIPp scenario without registration. Routing is set with in Lua:    KSR.dbg("EP: ksr_route_relay Check for Base Route\n");    if KSR.is_INVITE() and KSR.siputils.has_totag() < 0 then        KSR.dbg("EP: ksr_route_relay Base Route\n");        --KSR.sl.send_reply("503", "OLGX Debug");        KSR.setdsturi("sip:192.168.1.14:5060");        --KSR.pv.sets("$du", "sip:192.168.1.12:5062");    endThe problem is that Kamailio is dropping the ACK to the 200 OK from the UAS. Wireshark shows that the UAS is retransmitting the 200 OK and the ACK is not being forwarded from the UAC to the UAS.Within the Lua config script:-- Handle requests within SIP dialogsfunction ksr_route_withindlg()    if KSR.siputils.has_totag() < 0 then return 1; end    KSR.dbg("EP: ksr_route_withindlg has to-tag, it is within a dialog\n");    -- sequential request within a dialog should    -- take the path determined by record-routing    if KSR.rr.loose_route() > 0 then        ksr_route_dlguri();        if KSR.is_BYE() then            KSR.setflag(FLT_ACC); -- do accounting ...            KSR.setflag(FLT_ACCFAILED); -- ... even if the transaction fails        elseif KSR.is_ACK() then            -- ACK is forwarded statelessly            KSR.dbg("EP: ksr_route_withindlg Forwarding ACK\n");            ksr_route_natmanage();        elseif KSR.is_NOTIFY() then            -- Add Record-Route for in-dialog NOTIFY as per RFC 6665.            KSR.rr.record_route();        end        KSR.dbg("EP: ksr_route_withindlg loose route calling ksr_route_relay\n");        ksr_route_relay();        KSR.dbg("EP: ksr_route_withindlg exit\n");        KSR.x.exit();    end    if KSR.is_ACK() then        if KSR.tm.t_check_trans() > 0 then            -- no loose-route, but stateful ACK;            -- must be an ACK after a 487            -- or e.g. 404 from upstream server            KSR.dbg("EP: ksr_route_withindlg is ACK calling ksr_route_relay\n");            ksr_route_relay();            KSR.dbg("EP: ksr_route_withindlg exit\n");            KSR.x.exit();        else            -- ACK without matching transaction ... ignore and discard            KSR.dbg("EP: ksr_route_withindlg Unknown ACK exit\n");            KSR.x.exit();        end    end    KSR.sl.sl_send_reply(404, "Not here");    KSR.dbg("EP: ksr_route_withindlg exit after 404\n");    KSR.x.exit();endAnd logs for the ACK:Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (106/100/385) [[ACK sip:service@192.168.1.15:5060 SIP/2.0 0D  0A Via: SIP/2.0/UDP 192.168.1.12:5060;branch=z9hG4bK-1091869]]Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:677]: parse_msg(): SIP Request:Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:679]: parse_msg():  method:  Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:681]: parse_msg():  uri:     Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:683]: parse_msg():  version: Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Via] type 1Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232,  = ; state=16Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  [core/parser/msg_parser.c:557]: parse_headers(): this is the first viaNov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:

[SR-Users] Kamailio dropping ACKs

2021-11-11 Thread Emilio Panighetti

Working on a proof of concept with Kamailio 5.5.2 (Installed via 
kamailio-5.5.2-0.el8.centos.x86_64 RPM from rpm.kamailio.org).
Also note that this is using the LUA interface

Running a simple SIPp scenario without registration. Routing is set with in Lua:
KSR.dbg("EP: ksr_route_relay Check for Base Route\n");
if KSR.is_INVITE() and KSR.siputils.has_totag() < 0 then
KSR.dbg("EP: ksr_route_relay Base Route\n");
--KSR.sl.send_reply("503", "OLGX Debug");
KSR.setdsturi("sip:192.168.1.14:5060");
--KSR.pv.sets("$du", "sip:192.168.1.12:5062");
end

The problem is that Kamailio is dropping the ACK to the 200 OK from the UAS. 
Wireshark shows that the UAS is retransmitting the 200 OK and the ACK is not 
being forwarded from the UAC to the UAS.


Within the Lua config script:

-- Handle requests within SIP dialogs
function ksr_route_withindlg()
if KSR.siputils.has_totag() < 0 then return 1; end
KSR.dbg("EP: ksr_route_withindlg has to-tag, it is within a dialog\n");

-- sequential request within a dialog should
-- take the path determined by record-routing
if KSR.rr.loose_route() > 0 then
ksr_route_dlguri();
if KSR.is_BYE() then
KSR.setflag(FLT_ACC); -- do accounting ...
KSR.setflag(FLT_ACCFAILED); -- ... even if the transaction fails
elseif KSR.is_ACK() then
-- ACK is forwarded statelessly
KSR.dbg("EP: ksr_route_withindlg Forwarding ACK\n");
ksr_route_natmanage();
elseif KSR.is_NOTIFY() then
-- Add Record-Route for in-dialog NOTIFY as per RFC 6665.
KSR.rr.record_route();
end
KSR.dbg("EP: ksr_route_withindlg loose route calling 
ksr_route_relay\n");
ksr_route_relay();
KSR.dbg("EP: ksr_route_withindlg exit\n");
KSR.x.exit();
end
if KSR.is_ACK() then
if KSR.tm.t_check_trans() > 0 then
-- no loose-route, but stateful ACK;
-- must be an ACK after a 487
-- or e.g. 404 from upstream server
KSR.dbg("EP: ksr_route_withindlg is ACK calling ksr_route_relay\n");
ksr_route_relay();
KSR.dbg("EP: ksr_route_withindlg exit\n");
KSR.x.exit();
else
-- ACK without matching transaction ... ignore and discard
KSR.dbg("EP: ksr_route_withindlg Unknown ACK exit\n");
KSR.x.exit();
end
end
KSR.sl.sl_send_reply(404, "Not here");
KSR.dbg("EP: ksr_route_withindlg exit after 404\n");
KSR.x.exit();
end

And logs for the ACK:

Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (106/100/385) 
[[ACK sip:service@192.168.1.15:5060 SIP/2.0 0D  0A Via: SIP/2.0/UDP 
192.168.1.12:5060;branch=z9hG4bK-1091869]]
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 
(request) flags 1
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:677]: parse_msg(): SIP Request:
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:679]: parse_msg():  method:  
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:681]: parse_msg():  uri: 

Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:683]: parse_msg():  version: 
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name 
[Via] type 1
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, 
 = ; state=16
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:557]: parse_headers(): this is the first via
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name 
[From] type 4
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name 
[To] type 3
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: 
tag=4088926SIPpTag014
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, 
state=29
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:173]: get_hdr_field():  [63]; 
uri=[sip:service@192.168.1.15:5060]
Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG:  
[core/parser/msg_parser.c:176]:

Re: [SR-Users] Forcing Outbound Socket

2021-11-11 Thread Arsen Semenov

It is possible with TCP. Moreover Kamailio is trying to reuse the tcp
connection whenever the destination address is matching an active one.
The standard way is good, but in the real world you could face some devices
which do not support "outbound" properly, so you can leverage functions
exposed by nathelper module to ensure correct routing.

On Thu, Nov 11, 2021 at 4:50 PM Ross McKillop  wrote:

>
>
> On 11 Nov 2021, at 07:22, Olle E. Johansson  wrote:
>
>
>
> 10 nov. 2021 kl. 18:21 skrev Ross McKillop :
>
> Hi,
>
> Thanks, I was almost certain that is set but it seems it may not be so
> will double check that, thank you :)
>
> Now to solve the other issue….
>
> Just a nit-picking note: All these are non-standard fixes. The standard
> based way is to use the outbound module, it’s the way to allow the sip
> server to use an inbound TCP connection for outbound requests. This applies
> to client2server connections.
>
> For server2server connections there is a requirement of mutual TLS auth in
> order to be able to reuse the connection in both directions
>
>
> I thought this would be possible with TCP too.
>
> I looked at the outbound module but this is a 'drop in' replacement for
> something that already exists, so I'm trying to avoid rewriting headers as
> would be required for flow IDs etc, however it's a definite preferred
> method for improvement.
>
> As an aside, and it may be the same issue in
> https://www.mail-archive.com/sr-users@lists.kamailio.org/msg15589.html,
> when you force an outbound socket on a specific port and a reply is
> received on that port, both $Rp and $Rut show the port on the first listen
> directive, not the port it was actually received on, which makes it a bit
> harder to do what I was trying to as well :/
>
> Ross
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Arsen Semenov
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Forcing Outbound Socket

2021-11-11 Thread Ross McKillop

> On 11 Nov 2021, at 07:22, Olle E. Johansson  wrote:
> 
> 
> 
>> 10 nov. 2021 kl. 18:21 skrev Ross McKillop > >:
>> 
>> Hi,
>> 
>> Thanks, I was almost certain that is set but it seems it may not be so will 
>> double check that, thank you :) 
>> 
>> Now to solve the other issue…. 
> Just a nit-picking note: All these are non-standard fixes. The standard based 
> way is to use the outbound module, it’s the way to allow the sip server to 
> use an inbound TCP connection for outbound requests. This applies to 
> client2server connections.
> 
> For server2server connections there is a requirement of mutual TLS auth in 
> order to be able to reuse the connection in both directions

I thought this would be possible with TCP too.

I looked at the outbound module but this is a 'drop in' replacement for 
something that already exists, so I'm trying to avoid rewriting headers as 
would be required for flow IDs etc, however it's a definite preferred method 
for improvement.

As an aside, and it may be the same issue in 
https://www.mail-archive.com/sr-users@lists.kamailio.org/msg15589.html 
, when 
you force an outbound socket on a specific port and a reply is received on that 
port, both $Rp and $Rut show the port on the first listen directive, not the 
port it was actually received on, which makes it a bit harder to do what I was 
trying to as well :/

Ross

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio dropping ACKs

Re: [SR-Users] Kamailio dropping ACKs

Re: [SR-Users] Kamailio dropping ACKs

Re: [SR-Users] Kamailio dropping ACKs

[SR-Users] Kamailio dropping ACKs

Re: [SR-Users] Forcing Outbound Socket

Re: [SR-Users] Forcing Outbound Socket

7 matches

Site Navigation

Mail list logo

Footer information