27 Jun
2011
27 Jun
'11
8:31 a.m.
Hello,
a new module is now in GIT master branch, named async.
Its purpose is to provide asynchronous SIP request processing using
t_suspend()/t_continue() mechanism from tm module. While the tm module
had it for quite some time, it was not available for usage in
configuration file.
There are two functions implemented by now:
- async_route(routename, interval) - execute asynchronously a route
block after a time interval
- aync_sleep(interval) - sleep asynchronously for a time interval and
then resume SIP request processing
See the readme for more details:
http://kamailio.org/docs/modules/devel/modules/async.html
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
27 Jun
27 Jun
9:47 a.m.
New subject: new module: async - asynchronous SIP request processing in cfg
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/
3:10 p.m.
New subject: new module: async - asynchronous SIP request processing in cfg
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
2:11 p.m.
New subject: [sr-dev] new module: async - asynchronous SIP request processing in cfg
27 jun 2011 kl. 10.31 skrev Daniel-Constantin Mierla:
Hello,
a new module is now in GIT master branch, named async.
Its purpose is to provide asynchronous SIP request processing using
t_suspend()/t_continue() mechanism from tm module. While the tm module had it for quite
some time, it was not available for usage in configuration file.
There are two functions implemented by now:
- async_route(routename, interval) - execute asynchronously a route block after a time
interval
- aync_sleep(interval) - sleep asynchronously for a time interval and then resume SIP
request processing
See the readme for more details:
http://kamailio.org/docs/modules/devel/modules/async.html
Seems kind of sexy.
Do you have a good example of usage?
Greetings from Madrid
/O
5:09 p.m.
New subject: [sr-dev] new module: async - asynchronous SIP request processing in cfg
On Jun 27, 2011, at 4:11 PM, Olle E. Johansson <oej(a)edvina.net> wrote:
Delayed forwarding of requests or delayed
replying - like 100 trying, 180 ringing immediately when invite comes in, then
async_route() to reply 408 timeout after 20 sec when you run out of gw capacity :-).
All without blocking main sip workers.
For SIP MESSAGE to SMS you can use the mechanism just to switch to other pool of workers
in case SMS gatewaying is blocking - although this can be achieved as well with mqueue and
rtimer modules if you don't need the full sip request in special workers.
Just some thoughts ...
Hopefully the module will help others to contribute more functions that will work
asynchronously. My todo has some more ideas here as well, just that is as long as Madrid -
Berlin, so may not get in that soon :-)
Enjoy the cold Saharian daylight temperatures,
Daniel
27 jun 2011 kl. 10.31 skrev Daniel-Constantin Mierla:
Hello,
a new module is now in GIT master branch, named async.
Its purpose is to provide asynchronous SIP request processing using
t_suspend()/t_continue() mechanism from tm module. While the tm module had it for quite
some time, it was not available for usage in configuration file.
There are two functions implemented by now:
- async_route(routename, interval) - execute asynchronously a route block after a time
interval
- aync_sleep(interval) - sleep asynchronously for a time interval and then resume SIP
request processing
See the readme for more details:
http://kamailio.org/docs/modules/devel/modules/async.html
Seems kind of sexy.
Do you have a good example of usage?
4705
days inactive
4705
days old
4 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Daniel-Constantine Mierla
-
Olle E. Johansson