I am not sure I understand the difference between the two installs.
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 09/10/2014 01:15 PM, Jayesh Nambiar wrote:
Hello Razvan,
An update to the above problem:
I re-installed opensips without prefix based installation and the
exec_avp for t_uac_cancel worked fine as expected. No permission
errors anywhere !!
I used to install opensips directly using the following:
make prefix=/usr/local/myOpensips include_modules="db_mysql
cachedb_redis json rest_client"
make prefix=/usr/local/myOpensips include_modules="db_mysql
cachedb_redis json rest_client" install.
Is the above method no longer supported or somethig??
Thanks,
--- Jayesh
On Wed, Sep 10, 2014 at 1:55 PM, Jayesh Nambiar <[email protected]
<mailto:[email protected]>> wrote:
Hello,
Just an update, when I ran exec_msg function with modparam("exec",
"async", 0), the behaviour was same as exec_avp function.
Basically, opensips logs stay at forked_pid and nothing else works
after that. No SIP request is processed.
--- Jayesh
On Tue, Sep 9, 2014 at 8:41 PM, Jayesh Nambiar
<[email protected] <mailto:[email protected]>> wrote:
When I use exec_avp opensips hangs. There's no core generated,
and following are the logs immediately after the command is
executed:
Sep 9 10:17:48 v38
/usr/local/myOpensips/sbin/opensips[24843]:
DBG:exec:w_exec_avp: executing
[/usr/local/myOpensips/etc/opensips/uac_cancel.sh
'.56sqM.YAwbUId0odDVrte3d6PZqa.de
<http://56sqM.YAwbUId0odDVrte3d6PZqa.de>' '14654']
Sep 9 10:17:48 v38
/usr/local/myOpensips/sbin/opensips[24843]: DBG:exec:exec_avp:
Forked pid 24879
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:mi_fifo:mi_parse_tree: adding node <> ; val
<.56sqM.YAwbUId0odDVrte3d6PZqa.de
<http://56sqM.YAwbUId0odDVrte3d6PZqa.de>>
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:mi_fifo:mi_parse_tree: adding node <> ; val <14654>
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:mi_fifo:mi_parse_node: end of input tree
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:t_lookup_callid: created comparable call_id header
field: >Call-ID: .56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012
<http://56sqM.YAwbUId0odDVrte3d6PZqa.de#015%23012><
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:t_lookup_callid: created comparable cseq header field:
>CSeq: 14654 INVITE<
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:t_lookup_callid: <Call-ID:
.56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012
<http://56sqM.YAwbUId0odDVrte3d6PZqa.de#015%23012>> <CSeq: 14654>
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:t_lookup_callid: we have a match: callid=>>Call-ID:
.56sqM.YAwbUId0odDVrte3d6PZqa.de#015#012
<http://56sqM.YAwbUId0odDVrte3d6PZqa.de#015%23012><<
cseq=>>CSeq: 14654<<
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:t_lookup_callid: REF_UNSAFE:[0x7f449a0cbb00] after is 1
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:t_lookup_callid: transaction found.
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:mi_tm_cancel: cancelling transaction 0x7f449a0cbb00
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:build_local: using FROM=<From: "Jayesh Nambiar"
<sip:[email protected]
<mailto:sip%[email protected]>>;tag=NPD-XIL90Z6yNzrktn-IZWpOgnzcJ6EZ#015#012>,
TO=<To: <sip:[email protected]
<mailto:sip%[email protected]>>#015#012>, CSEQ_N=<CSeq:
14654>
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:cancel_branch: sending cancel...
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]: DBG:tm:set_timer:
relative timeout is 500000
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:insert_timer_unsafe: [4]: 0x7f449a0cbde8 (173300000)
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:insert_timer_unsafe: [0]: 0x7f449a0cbe18 (212)
Sep 9 10:18:00 v38
/usr/local/myOpensips/sbin/opensips[24835]:
DBG:tm:mi_tm_cancel: UNREF_UNSAFE: [0x7f449a0cbb00] after is 0
Also when I use exec_msg, the opensips doesn't hang and looks
like it works as expected. Although while using exec_msg
function, it adds an additional parameter when executing the
command at the end in a parentheses. For eg: my function is:
exec_msg("/usr/local/myOpensips/sbin/opensipsctl fifo
t_uac_cancel $avp(caller_cid) $avp(caller_cseq)");
In the debug it shows command executed as:
/usr/local/myOpensips/etc/opensips/uac_cancel.sh
btf4RC2Z8tBlpG6eAG-hZK4cZxENCEud 8222 (23430)
I'm not sure what (23430) is in the above command because of
which most likely the t_uac_cancel fails. Because If I run
this command directly it gives me syntax error:
-bash: syntax error near unexpected token `('
I dont even have an option to single quote that parameter as
it comes automatically when the function is executed.
--- Jayesh
On Tue, Sep 9, 2014 at 8:22 PM, Răzvan Crainea
<[email protected] <mailto:[email protected]>> wrote:
Hi, Jayesh!
Do you see any cores generated? Is there anything logged
by your MI command?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com <http://www.opensips-solutions.com>
On 09/09/2014 05:27 PM, Jayesh Nambiar wrote:
Hello Razvan,
I extracted the source opensips-1.11.2-4c08b62_src.tar.gz
created on Sept 7th and tried again. This time, as soon
as the exec_avp command is fired, the opensips stops
processing anything after that. The service doesn't even
stop when tried to stop cleanly. It just hangs. After a
minute or so, it shuts down with the following in the logs:
Sep 9 10:23:17 v38
/usr/local/myOpensips/sbin/opensips[24832]:
DBG:core:pool_remove: connection still kept in the pool
Sep 9 10:23:17 v38
/usr/local/myOpensips/sbin/opensips[24832]:
DBG:core:pool_remove: removing connection from the pool
Sep 9 10:23:17 v38
/usr/local/myOpensips/sbin/opensips[24832]:
DBG:core:pool_remove: removing connection from the pool
Sep 9 10:24:17 v38
/usr/local/myOpensips/sbin/opensips[24832]:
CRITICAL:core:sig_alarm_abort: BUG - shutdown timeout
triggered, dying...
Sep 9 10:24:17 v38 kernel: [24880095.291228] device eth0
left promiscuous mode
Should I try with an older stable version instead?? I
think there is something wrong with the way this is
going. Let me know if I can be of any help to
troubleshoot this further.
Thanks,
--- Jayesh
On Tue, Sep 9, 2014 at 7:19 PM, Răzvan Crainea
<[email protected] <mailto:[email protected]>> wrote:
Can you please update your sources? Bogdan made a
fixon 24th of August that might be related to this.
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com <http://www.opensips-solutions.com>
On 09/09/2014 04:42 PM, Jayesh Nambiar wrote:
Hello Razvan,
I am running 1.11.2 extracted from the following
source file:
opensips-1.11.2-4fda9a1_src.tar.gz
A little more background on the problem:
The caller is connected on TCP and relayed over UDP.
The transaction that I am trying to cancel is an UDP
transaction. I dont believe this should have any
concern with the problem I'm facing but still
mentioning. Basically I want to cancel this
transaction, get the caller into the failure route
and relay it to a different destination !!
Thanks for the prompt replies.
--- Jayesh
On Tue, Sep 9, 2014 at 7:07 PM, Răzvan Crainea
<[email protected] <mailto:[email protected]>>
wrote:
Hi, Jayesh!
No, it should not be present. It is created by
opensipsctl when a command is issued. What
version of OpenSIPS are you running?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
<http://www.opensips-solutions.com>
On 09/09/2014 04:30 PM, Jayesh Nambiar wrote:
Hi,
Just as an update, I only see opensips_fifo in
the /tmp/ directory. Is the opensips_receiver
supposed to be present??
--- Jayesh
On Tue, Sep 9, 2014 at 6:49 PM, Jayesh Nambiar
<[email protected]
<mailto:[email protected]>> wrote:
Yes, running opensips with user root. Still
the same problem.
--- Jayesh
On Tue, Sep 9, 2014 at 6:22 PM, Răzvan
Crainea <[email protected]
<mailto:[email protected]>> wrote:
Hi, Jayesh!
I think there is a permissions issue
here. What is the user you are running
opensips with? Is it the same as the
one you are trying to execute the shell
script?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
<http://www.opensips-solutions.com>
On 09/09/2014 03:44 PM, Jayesh Nambiar
wrote:
Hello,
I try to cancel a running transaction
in opensips based on certain
conditions. When I try this from the
script:
exec_avp("/usr/local/myOpensips/sbin/opensipsctl
fifo t_uac_cancel $avp(caller_cid)
$avp(caller_cseq)", "$avp(result)");
The callid and cseq is properly
substituted in the appropriate AVPs.
I get, ** ERROR: error opening read
fifo /tmp/opensips_receiver_24405 in
the resulting AVP. Whereas when I run
this command directly from my shell it
runs fine and cancels the transaction
as expected.
Tried to google around the problem and
couldn't find much. I read about some
selinux thing that might block
opensips from executing the MI
command, but I'm pretty sure selinux
is disabled on my machine. Where else
do I look for a fix such that my
script is able to execute this !!
Thanks in advance for any pointers.
--- Jayesh
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
