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@sixbell.com
http://www.sixbell.com