27 Jun
2011
27 Jun
'11
11:47 a.m.
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.
}
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/