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

Daniel-Constantin Mierla miconda at gmail.com
Mon Jun 27 17:10:34 CEST 2011


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

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda




More information about the sr-users mailing list