[SR-Users] Fwd: Dispatcher module and hash algorithm
Hello, I had to resend this message, because the original has been waiting forever for "moderator approval", because it exceeded the 150KB limit. I deleted the screenshot with the wireshark trace, that was probably the cause of the size. Best regards, Luis Forwarded Message Subject:Dispatcher module and hash algorithm Date: Fri, 12 Jun 2020 12:10:58 -0400 From: Luis Rojas G. Reply-To: luis.ro...@sixbell.com To: Kamailio (SER) - Users Mailing List Hello, I noticed a couple of strange behaviors, using this version : kamailio-5.3.3-4.1.x86_64 I am using algorithm "0". Hash over Call-ID. The reason for that is that I am just re-sending the message, using send_udp(), to a destination in a group from file dispatcher.list. Kamailio is completely stateless, it does not need to remember anything. And using a hash over Call-ID I can be sure that any other message related to the same call will be sent to the same destination : retransmissions of the INVITE, CANCEL, ACK, BYE, etc. I general, it works, but I detected two problems. I have a group of 5 destinations, where every server is running at 80% of the nominal load. It's a 4 + 1 configuration, for redundancy. I know it's not 100% evenly distributed using hash over Call-ID, but in practice it's almost perfectly even. However, if one node is down, instead of having the four alive running at 100%, I get three running still at 80% capacity, and one is sent 160% of the load (which of course can't process). it seems, all traffic that was supposed to be sent to the failed node is transferred to the same unique destination. That implementation makes my solution for redundancy worthless. Why didn't the implementation use, for instance, a re-hash over the hash? That would allow to redistribute "evenly" over the remaining servers. I tried to solve this by repeating the entries in dispatcher.list, as I noticed that kamailio doesn't check if different lines contain duplicated uris. For instance, if I have two lines with "destination A", and one line with "destination B", like this: 0 sip:server_A 0 sip:server_A 0 sip:server_B I see that "destination A" receives twice the amount of SIP OPTIONS that "destination B" receives. And so, I used this dispatcher.list : 0 sip:server_1 0 sip:server_2 0 sip:server_3 0 sip:server_4 0 sip:server_5 0 sip:server_1 0 sip:server_3 0 sip:server_5 0 sip:server_2 0 sip:server_4 0 sip:server_1 0 sip:server_4 0 sip:server_2 0 sip:server_5 0 sip:server_3 0 sip:server_1 0 sip:server_5 0 sip:server_4 0 sip:server_3 0 sip:server_2 (it's not a random order. It follows a sequence) I thought : "what a genius I am. This way, if any node fails, and kamailio select the "next" to send the traffic to, it will distribute evenly over the rest". It doesn't work. I detected something that looks like a bug. If one entry is repeated at least once, for instance : 0 sip:server_1 0 sip:server_1 0 sip:server_2 0 sip:server_3 0 sip:server_4 0 sip:server_5 if server_1 is down, kamailio still sends some of the INVITEs to it. Not all of them, but many. I can see the SIP OPTIONS been sent to it, and the response "ICMP Destination Unreachable", so Kamailio knows that server_down. However, still sends INVITE requests to that failed node. Look at this trace : [ screenshot deleted, but believe me it is as I described it] You can see all the failed SIP OPTIONS. Still, kamailio sends traffic to that server. It does not send traffic to a failed destination if it's listed only once in dispatcher.list Any ideas? Thanks in advance, Luis -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to get cause from reason header?
On 5/8/20 4:21 PM, Denys Pozniak wrote:
Try this one:
$(hdr(Reason){param.value,cause})
Wonderful!!
Thanks a lot,
Luis
пт, 8 мая 2020 г. в 21:57, Luis Rojas G. <mailto:luis.ro...@sixbell.com>>:
Hello,
That is one of the parts I read, but to transform something first
I would need something to transform.
I don't know how to get the cause from the header. I was reading
this :
https://kamailio.org/docs/modules/5.3.x/modules/textopsx.html#textopsx.sel.hf_value
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkamailio.org%2Fdocs%2Fmodules%2F5.3.x%2Fmodules%2Ftextopsx.html%23textopsx.sel.hf_value=02%7C01%7C%7C41a6de06d98740013e8b08d7f38d66cf%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245660962672571=75sVlNzFQPs888UkJmMFevIpKsiadfLlM7ciOHq9Rp0%3D=0>
It gives some nice examples, like :
$b = @hf_value.p_associated_uri;
$rr = @hf_value.route.uri;
$prt = @hf_value2.authorization.integrity_protected;
What about @hf_value.reason.cause or @hf_value2.reason.cause ?
They don't even compile.
0(3848) ERROR: [core/select.c:299]: resolve_select():
Unable to resolve select 'cause' at level 2
0(3848) ERROR: [core/rvalue.c:2893]: fix_rval(): Unable to
resolve select in cfg at line: 209 col: 42
0(3848) ERROR: [core/select.c:434]: log_select(): select(
0(3848) ERROR: [core/select.c:439]: log_select():
hf_value2, 0(3848) ERROR: [core/select.c:439]: log_select():
, 0(3848) ERROR: [core/select.c:439]:
log_select(): cause, 0(3848) ERROR: [core/select.c:442]:
log_select(): )
Luis
On 5/8/20 2:42 PM, Denys Pozniak wrote:
Hello!
Did you try Parameters List Transformations?
https://www.kamailio.org/wiki/cookbooks/devel/transformations#parameters_list_transformations
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Ftransformations%23parameters_list_transformations=02%7C01%7C%7C41a6de06d98740013e8b08d7f38d66cf%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245660962682566=q5qkLPKpaNSKN9kfmkYV9GgUfpFV84Qv0SDkXdxqT90%3D=0>
пт, 8 мая 2020 г. в 19:32, Luis Rojas G. mailto:luis.ro...@sixbell.com>>:
Hello,
I am sure that this is very easy to do, but I have been
googling and I
can't find a way.
Having a Reason header, for instance :
Reason: SIP;cause=Some_Cause;text="Some_text"
How can I get the value of "Some_Cause"? I need to compare it
to some
specific numeric values...
Thanks in advance,
Luis
--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:luis.ro...@sixbell.com <mailto:luis.ro...@sixbell.com>
http://www.sixbell.com
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F=02%7C01%7C%7C41a6de06d98740013e8b08d7f38d66cf%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245660962692559=nS0PdNyxQ2qXDLm4S7PKH62dR1sVqZrFgAoJTFMy8J4%3D=0>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users=02%7C01%7C%7C41a6de06d98740013e8b08d7f38d66cf%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245660962692559=%2F4yahCz4hPIc5KTTntOi%2FOZ0ZFAWshRdtuUDz5z70t8%3D=0>
--
BR,
Denys Pozniak
--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:luis.ro...@sixbell.com
http://www.sixbell.com
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F=02%7C01%7C%7C41a6de06d98740013e8b08d7f38d66cf%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245660962702553=O6eOmYSw5RnpQmGKUfnjEHJsSk7u3DPRnuogok1VH7I%3D=0>
--
BR,
Denys Pozniak
--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:luis.ro...@sixbell.com
http://www.sixbell.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to get cause from reason header?
Hello, That is one of the parts I read, but to transform something first I would need something to transform. I don't know how to get the cause from the header. I was reading this : https://kamailio.org/docs/modules/5.3.x/modules/textopsx.html#textopsx.sel.hf_value It gives some nice examples, like : $b = @hf_value.p_associated_uri; $rr = @hf_value.route.uri; $prt = @hf_value2.authorization.integrity_protected; What about @hf_value.reason.cause or @hf_value2.reason.cause ? They don't even compile. 0(3848) ERROR: [core/select.c:299]: resolve_select(): Unable to resolve select 'cause' at level 2 0(3848) ERROR: [core/rvalue.c:2893]: fix_rval(): Unable to resolve select in cfg at line: 209 col: 42 0(3848) ERROR: [core/select.c:434]: log_select(): select( 0(3848) ERROR: [core/select.c:439]: log_select(): hf_value2, 0(3848) ERROR: [core/select.c:439]: log_select(): , 0(3848) ERROR: [core/select.c:439]: log_select(): cause, 0(3848) ERROR: [core/select.c:442]: log_select(): ) Luis On 5/8/20 2:42 PM, Denys Pozniak wrote: Hello! Did you try Parameters List Transformations? https://www.kamailio.org/wiki/cookbooks/devel/transformations#parameters_list_transformations <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Ftransformations%23parameters_list_transformations=02%7C01%7C%7Ca702e4ab30164604fec508d7f37f9be0%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245601731466978=ub57diRdKH%2Bv7AmwCXz82DqhyiCriw1bu5U%2FEn9OZyQ%3D=0> пт, 8 мая 2020 г. в 19:32, Luis Rojas G. <mailto:luis.ro...@sixbell.com>>: Hello, I am sure that this is very easy to do, but I have been googling and I can't find a way. Having a Reason header, for instance : Reason: SIP;cause=Some_Cause;text="Some_text" How can I get the value of "Some_Cause"? I need to compare it to some specific numeric values... Thanks in advance, Luis -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com <mailto:luis.ro...@sixbell.com> http://www.sixbell.com <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F=02%7C01%7C%7Ca702e4ab30164604fec508d7f37f9be0%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245601731466978=6PUKqMIEB%2FK%2BkcgxsYJ7pMxifhVh5y96ymcHjYF%2F5rM%3D=0> ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users=02%7C01%7C%7Ca702e4ab30164604fec508d7f37f9be0%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637245601731476971=1c6ILaqdc1paDW6Bon83APNAwq1eJ7TatMfPPyMbDQk%3D=0> -- BR, Denys Pozniak -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] How to get cause from reason header?
Hello, I am sure that this is very easy to do, but I have been googling and I can't find a way. Having a Reason header, for instance : Reason: SIP;cause=Some_Cause;text="Some_text" How can I get the value of "Some_Cause"? I need to compare it to some specific numeric values... Thanks in advance, Luis -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hi, Alex,
Thanks for all the details. Wow, such nice implementation. It requires a
deep knowledge of Kamailio.
I see, this is the part where the transaction is saved.
mq_add("reinvite_q", "$T(id_index):$T(id_label)", "");
I didn't know much about pseudo-variables. I am reading now.
https://www.kamailio.org/wiki/cookbooks/5.3.x/pseudovariables#tmx_module_pseudo-variables
I guess, this approach could help me also in case of replies, not just
requests, to add a delay to 200 OK to Invite.
By the way, I assigned a value to "async_workers", and now the Invite (I
was delaying any Invite, not just reinvite, just to test the api) is
propagated delayed, which is great, but at the same time a
SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)
is sent back to the origin, just killing the call.
I'll start playing with mqueue and rtimer.
Thanks again!
Luis
On 4/14/20 5:26 PM, Alex Balashov wrote:
Hi Luis,
Rather confusingly, there is an 'async_workers' parameter in the core as
well, which needs to be set:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2F5.3.x%2Fcore%23async_workersdata=02%7C01%7C%7Ca8cbe9ce15c24b5ee8e408d7e0babd56%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637224964985365901sdata=IvnQkD9Binyea0p5mRSnjUaNK%2BcKWM3YjOG8RcyKB9s%3Dreserved=0
There is some relationship between 'async_workers' in the core and the
'workers' modparam in the 'async' module which is explained by Daniel
somewhere in a past mailing list thread, but I do not remember it
offhand. I really should dig it out and update the documentation with
this nuance.
Having said that, I did not use the 'async' framework for my fix, but
rather 'mqueue' and 'rtimer'. I have no real justification for that;
just custom, habit and comfort with those mechanisms. I grew accustomed
to them at a time when I had some issues with 100% CPU utilisation in a
virtualised (Xen) environment when using early versions of the 'async'
concepts.
1) The first thing is to create a reinvite queue; a single one will do,
since it's specifically designed to be multiprocess-safe:
loadmodule "mqueue"
modparam("mqueue", "mqueue", "name=reinvite_q");
2) Then I create 12 'rtimer' processes to consume this queue, each
having a 10,000 usec re-invocation delay:
loadmodule "rtimer"
modparam("rtimer", "timer", "name=reinvite_q1;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q1;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q2;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q2;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q3;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q3;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q4;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q4;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q5;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q5;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q6;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q6;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q7;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q7;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q8;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q8;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q9;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q9;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q10;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q10;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q11;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q11;route=REINVITE_DEQUEUE")
modparam("rtimer", "timer", "name=reinvite_q12;interval=1u;mode=1;")
modparam("rtimer", "exec", "timer=reinvite_q12;route=REINVITE_DEQUEUE")
3) I then add this handling for reinvites to the loose_route() block in
the main request route -- logging and other extraneous matter omitted:
---
if(has_totag()) {
if(loose_route()) {
if(is_method("INVITE")) {
if(!t_suspend()) {
sl_send_reply("500", "Internal Server Error");
exit;
}
mq_add("reinvite_q", "$T(id_index):$T(id_label)", "");
} else {
# Normal in-dialog request handling, t_relay() and that.
route(IN_DLG_REQ);
}
}
}
---
And the handler on the other side, when the transaction is reanimated,
as it were:
---
route[REINVITE_DEQUEUE] {
while(mq_fetch("reinvite_q")) {
xlog("L_INFO", "[R-REINVITE-DEQUEUE:$ci] -> Resuming re-invite handling
($TV(Sn)) in PID $pp\n");
$var(id) = $(mqk(reinvite_q){s.select,0,:}{s.int});
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, Alex,
How specifically did you solve that scenario (ACK-Re-Invite)? Would you
mind sharing that part of your script? I have been trying to do that,
but can't make it work. I was working on the requests, to see how Async
works.
If I put it just in request_route, for instance, where record_route is put :
if (is_method("INVITE|SUBSCRIBE")) {
if (is_method("INVITE")) {
async_ms_sleep(20);
}
record_route();
}
I get this error :
1(18720) ERROR: async [async_mod.c:246]: w_async_ms_sleep(): cannot be
executed as last action in a route block
I tried in route[DISPATCH]
route[DISPATCH] {
# round robin dispatching on gateways group '1'
if(!ds_select_dst("1", "0")) {
send_reply("404", "No destination");
exit;
}
xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");
t_on_failure("RTF_DISPATCH");
async_ms_sleep(10);
forward();
# route(RELAY);
exit;
}
I get this error :
17(18736) WARNING: [core/async_task.c:244]: async_task_push():
async task pushed, but no async workers - ignoring
No async workers? Why? I have this at the beginning of file :
loadmodule "async.so"
modparam("async", "workers", 4)
modparam("async", "ms_timer", 5)
Please, any advice.
Luis
On 4/9/20 9:49 AM, Alex Balashov wrote:
On Thu, Apr 09, 2020 at 08:14:02AM -0400, Luis Rojas G. wrote:
Yes, I know that specifically in this case, from the point fo view of
SIP, it's not "much" important. It's just a symptom than I can't rely
on Kamailio to keep the ordering of messages when they are very very
close in time. With this customer (a Brazilian mobile operator) I have
seen scenarios where they send Re-Invite immediately after ACK, and
sometimes it caused us problems. I can't think right now in other
scenario,, but I'm afraid to find out in production. For what I see
the Async module, as it is now, could help me to deal with requests.
However, even though it's not a problem for SIP, the operator will
complain, I know them. And also, they will not like to just drop the
180, because there will be scenarios with interworking, so it needs to
propagate the ACM ISUP body, with parameters as backward call
indicators.
Agreed that you need to conserve signalling messages end-to-end, as a
matter of principle; can't just drop things.
As I mentioned earlier, we had the same problem--ironically, with a
major mobile operator--sending reinvites and e2e ACKs almost
contemporaneously. We solved it with 'async' by delaying all reinvites
by 50 ms, and haven't had a single complaint since.
Aside from that specific scenario, we haven't seen ordering problems,
and have never had cause to call into question whether we can 'rely' on
Kamailio to conserve ordering.
There are valid questions raised in this thread about whether any
user-space SIP element subject to the vicissitudes and realities of
packet-switched networking can be relied upon to preserve ordering in a
consistent and universal way.
At the end of the day, this is a network problem. PSTN interworking is
imperfect; it imposes synchronous assumptions upon asynchronous media,
and we see this play out in many areas, e.g. fax. Not much you can do
about it, but thankfully the corner cases are relatively few.
-- Alex
--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:luis.ro...@sixbell.com
http://www.sixbell.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Using dispatcher module : Modifying message before dispatching with send_udp()
Great, thanks! it works! Best regards, Luis On 4/13/20 1:54 PM, Daniel-Constantin Mierla wrote: Hello, use msg_apply_changes() (from textopsx) before send_udp(). Cheers, Daniel On 13.04.20 18:02, Luis Rojas G. wrote: Hello, I am using the dispatcher module, Kamailio version 5.3.3. The point is, I am using send_udp() to forward the message, because I don't want Kamailio to add headers Via nor Record-Route. I am just dispatching the Invite message, and the rest of communication to be made just between the endpoints, not through Kamailio. However, I need to add before a custom header, using append_hf(). It seems, send_udp() really changes nothing at all in the message, not even something added by the script with append_hf(). It works if I use forward(), but not if I use send_udp(). Is there a way to accomplish this? Best regards, -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2Fdata=02%7C01%7C%7C5c9e6b2c71b04559013508d7dfd3a880%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637223972496531226sdata=jwlypRLkYiufs4wA3WTF8mPiQMuMgE01CBH2sbFAOcw%3Dreserved=0 ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-usersdata=02%7C01%7C%7C5c9e6b2c71b04559013508d7dfd3a880%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637223972496531226sdata=FyW6GLrfJMqqDZGJguamvcaqIeqyCKSF9jQ5ptD7H4s%3Dreserved=0 -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Using dispatcher module : Modifying message before dispatching with send_udp()
Hello, I am using the dispatcher module, Kamailio version 5.3.3. The point is, I am using send_udp() to forward the message, because I don't want Kamailio to add headers Via nor Record-Route. I am just dispatching the Invite message, and the rest of communication to be made just between the endpoints, not through Kamailio. However, I need to add before a custom header, using append_hf(). It seems, send_udp() really changes nothing at all in the message, not even something added by the script with append_hf(). It works if I use forward(), but not if I use send_udp(). Is there a way to accomplish this? Best regards, -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Callee BYE routing issue
On 4/11/20 12:24 PM, Alex Balashov wrote: Indeed. The From/To headers are cosmetic in this regard; no attribute of them would cause a routing problem[1]. -- Alex [1] Well, except for missing tags, I suppose; but even then, this would not pose a routing problem, just a dialog party identification problem to one or more UAs. Hello, What about a syntax error in those headers? I am curious about this : "sip:398@ B2BUA_IP:" Why a space after "@"? Best regards, Luis -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hi, Alex, It's 16 virtual cores (8 physical plus HyperThreading) and 48GB of RAM. Luis On 4/10/20 8:02 AM, Alex Balashov wrote: Luis, I wonder, how many CPU cores/available hardware threads (taking into account HyperThreading and all that—so just the number of CPUs in /proc/cpuinfo) are available here? It almost sounds like something which would occur with maybe 1 or 2 CPUs being contended over. Perhaps the simplest thing for this kind of call volume is to run Kamailio on a host with 8 or 12+ CPU cores? — Alex — Sent from my iPad On Apr 10, 2020, at 2:20 AM, Luis Rojas G. wrote: Hello, I have a lot of experience developing mutithreaded applications, and I don't see it so unlikely at all that a process loses cpu just after recvfrom(). It's just as probable as to lose it just before, or when writing on a cache or just before of after sendto(). If there are many messages going through, some of them will fall in this scenario. if I try sending a burst of 100 messages, I see two or three presenting the scenario. Just forward() with a single process does not give the capacity. I'm getting almost 1000caps. More than that and start getting errores, retransmissions, etc. And this is just one way. I need to receive the call to go back to the network (our application is a B2BUA), so I will be down to 500caps, with a simple scenario, with no reliable responses, reinvites, updates, etc. I will end up having as many standalone kamailio processes as the current servers I do have now. I really think the simplest way would be to add a small delay to 200 OK. Very small, like 10ms, should be enough. Simple and it should work. As Alex Balashov commented he did for the case with ACK-Re-Invite. I have to figure out how to make async_ms_sleep() work in reply_route(). Thanks for all the comments and ideas Best regards, Luis . On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote: mico...@gmail.com appears similar to someone who previously sent you email, but may not be that person. Learn why this could be a risk <http://aka.ms/LearnAboutSenderIdentification> Feedback <http://aka.ms/SafetyTipsFeedback> Hello, then the overtaking is in between reading from the socket and getting to parsing the call-id value -- the cpu is lost by first reader after recvfrom() and the second process get enough cpu time to go ahead further. I haven't encountered this case, but as I said previously, it is very unlikely, but still possible. I added the route_locks_size because in the past I had cases when processing of some messages took longer executing config (e.g., due to authentication, accounting, ..) and I needed to be sure they are processed in the order they enter config execution. Then the option is to see if a single process with stateless sending out (using forward()) gives the capacity, if you don't do any other complex processing. Or if you do more complex processing, use a dispatcher process with forwarding to local host or in a similar manner try to use mqueue+rtimer for dispatching using shared memory queues. Of course, it is open source and there is also the C coding way, to add a synchronizing mechanism to protect against parallel execution of the code from recvfrom() till call-id lock is acquired. Cheers, Daniel On 09.04.20 17:37, Luis Rojas G. wrote: Hello, Well, it did not work at all. Exactly same behavior, with random out of order messages. Best regards, Luis On 4/9/20 11:28 AM, Daniel-Constantin Mierla wrote: mico...@gmail.com appears similar to someone who previously sent you email, but may not be that person. Learn why this could be a risk <http://aka.ms/LearnAboutSenderIdentification> Feedback <http://aka.ms/SafetyTipsFeedback> Hello, the sip messages belonging to the same dialog have the same value for Call-Id header. The locking is done based on hashing the Call-Id, so it doesn't need at all the dialog module for its purpose. Cheers, Daniel On 09.04.20 14:19, Luis Rojas G. wrote: Hello, Daniel, I am not so sure. I first tried adding that parameter, but it did not work at all. Same behavior. Then I read the documentation more carefully : https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size route_locks_size Set the number of mutex locks to be used for synchronizing the execution of messages sharing the same Call-Id. In other words, enables Kamailio to execute the config script sequentially for the requests and replies received *within the same dialog* – a new message received *within the same dialog* waits until the previous one is routed out. Locks to execute sequentially messages belonging to same dialog. How will Kamailio be aware that messages belong to same dialog, without the dialog module?. With just stateless proxy it has no idea about dialogs, it just forwards messages. I guess that's why just adding that parameter did not w
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, Daniel,
Yes, yes, yes, you are right. I got confused for a moment. Yes, the
criteria for dispatcher is only for the request. And so, it will have
no effect on the replies. On the replies only the via headers are
considered. Wel, moving to round robin increased the throughput for a
single instance. Now it can process over 1000 CAPS.
For the scenario ack-reinvite, the solution adding a small delay for
re-invite, using something like async_ms_sleep() will solve it, so I am
not worried ( I mentioned on a previous post that I have seen also that
scenario happening with this operator. Re-invite immediately after ACK,
and it caused us problems)
My problem is still 180-200. it will not matter the number of processes
or cores. In the end, it's a classical multi-process/multi-threaded race
condition. Considering the architecture of Kamailio, with multiple
processes, the problem will appear. And the more the traffic, the more
close in time 180 and 200 are, the more it will happen. With my currents
test, with 180 and 200 very close, I am getting around 0.5% of cases
suffering from that condition.
I know, if you think in "only SIP", yes, it's not so important the 180.
it's important in my case, because my customer is very complicated, and
they will not like to see messages coming to our platform in one order
and going out in other.
And the second : it's not only SIP. they usually have interworking, and
180 then will carry an ISUP ACM body that is important. As I mentioned
in a previous post, for instance, the Backward Call Indicators, with
very important subfields like the Charge Indicator.
I understand. It's UDP. Messages can be lost on the network. OK.
Messages can arrive out of order. OK. But i't s pity that if messages
were not lost and arrived in order, they leave kamailio out of order.
So far the only solution I see is to try to insert a small delay before
forwarding the 200.
Best rgards,
Luis
On 4/9/20 3:58 PM, Daniel-Constantin Mierla wrote:
mico...@gmail.com appears similar to someone who previously sent you
email, but may not be that person. Learn why this could be a risk
<http://aka.ms/LearnAboutSenderIdentification>
Feedback <http://aka.ms/SafetyTipsFeedback>
Hello,
dispatcher has nothing to do with handling sip replies. It is intended
only for routing sip requests. If you use dispatcher for replies, you
do it wrong, just let kamailio route them based on Via headers.
So maybe I was looking at the wrong message flow processing, I was
speaking mainly about the case when the caller sends quickly the
reINVITE after the ACK to the initial INVITE 200ok and the reINVITE
gets to callee before the ACK. That was more of a branching in
discussion on Alex' remarks and the situation that I enocountered in
the past and created troubles. Never had to deal with troubles caused
by change of order between 180 and 200. In IP world, if the time
between 180 and 200 is very short, it doesn't matter at all, because
the 180 is for start play a ring tone, which a human may not even hear
it when 200 comes 50ms after it.
If you face the re-ordering for replies, then Kamailio doesn't do much
internally if you don't have reply_route{} (as well as no
onsend_route) in config file, provided that you do not use tm module
for sending out (and by that no onreply_route or failure_route).
For a sip reply, kamilio is parsing the headers to find the 2nd Via
header and use that address to send out the reply. The request route
is not executed for sip replies.
What you can try is to set number of kamailio processes not to exceed
the number of CPU cores, so there is "no real competition" to get CPU
cycles. It could improve a bit, but still not a 100% accuracy (ie.,
there are other processes running on the system).
Cheers,
Daniel
On 09.04.20 21:29, Luis Rojas G. wrote:
Hello,
I just realized that I had the dispatcher configured using a hash of
Call-ID. That means, after recvfrom there must be an extra
processing finding the Call-ID header in message, to calculate a hash
and then forward() message. The more the processing, the more cases
when 200 could arrive before 180. I just changed it to round robin,
and the amount decreased a lot, but it's still there. If I send a
burst of 1000 messages, about 5 of them leave out of order every time.
Best regards,
Luis
On 4/9/20 1:48 PM, Luis Rojas G. wrote:
Hello,
I have a lot of experience developing mutithreaded applications, and
I don't see it so unlikely at all that a process loses cpu just
after recvfrom(). It's just as probable as to lose it just before,
or when writing on a cache or just before of after sendto(). If
there are many messages going through, some of them will fall in
this scenario. if I try sending a burst of 100 messages, I see two
or three presenting the scenario.
Just forward() with a single process does not give the capaci
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, I just realized that I had the dispatcher configured using a hash of Call-ID. That means, after recvfrom there must be an extra processing finding the Call-ID header in message, to calculate a hash and then forward() message. The more the processing, the more cases when 200 could arrive before 180. I just changed it to round robin, and the amount decreased a lot, but it's still there. If I send a burst of 1000 messages, about 5 of them leave out of order every time. Best regards, Luis On 4/9/20 1:48 PM, Luis Rojas G. wrote: Hello, I have a lot of experience developing mutithreaded applications, and I don't see it so unlikely at all that a process loses cpu just after recvfrom(). It's just as probable as to lose it just before, or when writing on a cache or just before of after sendto(). If there are many messages going through, some of them will fall in this scenario. if I try sending a burst of 100 messages, I see two or three presenting the scenario. Just forward() with a single process does not give the capacity. I'm getting almost 1000caps. More than that and start getting errores, retransmissions, etc. And this is just one way. I need to receive the call to go back to the network (our application is a B2BUA), so I will be down to 500caps, with a simple scenario, with no reliable responses, reinvites, updates, etc. I will end up having as many standalone kamailio processes as the current servers I do have now. I really think the simplest way would be to add a small delay to 200 OK. Very small, like 10ms, should be enough. Simple and it should work. As Alex Balashov commented he did for the case with ACK-Re-Invite. I have to figure out how to make async_ms_sleep() work in reply_route(). Thanks for all the comments and ideas Best regards, Luis . On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote: mico...@gmail.com appears similar to someone who previously sent you email, but may not be that person. Learn why this could be a risk <http://aka.ms/LearnAboutSenderIdentification> Feedback <http://aka.ms/SafetyTipsFeedback> Hello, then the overtaking is in between reading from the socket and getting to parsing the call-id value -- the cpu is lost by first reader after recvfrom() and the second process get enough cpu time to go ahead further. I haven't encountered this case, but as I said previously, it is very unlikely, but still possible. I added the route_locks_size because in the past I had cases when processing of some messages took longer executing config (e.g., due to authentication, accounting, ..) and I needed to be sure they are processed in the order they enter config execution. Then the option is to see if a single process with stateless sending out (using forward()) gives the capacity, if you don't do any other complex processing. Or if you do more complex processing, use a dispatcher process with forwarding to local host or in a similar manner try to use mqueue+rtimer for dispatching using shared memory queues. Of course, it is open source and there is also the C coding way, to add a synchronizing mechanism to protect against parallel execution of the code from recvfrom() till call-id lock is acquired. Cheers, Daniel -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Actually, I was looking at the code yesterday, trying to figure it if it's just a validation, to not accept reply_route(), or if it needs some more logic to work inside that block. It's still an option. Best regards, Luis On 4/9/20 4:25 AM, Daniel-Constantin Mierla wrote: On 09.04.20 09:47, Daniel-Constantin Mierla wrote: [...] Any idea why Async is not allowed in reply_route()? Didn't notice this question in the first place to respond in my previous email. Probably the developer that did it needed it for SIP requests. However, you can make a patch (pull request) to make it work for other cases. The developers will review the changes and if they don't break anything, it will be merged. Cheers, Daniel . -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, Daniel, I am not so sure. I first tried adding that parameter, but it did not work at all. Same behavior. Then I read the documentation more carefully : https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size route_locks_size Set the number of mutex locks to be used for synchronizing the execution of messages sharing the same Call-Id. In other words, enables Kamailio to execute the config script sequentially for the requests and replies received *within the same dialog* – a new message received *within the same dialog* waits until the previous one is routed out. Locks to execute sequentially messages belonging to same dialog. How will Kamailio be aware that messages belong to same dialog, without the dialog module?. With just stateless proxy it has no idea about dialogs, it just forwards messages. I guess that's why just adding that parameter did not work. Am I wrong? Luis On 4/9/20 3:47 AM, Daniel-Constantin Mierla wrote: Hello, On 08.04.20 23:03, Luis Rojas G. wrote: Hello, Daniel, I looked into that parameter, but I need to use with the dialog module, and I'm pretty afraid to use that. who said or where is written than you need to load the dialog module? You definitely don't. Cheers, Daniel I was looking more into the stateless proxy, because I need to process a lot of traffic. My target is 4200CAPS. with duration between 90s and 210. Let's say, 150 seconds. That would mean 630.000 simultaneous dialogs. I don't think the solution can go that way. it would really help me to be able to use completely stateless proxy plus Async in reply_route(), to introduce an artificial delay before forwarding 200 OK to Invite.. As someone mentioned, it would help me on request_route(), for race conditions between ACK and Re-Invite. Any idea why Async is not allowed in reply_route()? Best regards, Luis On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote: Hello, you have to keep in mind that Kamailio is a SIP packet router, not a telephony engine. If 180 and 200 replies are part of a call is not something that Kamailio recognize at its core. Its main goal is to route out as fast as possible what is received, by executing the configuration file script. Now, a matter of your configuration file, processing of some SIP messages can take longer than processing other. And the processing is done in parallel, a matter of children parameter (and tcp_children, sctp_children). With that in mind, a way to try to cope better with the issue you face is to set route_locks_size parameter, see: * https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size=02%7C01%7C%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764096691=P%2BETJg%2FH4%2BbbCR0Jtp6QpEx6QtBqdOr4saB7XKZbLYM%3D=0> Probably is what you look for. But if you want more tight constraints, like when receiving a 180 after a 200ok and not route it out, you have to make the logic in configuration file by combining modules such as dialog or htable (as already suggested). Cheers, Daniel On 08.04.20 16:04, Luis Rojas G. wrote: Hi, Henning, No need to be ironic. As I mentioned on my first post, I tried stateful proxy and I observed the same behavior. /"I tried using stateful proxy and I obtained the same result."/ The asynchronous sleep seems promising. I will look into it. Thanks, Luis On 4/8/20 9:30 AM, Henning Westerholt wrote: Hi Luis, I see. Well, you want to use Kamailio as a stateless proxy, on the other hand it should do things that are inherently stateful. As mentioned, have a look to the dialog module to track the state of dialogs that you process. This will not work in a stateless mode, though. You can also use the htable module to just store some data about the processed messages in a shared memory table and use this to enforce your ordering. There is also the option to do an asynchronous sleep (with the async) module on the message that you want to delay but still processing other messages during it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F=02%7C01%7C%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764096691=XZpyIXwvOjenJKg5MIt6pNESBbpF2RV0waycxScsrkU%3D=0> Kamailio services – https://gilawa.com <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F=02%7C01%7C%7C4ccc34db19ff4d0ca9b808d7dc5a4e1c%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220152764106687=CQbRA%2FVw6bAhHFVfuzuZh9zlrPzV%2B8jvZmIlCsc7Smk%3D=0> *From:* Luis Rojas G. *Sent:* Wednesday, April 8, 2020 3:00 PM *To:* Henning Westerholt ; Kamailio (SER) - Users Mailing List *Subje
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Yes, I know that specifically in this case, from the point fo view of SIP, it's not "much" important. It's just a symptom than I can't rely on Kamailio to keep the ordering of messages when they are very very close in time. With this customer (a Brazilian mobile operator) I have seen scenarios where they send Re-Invite immediately after ACK, and sometimes it caused us problems. I can't think right now in other scenario,, but I'm afraid to find out in production. For what I see the Async module, as it is now, could help me to deal with requests. However, even though it's not a problem for SIP, the operator will complain, I know them. And also, they will not like to just drop the 180, because there will be scenarios with interworking, so it needs to propagate the ACM ISUP body, with parameters as backward call indicators. Luis On 4/9/20 3:27 AM, Olle E. Johansson wrote: If you think about it, if the 200 OK is so close to the 180 it doesn’t really matter from a signalling standpoint if the 180 comes first or if it arrives after the 200 OK. It’s the 200 OK that is important. If the 180 comes after, it’s simply ignored and the dialog is established successfully. The 1xx is seldom significant (unless you have PRACK but that’s another story). Or do you really have a situation where the 180 is critical? /O On 8 Apr 2020, at 18:01, Steve Davies <mailto:steve-lists-srus...@connection-telecom.com>> wrote: Hi Luis, Kamailio architecture isn't going to change I'm sure. There is no central orchestrator - each worker process just grabs messages as fast as it can. If your processing is slow for some and fast for others then they can get out of order I reckon. 180s are really neither here nor there if there's a 200 OK right behind it. Perhaps a proxy like Drachtio would work better for you? Steve On Wed, 8 Apr 2020 at 17:44, Luis Rojas G. <mailto:luis.ro...@sixbell.com>> wrote: Hello, Henning, I am worried about this scenario, because it's a symptom of what may happen in other cases. For instance, I've seen that this operator usually sends re-invites immediate after sending ACK. This may create race conditions like 3.1.5 of RFC5407 https://tools.ietf.org/html/rfc5407#page-22 <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475291806=RAqaEpyoKIedkPmVMHa%2Fl72%2B3JBkU%2F7PyiAjCMqpr4E%3D=0> I'd understand that one happens because of packet loss, as it's in UDP's nature, but in this case it would be artificially created by Kamailio. if there was no problem at network level (packet loss, packets following different path on the network and arriving out of order), why Kamailio creates it? I'd expect that the shared memory is used precisely for this. If an instance of kamailio receives a 200 OK, it could check on the shm and say "hey, another instance is processing a 180 for this call. Let's wait for it to finish" (*). I know there could still be a problem, the instance processing the 180 undergoes a context switch just after it receives the message, but before writing to shm, but it would greatly reduce the chance. In our applications we use a SIP stack that always sends messages to the application in the same order it receives them, even though is multi-threaded and messages from the network are received by different threads. So, they really syncronize between them. Why Kamailio instances don't? I am evaluating kamailio to use it as a dispatcher to balance load against our several Application Servers, to present to the operator just a couple of entrance points to our platform (they don't want to establish connections to each one of our servers). This operator is very difficult to deal with. I am sure they will complain something like "why are you sending messages out of order? Fix that". The operator will be able to see traces and check that messages entered the Kamailio nodes in order and left out of order. They will not accept it. (*) Not really "wait", as it would introduce a delay in processing all messages. it should be like putting it on a queue, continue processing other messages, and go back to the queue later. Well, thanks for your answer. Luis On 4/8/20 3:01 AM, Henning Westerholt wrote: Hello Luis, as the 1xx responses are usually send unreliable (unless you use PRACK), you should not make any assumption on the order or even the arrival of this messages. It can also happens on a network level, if send by UDP. Can you elaborate why you think this re-ordering is a problem for you? One idea to enforce some ordering would be to use the dialog mo
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, Daniel, "Simple" does not mean "without processing". You could search for a word in a file several gigabytes long and it will take a lot of processing. Yet, it's very simple to do. And I have never seen an implementation where Call-ID is at the end of headers. Yes, it could be, but not probably, and it's not in my current scenario. Problem, as I said, is that a thread like that would become a bottleneck, considering all the tasks you mentioned. If I could support the required load (over 4000 CAPS) with only one process, I would not be having this problem of race conditions between different processes. if one process listening on public IP and port 5060 was able to process all messages. to send them to internal processes, then what do I need those processes for? Better to just forward directly to next hop. Best regards, Luis On 4/8/20 4:51 PM, Daniel-Constantin Mierla wrote: Hello, On 08.04.20 22:17, Luis Rojas G. wrote: Hi, Daniel, about this : A distributor thread (or process) won't help here, if it distributes traffic to other threads (processes) without waiting for them to finish, which ends up to be serial processing. The distributor role for UDP traffic is done by the kernel. For tcp/tls there is a distributor process for connections. Cheers, Daniel I disagree. A distributor thread could do something as simple as apply a hash to the Call-ID, Actually what you refer "as simple as" involves parsing sip headers to find call id, which can be at the end of the headers, meaning parsing the entire set of headers. Then managing the queues (insert, drop in case of over load (which is done by kernel now), ...) etc. So that process will do a lot of processing when having to deal with high volume of traffic. But my remark was about a pure packet dispatcher thread, without any dialog awareness processing. Alex followed up to clarify he thought more or less about a higher level dispatcher, aware of some states/dialog/etc... and use it to select the process to send the message to, without waiting. the process will recive all messages for a specific call-leg. it does not need to wait for an answer nor it needs states, as "which process is processing which message at any time". You should be able to achieve pretty much this kind of behaviour via configuration based routing - just sketching: - one process listen on port 5060 public ip - many single processes per one port listening on 127.0.0.1 - dispatch from the process on public ip to the processes on 127.0.0.1 with different ports - corex module offers functions to set source address and received socket for more flexibility why processing on 127.0.0.1 Cheers, Daniel I think the main problem is that it introduces a bottleneck, and break the main philosophy of Kamailio's architecture, having only individual processes. Best regards, Luis On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote: Hello, you have to keep in mind that Kamailio is a SIP packet router, not a telephony engine. If 180 and 200 replies are part of a call is not something that Kamailio recognize at its core. Its main goal is to route out as fast as possible what is received, by executing the configuration file script. Now, a matter of your configuration file, processing of some SIP messages can take longer than processing other. And the processing is done in parallel, a matter of children parameter (and tcp_children, sctp_children). With that in mind, a way to try to cope better with the issue you face is to set route_locks_size parameter, see: * https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935214080=WjIJRCkac%2FAYQ3lMSLZ4CcDLwAB723VVOYlkAhhuFg0%3D=0> Probably is what you look for. But if you want more tight constraints, like when receiving a 180 after a 200ok and not route it out, you have to make the logic in configuration file by combining modules such as dialog or htable (as already suggested). Cheers, Daniel On 08.04.20 16:04, Luis Rojas G. wrote: Hi, Henning, No need to be ironic. As I mentioned on my first post, I tried stateful proxy and I observed the same behavior. /"I tried using stateful proxy and I obtained the same result."/ The asynchronous sleep seems promising. I will look into it. Thanks, Luis On 4/8/20 9:30 AM, Henning Westerholt wrote: Hi Luis, I see. Well, you want to use Kamailio as a stateless proxy, on the other hand it should do things that are inherently stateful. As mentioned, have a look to the dialog module to track the state of dialogs that you process. This will not work in a stateless mode, though. You can also use the ht
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, Daniel, I looked into that parameter, but I need to use with the dialog module, and I'm pretty afraid to use that. I was looking more into the stateless proxy, because I need to process a lot of traffic. My target is 4200CAPS. with duration between 90s and 210. Let's say, 150 seconds. That would mean 630.000 simultaneous dialogs. I don't think the solution can go that way. it would really help me to be able to use completely stateless proxy plus Async in reply_route(), to introduce an artificial delay before forwarding 200 OK to Invite.. As someone mentioned, it would help me on request_route(), for race conditions between ACK and Re-Invite. Any idea why Async is not allowed in reply_route()? Best regards, Luis On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote: Hello, you have to keep in mind that Kamailio is a SIP packet router, not a telephony engine. If 180 and 200 replies are part of a call is not something that Kamailio recognize at its core. Its main goal is to route out as fast as possible what is received, by executing the configuration file script. Now, a matter of your configuration file, processing of some SIP messages can take longer than processing other. And the processing is done in parallel, a matter of children parameter (and tcp_children, sctp_children). With that in mind, a way to try to cope better with the issue you face is to set route_locks_size parameter, see: * https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481963069=CWh4qvJwYloHLPCOFUdVXRuge3l2rvuAUDM6FBNjFMA%3D=0> Probably is what you look for. But if you want more tight constraints, like when receiving a 180 after a 200ok and not route it out, you have to make the logic in configuration file by combining modules such as dialog or htable (as already suggested). Cheers, Daniel On 08.04.20 16:04, Luis Rojas G. wrote: Hi, Henning, No need to be ironic. As I mentioned on my first post, I tried stateful proxy and I observed the same behavior. /"I tried using stateful proxy and I obtained the same result."/ The asynchronous sleep seems promising. I will look into it. Thanks, Luis On 4/8/20 9:30 AM, Henning Westerholt wrote: Hi Luis, I see. Well, you want to use Kamailio as a stateless proxy, on the other hand it should do things that are inherently stateful. As mentioned, have a look to the dialog module to track the state of dialogs that you process. This will not work in a stateless mode, though. You can also use the htable module to just store some data about the processed messages in a shared memory table and use this to enforce your ordering. There is also the option to do an asynchronous sleep (with the async) module on the message that you want to delay but still processing other messages during it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481973065=ISKj4Fc0FlBemyJhLFeDaXPQjpOrjIceeXURx2OccqU%3D=0> Kamailio services – https://gilawa.com <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060=vsVGfGjX4ZgDN%2FyaxzSCmc5BHNa%2Buu0Y%2FFQLbW7ETOc%3D=0> *From:* Luis Rojas G. *Sent:* Wednesday, April 8, 2020 3:00 PM *To:* Henning Westerholt ; Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER Hello, Henning, I am worried about this scenario, because it's a symptom of what may happen in other cases. For instance, I've seen that this operator usually sends re-invites immediate after sending ACK. This may create race conditions like 3.1.5 of RFC5407 https://tools.ietf.org/html/rfc5407#page-22 <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060=FekMqBnzvOj4%2FVFnS9x0X5KdcA0Ov1gcb975iEzfWZE%3D=0> I'd understand that one happens because of packet loss, as it's in UDP's nature, but in this case it would be artificially created by Kamailio. if there was no problem at network level (packet loss, packets following different path on the network and arriving out of order), why Kamailio creates it? I'd expect that the shared memory is used precisely for this. If an instance of kamailio receives a 200 OK, it could check on the shm and say "hey, another instance is proc
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hi, Daniel, about this : A distributor thread (or process) won't help here, if it distributes traffic to other threads (processes) without waiting for them to finish, which ends up to be serial processing. The distributor role for UDP traffic is done by the kernel. For tcp/tls there is a distributor process for connections. Cheers, Daniel I disagree. A distributor thread could do something as simple as apply a hash to the Call-ID, and use it to select the process to send the message to, without waiting. the process will recive all messages for a specific call-leg. it does not need to wait for an answer nor it needs states, as "which process is processing which message at any time". I think the main problem is that it introduces a bottleneck, and break the main philosophy of Kamailio's architecture, having only individual processes. Best regards, Luis On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote: Hello, you have to keep in mind that Kamailio is a SIP packet router, not a telephony engine. If 180 and 200 replies are part of a call is not something that Kamailio recognize at its core. Its main goal is to route out as fast as possible what is received, by executing the configuration file script. Now, a matter of your configuration file, processing of some SIP messages can take longer than processing other. And the processing is done in parallel, a matter of children parameter (and tcp_children, sctp_children). With that in mind, a way to try to cope better with the issue you face is to set route_locks_size parameter, see: * https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481963069=CWh4qvJwYloHLPCOFUdVXRuge3l2rvuAUDM6FBNjFMA%3D=0> Probably is what you look for. But if you want more tight constraints, like when receiving a 180 after a 200ok and not route it out, you have to make the logic in configuration file by combining modules such as dialog or htable (as already suggested). Cheers, Daniel On 08.04.20 16:04, Luis Rojas G. wrote: Hi, Henning, No need to be ironic. As I mentioned on my first post, I tried stateful proxy and I observed the same behavior. /"I tried using stateful proxy and I obtained the same result."/ The asynchronous sleep seems promising. I will look into it. Thanks, Luis On 4/8/20 9:30 AM, Henning Westerholt wrote: Hi Luis, I see. Well, you want to use Kamailio as a stateless proxy, on the other hand it should do things that are inherently stateful. As mentioned, have a look to the dialog module to track the state of dialogs that you process. This will not work in a stateless mode, though. You can also use the htable module to just store some data about the processed messages in a shared memory table and use this to enforce your ordering. There is also the option to do an asynchronous sleep (with the async) module on the message that you want to delay but still processing other messages during it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481973065=ISKj4Fc0FlBemyJhLFeDaXPQjpOrjIceeXURx2OccqU%3D=0> Kamailio services – https://gilawa.com <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060=vsVGfGjX4ZgDN%2FyaxzSCmc5BHNa%2Buu0Y%2FFQLbW7ETOc%3D=0> *From:* Luis Rojas G. *Sent:* Wednesday, April 8, 2020 3:00 PM *To:* Henning Westerholt ; Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER Hello, Henning, I am worried about this scenario, because it's a symptom of what may happen in other cases. For instance, I've seen that this operator usually sends re-invites immediate after sending ACK. This may create race conditions like 3.1.5 of RFC5407 https://tools.ietf.org/html/rfc5407#page-22 <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060=FekMqBnzvOj4%2FVFnS9x0X5KdcA0Ov1gcb975iEzfWZE%3D=0> I'd understand that one happens because of packet loss, as it's in UDP's nature, but in this case it would be artificially created by Kamailio. if there was no problem at network level (packet loss, packets following different path on the network and arriving out of order), why Kamailio creates it? I'd expect that the shared memory is used pre
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, Daniel I will try this option. I tried the ASYNC, using async_ms_sleep, but it seems it's not allowed in reply_route(). I wonder why. Documentation only mentions request_route: https://kamailio.org/docs/modules/5.3.x/modules/async.html#async.f.async_ms_sleep if I use it in reply_route() kamailio does not even start. 0(22147) ERROR: [core/cfg.y:3402]: yyparse(): misused command async_ms_sleep 0(22147) CRITICAL: [core/cfg.y:3547]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 221, column 23: Command cannot be used in the block ERROR: bad config file (1 errors) I wanted to introduce an artificial delay of just a few miliseconds to 200 OK to INVITE. it's not just a problem about 180 and 200, but several other conditions that will start to appear, like betwen ACK-Reinvite. Anyone reading is the list administrator? I tried to subscribe to the list, bit it seems I am still not a member, so I don't receive answers (unless I am copied directly) and can't post immediately, only after moderator's approval. Also, I can't answer all responses. Best regards, Luis On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote: Hello, you have to keep in mind that Kamailio is a SIP packet router, not a telephony engine. If 180 and 200 replies are part of a call is not something that Kamailio recognize at its core. Its main goal is to route out as fast as possible what is received, by executing the configuration file script. Now, a matter of your configuration file, processing of some SIP messages can take longer than processing other. And the processing is done in parallel, a matter of children parameter (and tcp_children, sctp_children). With that in mind, a way to try to cope better with the issue you face is to set route_locks_size parameter, see: * https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481963069=CWh4qvJwYloHLPCOFUdVXRuge3l2rvuAUDM6FBNjFMA%3D=0> Probably is what you look for. But if you want more tight constraints, like when receiving a 180 after a 200ok and not route it out, you have to make the logic in configuration file by combining modules such as dialog or htable (as already suggested). Cheers, Daniel On 08.04.20 16:04, Luis Rojas G. wrote: Hi, Henning, No need to be ironic. As I mentioned on my first post, I tried stateful proxy and I observed the same behavior. /"I tried using stateful proxy and I obtained the same result."/ The asynchronous sleep seems promising. I will look into it. Thanks, Luis On 4/8/20 9:30 AM, Henning Westerholt wrote: Hi Luis, I see. Well, you want to use Kamailio as a stateless proxy, on the other hand it should do things that are inherently stateful. As mentioned, have a look to the dialog module to track the state of dialogs that you process. This will not work in a stateless mode, though. You can also use the htable module to just store some data about the processed messages in a shared memory table and use this to enforce your ordering. There is also the option to do an asynchronous sleep (with the async) module on the message that you want to delay but still processing other messages during it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481973065=ISKj4Fc0FlBemyJhLFeDaXPQjpOrjIceeXURx2OccqU%3D=0> Kamailio services – https://gilawa.com <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060=vsVGfGjX4ZgDN%2FyaxzSCmc5BHNa%2Buu0Y%2FFQLbW7ETOc%3D=0> *From:* Luis Rojas G. *Sent:* Wednesday, April 8, 2020 3:00 PM *To:* Henning Westerholt ; Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER Hello, Henning, I am worried about this scenario, because it's a symptom of what may happen in other cases. For instance, I've seen that this operator usually sends re-invites immediate after sending ACK. This may create race conditions like 3.1.5 of RFC5407 https://tools.ietf.org/html/rfc5407#page-22 <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060=FekMqBnzvOj4%2FVFnS9x0X5KdcA0Ov1gcb975iEzfWZE%3D=0> I'd understand that one happens because of packet loss, as it's in UDP's nature, but in this case it would be
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hi, Henning, No need to be ironic. As I mentioned on my first post, I tried stateful proxy and I observed the same behavior. /"I tried using stateful proxy and I obtained the same result."/ The asynchronous sleep seems promising. I will look into it. Thanks, Luis On 4/8/20 9:30 AM, Henning Westerholt wrote: Hi Luis, I see. Well, you want to use Kamailio as a stateless proxy, on the other hand it should do things that are inherently stateful. As mentioned, have a look to the dialog module to track the state of dialogs that you process. This will not work in a stateless mode, though. You can also use the htable module to just store some data about the processed messages in a shared memory table and use this to enforce your ordering. There is also the option to do an asynchronous sleep (with the async) module on the message that you want to delay but still processing other messages during it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F=02%7C01%7C%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648=Rlxmq4vieb20HKUi4se4MfGJSuETpO%2Bd8uK0KzBTWO0%3D=0> Kamailio services – https://gilawa.com <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F=02%7C01%7C%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648=nAvHd08RTXoEAFfpOuoGQJnoRmOtzQ0RSfS2RYwIyQs%3D=0> *From:* Luis Rojas G. *Sent:* Wednesday, April 8, 2020 3:00 PM *To:* Henning Westerholt ; Kamailio (SER) - Users Mailing List *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER Hello, Henning, I am worried about this scenario, because it's a symptom of what may happen in other cases. For instance, I've seen that this operator usually sends re-invites immediate after sending ACK. This may create race conditions like 3.1.5 of RFC5407 https://tools.ietf.org/html/rfc5407#page-22 <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22=02%7C01%7C%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311856645=fwVfaNyZ7hCyBvYz%2BdlWBMf52MuFdhBxHpnYysjA0FA%3D=0> I'd understand that one happens because of packet loss, as it's in UDP's nature, but in this case it would be artificially created by Kamailio. if there was no problem at network level (packet loss, packets following different path on the network and arriving out of order), why Kamailio creates it? I'd expect that the shared memory is used precisely for this. If an instance of kamailio receives a 200 OK, it could check on the shm and say "hey, another instance is processing a 180 for this call. Let's wait for it to finish" (*). I know there could still be a problem, the instance processing the 180 undergoes a context switch just after it receives the message, but before writing to shm, but it would greatly reduce the chance. In our applications we use a SIP stack that always sends messages to the application in the same order it receives them, even though is multi-threaded and messages from the network are received by different threads. So, they really syncronize between them. Why Kamailio instances don't? I am evaluating kamailio to use it as a dispatcher to balance load against our several Application Servers, to present to the operator just a couple of entrance points to our platform (they don't want to establish connections to each one of our servers). This operator is very difficult to deal with. I am sure they will complain something like "why are you sending messages out of order? Fix that". The operator will be able to see traces and check that messages entered the Kamailio nodes in order and left out of order. They will not accept it. (*) Not really "wait", as it would introduce a delay in processing all messages. it should be like putting it on a queue, continue processing other messages, and go back to the queue later. Well, thanks for your answer. Luis On 4/8/20 3:01 AM, Henning Westerholt wrote: Hello Luis, as the 1xx responses are usually send unreliable (unless you use PRACK), you should not make any assumption on the order or even the arrival of this messages. It can also happens on a network level, if send by UDP. Can you elaborate why you think this re-ordering is a problem for you? One idea to enforce some ordering would be to use the dialog module in combination with reply routes and the textops(x) module. About the shared memory question – Kamailio implement its own memory manager (private memory and shared memory pool). Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ <https://nam02.safelinks.protection.ou
Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Hello, Henning, I am worried about this scenario, because it's a symptom of what may happen in other cases. For instance, I've seen that this operator usually sends re-invites immediate after sending ACK. This may create race conditions like 3.1.5 of RFC5407 https://tools.ietf.org/html/rfc5407#page-22 I'd understand that one happens because of packet loss, as it's in UDP's nature, but in this case it would be artificially created by Kamailio. if there was no problem at network level (packet loss, packets following different path on the network and arriving out of order), why Kamailio creates it? I'd expect that the shared memory is used precisely for this. If an instance of kamailio receives a 200 OK, it could check on the shm and say "hey, another instance is processing a 180 for this call. Let's wait for it to finish" (*). I know there could still be a problem, the instance processing the 180 undergoes a context switch just after it receives the message, but before writing to shm, but it would greatly reduce the chance. In our applications we use a SIP stack that always sends messages to the application in the same order it receives them, even though is multi-threaded and messages from the network are received by different threads. So, they really syncronize between them. Why Kamailio instances don't? I am evaluating kamailio to use it as a dispatcher to balance load against our several Application Servers, to present to the operator just a couple of entrance points to our platform (they don't want to establish connections to each one of our servers). This operator is very difficult to deal with. I am sure they will complain something like "why are you sending messages out of order? Fix that". The operator will be able to see traces and check that messages entered the Kamailio nodes in order and left out of order. They will not accept it. (*) Not really "wait", as it would introduce a delay in processing all messages. it should be like putting it on a queue, continue processing other messages, and go back to the queue later. Well, thanks for your answer. Luis On 4/8/20 3:01 AM, Henning Westerholt wrote: Hello Luis, as the 1xx responses are usually send unreliable (unless you use PRACK), you should not make any assumption on the order or even the arrival of this messages. It can also happens on a network level, if send by UDP. Can you elaborate why you think this re-ordering is a problem for you? One idea to enforce some ordering would be to use the dialog module in combination with reply routes and the textops(x) module. About the shared memory question – Kamailio implement its own memory manager (private memory and shared memory pool). Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F=02%7C01%7C%7C9909a729fd8a426f81aa08d7db8aab0a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C1%7C637219260993836600=ZLmPqvbWKbsXY49s870sElN2I0uIn0DtDQSqJOoxr6I%3D=0> Kamailio services – https://gilawa.com <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F=02%7C01%7C%7C9909a729fd8a426f81aa08d7db8aab0a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C1%7C637219260993836600=Hdgzfwgu80wiwJBOjh9N70hvXSvWjt8abuKFjVRsavo%3D=0> *From:* sr-users *On Behalf Of *Luis Rojas G. *Sent:* Tuesday, April 7, 2020 10:43 PM *To:* sr-users@lists.kamailio.org *Subject:* [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER Good day, I am testing the dispatcher module, using Kamailio as stateless proxy. I have a pool of UAC (scripts in SIPP) and a pool of UAS (also scripts in SIPP) for the destinations. Kamailio version is kamailio-5.3.3-4.1.x86_64. Problem I have is, if UAS responds 180 and 200 OK to Invite immediately, sometimes they are propagated out of order. 200 OK before 180, like this : UAS is 172.30.4.195:5061. UAC is 172.30.4.195:5080. Kamailio is 192.168.253.4:5070 Difference between 180 and 200 is just about 50 microseconds. My guess is that both messages are received by different instances of Kamailio, and then because of context switches, even though the 180 is received before, that process ends after the processing of 200. However, I had the idea that in order to avoid these problems the kamailio processes synchronized with each other using a shared memory. I tried using stateful proxy and I obtained the same result. By the way, anyone has any idea about how Kamailio's share memory is implemented? It clearly does not use the typical system calls shmget(), shmat(), because they are not shown by ipcs command. Before posting here I googled, but I couldn't find anything related to this. I can't believe I am the only one who ever had this problem, so I guess I am doing something wrong... Please, any help. I'm really stuck on this. Thanks. -- -- Luis Rojas
[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Good day, I am testing the dispatcher module, using Kamailio as stateless proxy. I have a pool of UAC (scripts in SIPP) and a pool of UAS (also scripts in SIPP) for the destinations. Kamailio version is kamailio-5.3.3-4.1.x86_64. Problem I have is, if UAS responds 180 and 200 OK to Invite immediately, sometimes they are propagated out of order. 200 OK before 180, like this : UAS is 172.30.4.195:5061. UAC is 172.30.4.195:5080. Kamailio is 192.168.253.4:5070 Difference between 180 and 200 is just about 50 microseconds. My guess is that both messages are received by different instances of Kamailio, and then because of context switches, even though the 180 is received before, that process ends after the processing of 200. However, I had the idea that in order to avoid these problems the kamailio processes synchronized with each other using a shared memory. I tried using stateful proxy and I obtained the same result. By the way, anyone has any idea about how Kamailio's share memory is implemented? It clearly does not use the typical system calls shmget(), shmat(), because they are not shown by ipcs command. Before posting here I googled, but I couldn't find anything related to this. I can't believe I am the only one who ever had this problem, so I guess I am doing something wrong... Please, any help. I'm really stuck on this. Thanks. -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com -- Luis Rojas Software Architect Sixbell Los Leones 1200 Providencia Santiago, Chile Phone: (+56-2) 22001288 mailto:luis.ro...@sixbell.com http://www.sixbell.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
