[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

[Luis Rojas G.]

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> [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.rojas at sixbell.com
http://www.sixbell.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200414/a0519c3d/attachment.html>