[SR-Users] new module: async - asynchronous SIP request processing in cfg

[Alex Balashov]

Interesting.  A few thoughts:

1. What sort of use cases are envisioned here?  Most SIP transactions 
are very delay-sensitive operate on a sub-1s retransmit timer 
resolution, e.g. Timer T1.

For INVITE transactions where retransmissions can be held down by 100 
Trying, I am still brought to wonder, what is the end goal, given that 
in practice, pretty much all blocking calls invoked in processing an 
INVITE request return info that is essential to further processing/routing?

I have a feeling that perhaps this is more useful with SIP features that 
are not "call-related", but I am not sufficiently imaginative to come up 
with a concrete example.

Oddly enough, one constituency that I do think would have an interest in 
this feature--though a dubiously desirable one--is people running large 
amounts of low-ASR, low-ACD dialer traffic.  We get asked a lot about 
whether there are ways to "slow down" outbound BYEs (from the equipment 
as they move toward a termination provider) in order to circumvent 
financial penalties assessed when a percentage threshold of 
short-duration calls (e.g. under 6 seconds) is exceeded.

Despite the obvious technical problems that can potentially be incurred 
here (retransmissions, fast RTP timeout, etc.), doubtless this is going 
to excite garbage traffic runners.

I am not sure that's a good thing, though.  The PSTN is like the sewer 
system;  you get out of it what you put into it.  And what these people 
put into it in fact belongs in a sewer system.  :-)

2. It would be nice if the interval granularity could be expressed in 
milliseconds, since that would allow potential applications that fly 
under the radar of most SIP timers.

3. It seems like in some ways this would be most useful if blocking 
operations like database calls could be "redirected" into a separate 
worker thread pool, and then request processing would resume as soon as 
they complete.  Because all that happens in separate threads, it frees 
up core SIP worker threads to absorb more new requests.

So, perhaps something like:

     route {
        ...
        async_wrapper(allow_trusted(), MY_ROUTE);
     }

     route[MY_ROUTE] {
        if(!$someretval) {
          sl_send_reply("403", "Forbidden");
          exit;
        }

        t_relay(); # etc.
     }

-- 
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/