Sergey,
On 10/01/2010 06:11 PM, Sergey Okhapkin wrote:
There is a way, t_uac_dlg MI does that. I wonder why something similar is not available from cfg script. You can issue http request and wait for response from cfg, it would be nice to have t_uac_dlg() script function too.
You can send a request from script, sure. That's what uac_req_send() does; t_uac_dlg is just its MI equivalent, allowing that action to be externally stimulated. Unless I am missing something that is not in the documentation, t_uac_dlg does not wait for a reply either. Or does it? I have not used it.
I have no problem to run apache and invoke t_uac_dlg from CGI, but I'd prefer to avoid cgi overhead and implement kamailio-only based solution.
Understandably. However, generally speaking, the architecture of Kamailio, and the entire *SER technology stack, is patterned after a strictly (external) event-driven process. This means that route script is invoked only when messages are received; some state information can be retained across sets of related messages (transactions, dialogs, etc.), but in principle, Kamailio does not sit around and block, waiting for replies to come back.
Given the present architecture, waiting on a response would be additionally problematic because Kamailio/sip-router does not use threads per se. It spawns a set of forked processes which act as worker threads that are specialised into different roles, but these are finite in nature. It would be catastrophic to throughput to have one of these pause and block, waiting on a reply before returning from an invocation of route script for a given message.