[SR-Users] more on asynchronous processing in config

[Daniel-Constantin Mierla]

Hello,

On 7/5/11 2:03 PM, Alex Balashov wrote:
> Daniel,
>
> On 07/05/2011 06:04 AM, Daniel-Constantin Mierla wrote:
>
>> Hello,
>>
>> over the weekend I exported to config file the two main functions from
>> tm that allow to suspend the execution of a SIP request and resume it in
>> another place. They are exported through tmx module:
>> - t_suspend() - will suspend the execution of current sip request and
>> then you can do something else (like processing the next request)
>> - t_continue(tindex, tlabel, rtname) - continue the processing of SIP
>> request suspended in the transaction identified by tupple
>> (tindex,tlable) with the actions in route[rtname]
>>
>> After t_suspend() you can get the transaction identifier (tindex,
>> tlable) via pseudo-variables $T(id_index) and $T(id_label), e.g.:
>>
>> if(t_suspend()) {
>> xlog("sip request suspended in transaction 
>> [$T(id_index)/$T(id_label)]\n");
>> exit;
>> }
>
> When transactions are continued, where do they get continued?  Is it 
> in one consuming thread?  A pool of them specially allocated for this 
> purpose?  A random SIP worker thread?
the transaction processing is continued when you execute 
t_continue(...). If t_continue() is missing for a request, then the 
transaction will time out. The processing after t_continue() is done in 
the process that executes t_continue(), can be different from case to case.

if you use async module functions, then it has a special pool of 
processes to handle the t_continue(). If you pass the transaction 
index/label via mqueue to a rtimer process and do there t_continue, then 
the rtimer process will do that.

If you send a new request (e.g., like with uac_req_send() ) and do 
t_continue() when a reply to that request comes, then you have the sip 
worker that read the reply doing the processing.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda