1 Oct
2010
1 Oct
'10
11:56 a.m.
I need to get http request with xhttp module, process request parameters,
build SIP request (based on received http parameters), receive SIP reply and
send http response back based on SIP reply. HTTP part is simple, but how to
send SIP request from event_route[xhttp:request] and get SIP reply?
uac_req_send() function doesn't wait for SIP reply, t_uac_dlg MI command does
everything needed but is not accessible from config script. Any other
ideas/suggestions?
1 Oct
1 Oct
5:50 p.m.
Sergey,
There is no way to get Kamailio to "wait" for a reply. You would have
to come up with some sort of asynchronous means of providing the reply
result to the waiting HTTP client that is prompted by a reply on the
Kamailio side also asynchronously.
-- Alex
On 10/01/2010 11:56 AM, Sergey Okhapkin wrote:
I need to get http request with xhttp module, process
request parameters,
build SIP request (based on received http parameters), receive SIP reply and
send http response back based on SIP reply. HTTP part is simple, but how to
send SIP request from event_route[xhttp:request] and get SIP reply?
uac_req_send() function doesn't wait for SIP reply, t_uac_dlg MI command does
everything needed but is not accessible from config script. Any other
ideas/suggestions?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
6:11 p.m.
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.
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.
On Friday 01 October 2010, Alex Balashov wrote:
Sergey,
There is no way to get Kamailio to "wait" for a reply. You would have
to come up with some sort of asynchronous means of providing the reply
result to the waiting HTTP client that is prompted by a reply on the
Kamailio side also asynchronously.
-- Alex
On 10/01/2010 11:56 AM, Sergey Okhapkin wrote:
I need to get http request with xhttp module,
process request parameters,
build SIP request (based on received http parameters), receive SIP reply
and send http response back based on SIP reply. HTTP part is simple, but
how to send SIP request from event_route[xhttp:request] and get SIP
reply?
uac_req_send() function doesn't wait for SIP reply, t_uac_dlg MI command
does everything needed but is not accessible from config script. Any
other ideas/suggestions?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:06 p.m.
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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
7:24 p.m.
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.
7:29 p.m.
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. :-)
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
7:38 p.m.
Yes, it returns final SIP response back. Checked with kamailio/opensips 1.4,
kamailio 1.5 and 3.1
On Friday 01 October 2010, Alex Balashov wrote:
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. :-)
7:43 p.m.
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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
7:49 p.m.
I never checked with datagram/RPC, I use MI FIFO for that in production
environment.
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.
2 Oct
2 Oct
3:39 a.m.
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:
--
Daniel-Constantin Mierla
http://www.asipto.com
On 10/01/2010 07:38 PM, Sergey Okhapkin wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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.
3:43 a.m.
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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
3:48 a.m.
Hi Alex,
On 10/2/10 9:43 AM, Alex Balashov wrote:
Daniel,
On 10/02/2010 03:39 AM, Daniel-Constantin Mierla wrote:
is the same case like sending to fifo/datagram MI. If worked there for
you, should work now.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
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. 
4:05 a.m.
On Oct 02, 2010 at 03:43, Alex Balashov <abalashov(a)evaristesys.com> wrote:
Daniel,
On 10/02/2010 03:39 AM, Daniel-Constantin Mierla wrote:
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).
Anyway it cannot be done from the script.
Andrei
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.
4:08 a.m.
On 10/2/10 10:05 AM, Andrei Pelinescu-Onciul wrote:
On Oct 02, 2010 at 03:43, Alex
Balashov<abalashov(a)evaristesys.com> wrote:
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
Daniel,
On 10/02/2010 03:39 AM, Daniel-Constantin Mierla wrote:
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). 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. Anyway it cannot be done from the script.
--
Daniel-Constantin Mierla
http://www.asipto.com
3:55 a.m.
On Oct 02, 2010 at 09:39, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
On 10/2/10 1:49 AM, Sergey Okhapkin wrote:
The same can be achieved with RPCs. Load the xmlrpc module and use
tm.t_uac_wait.
$ sercmd help tm.t_uac_wait
starts a tm uac and waits for the final reply, using a list of string
parameters: method, ruri, dst_uri send_sock, headers (CRLF separated)
and body (optional)
Examples on how to send xmlrpc commands in perl or python are in
modules/xmlrpc/examples.
Andrei
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 
6:53 a.m.
2010/10/2 Sergey Okhapkin <sos(a)sokhapkin.dyndns.org>rg>:
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? :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5251
days inactive
5252
days old
15 comments
5 participants
participants (5)
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Sergey Okhapkin