[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