Hi Alex,
On 6/27/11 11:47 AM, Alex Balashov wrote:
Interesting. A few thoughts:
- 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. :-)
- 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.
- 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. }