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