[SR-Users] Can this be done with xhttp module (3.1 devel)?
Sergey Okhapkin
sos at sokhapkin.dyndns.org
Sat Oct 2 01:24:55 CEST 2010
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.
>
More information about the sr-users
mailing list