t_uac_dlg returns final response to the initiated request. I don't know if it
really waits for the response or uses some kind of async callback.
On Friday 01 October 2010, Alex Balashov wrote:
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.