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.

On 10/01/2010 07:24 PM, Sergey Okhapkin wrote:

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.

Really? Very interesting. The documentation does not say that it does that at all, although that is not uncommon with this product. :-)

On 10/01/2010 07:38 PM, Sergey Okhapkin wrote:

Yes, it returns final SIP response back. Checked with kamailio/opensips 1.4, kamailio 1.5 and 3.1

Does it do this with the MI FIFO interface too, or just datagram/RPC?

If it does it only via datagram or RPC, this is quite logical because the client stays connected and keeps listening for events.

Hello,

On 10/2/10 1:49 AM, Sergey Okhapkin wrote:

I never checked with datagram/RPC, I use MI FIFO for that in production environment.

you can use t_uac_dlg MI command via XMLRPC. That is done via http.

This command is a bit special, doing a wait until the reply comes, blocking working process, so use it carefully.

Just load mi_rpc module and then you can run any mi command via xmlrpc. http://kamailio.org/docs/modules/devel/modules/mi_rpc.html

Cheers, Daniel

On Friday 01 October 2010, Alex Balashov wrote:

...

On 10/01/2010 07:38 PM, Sergey Okhapkin wrote:

...

Yes, it returns final SIP response back. Checked with kamailio/opensips 1.4, kamailio 1.5 and 3.1

Does it do this with the MI FIFO interface too, or just datagram/RPC?

If it does it only via datagram or RPC, this is quite logical because the client stays connected and keeps listening for events.

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Alex,

On 10/2/10 9:43 AM, Alex Balashov wrote:

Daniel,

On 10/02/2010 03:39 AM, Daniel-Constantin Mierla wrote:

...

you can use t_uac_dlg MI command via XMLRPC. That is done via http.

This command is a bit special, doing a wait until the reply comes, blocking working process, so use it carefully.

Doesn't this aspect of the command make it a bit impractical for any non-trivial call volume? In a normal setup there are only < 10 SIP worker processes and replies take up to a few hundred milliseconds to come back.

is the same case like sending to fifo/datagram MI. If worked there for you, should work now.

Cheers, Daniel

On 10/2/10 10:05 AM, Andrei Pelinescu-Onciul wrote:

On Oct 02, 2010 at 03:43, Alex Balashovabalashov@evaristesys.com wrote:

...

Daniel,

On 10/02/2010 03:39 AM, Daniel-Constantin Mierla wrote:

...

you can use t_uac_dlg MI command via XMLRPC. That is done via http.

This command is a bit special, doing a wait until the reply comes, blocking working process, so use it carefully.

Doesn't this aspect of the command make it a bit impractical for any non-trivial call volume? In a normal setup there are only< 10 SIP worker processes and replies take up to a few hundred milliseconds to come back.

I'm not sure about the MI command (I don't think it blocks a worker since it should use internally an async. callback), but tm.t_uac_wait does not block any process. It uses t_uac() and a callback on the transaction completion (the xmlrpc reply is send from the callback).

Good to know. I will double check for MI, but that was my believing so far.

I remember you implemented the pure RPC alternative -- earlier this morning I was checking mi_rpc for a 'mi async' command instead of looking at tm -- didn't wake up properly :-)

Thanks, Daniel

Anyway it cannot be done from the script.

2010/10/2 Sergey Okhapkin sos@sokhapkin.dyndns.org:

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.

I suppose it works as follows:

- t_uac_dlg is invoked. - Kamailio MI process receives the MI request and creates an outgoing transaction for sending the desired SIP request. It also creates a callback to be executed when a response is received within this transaction (I expect). - After sending the request the worker process gets free again (important) and can process other requests. - When a response arrives the callback is executed and the MI worker can then send the MI response informing about the response code.

This is not problematic. However what the initiator of this threads look for *is* terrible problematic. Alex already explained it but I'd would like to insist on it:

- An HTTP request arrives to a kamailio worker (let's name it "worker_1"). - worker_1 generates a SIP request. - Now worker_1 MUST wait until the SIP response in order to create the HTTP response.

This is terrible because worker_1 gets blocked until the HTTP response arrives (what about if it never arrives?).

If HTTP requests would create a "transaction" (saved in shared memory) then perhaps this could work but... what do we want kamaialio/sip-router to be? :)