[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