Hi Alex,

On 6/27/11 11:47 AM, Alex Balashov wrote:

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.

the first purpose what to show how to write C extensions using the asynchronous SIP request processing mechanism, based on mailing list questions lately.

In the past there were some discussions about asynchronous sleep and this was used as a sample implementation, by executiing either next actions in config (with some limitations listed in readme) or a specific route block when processing is resumed.

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.

There are also use cases for INVITEs as well, by conding some extension in C. Matthew Williams showed a case, when it is needed to connect to another server before allowing the call.

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.

Sending 100 reply should stop retransmission for any kind of SIP request.

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.

The easiest so far was to use a generic timer api which is second granularity, but further improvements are planned.

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.

This is kind of next improvement, something like using an internal message queue to pass transaction identifiers (returned by t_suspend()) to other processes that will resume the processing immediately by executing further a specific route block. I am not looking to create a generic async wrapper right now to cfg functions, that will require some analysis to see the feasibility (i.e., passing a function name with parameters as parameter to another cfg function might give some troubles with our internal fixup system). But directing the processing of a route block to another pool of workers is more or less the same (if you have just that function executed in the route block).

Cheers, Daniel

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.
}

On Jun 27, 2011, at 4:11 PM, Olle E. Johansson oej@edvina.net wrote:

27 jun 2011 kl. 10.31 skrev Daniel-Constantin Mierla:

...

Hello,

a new module is now in GIT master branch, named async.

Its purpose is to provide asynchronous SIP request processing using t_suspend()/t_continue() mechanism from tm module. While the tm module had it for quite some time, it was not available for usage in configuration file.

There are two functions implemented by now:

• async_route(routename, interval) - execute asynchronously a route block after a time interval
• aync_sleep(interval) - sleep asynchronously for a time interval and then resume SIP request processing

See the readme for more details: http://kamailio.org/docs/modules/devel/modules/async.html

Seems kind of sexy.

Do you have a good example of usage?

Delayed forwarding of requests or delayed replying - like 100 trying, 180 ringing immediately when invite comes in, then async_route() to reply 408 timeout after 20 sec when you run out of gw capacity :-).

All without blocking main sip workers.

For SIP MESSAGE to SMS you can use the mechanism just to switch to other pool of workers in case SMS gatewaying is blocking - although this can be achieved as well with mqueue and rtimer modules if you don't need the full sip request in special workers.

Just some thoughts ...

Hopefully the module will help others to contribute more functions that will work asynchronously. My todo has some more ideas here as well, just that is as long as Madrid - Berlin, so may not get in that soon :-)

Enjoy the cold Saharian daylight temperatures, Daniel