[OpenSIPS-Users] calling t_uac_cancel from opensips script
Jayesh Nambiar
jayesh1017 at gmail.com
Tue Sep 9 17:11:48 CEST 2014
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' '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>
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<
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>
<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<< 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:1003040 at 198.24.63.38>;tag=NPD-XIL90Z6yNzrktn-IZWpOgnzcJ6EZ#015#012>,
TO=<To: <sip:1003030 at 198.24.63.38>#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 <razvan at opensips.org> wrote:
> Hi, Jayesh!
>
> Do you see any cores generated? Is there anything logged by your MI
> command?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.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 <razvan at opensips.org>
> wrote:
>
>> Can you please update your sources? Bogdan made a fix on 24th of August that
>> might be related to this.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.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 <razvan at opensips.org>
>> 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 Solutionswww.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 <jayesh1017 at gmail.com>
>>> wrote:
>>>
>>>> Yes, running opensips with user root. Still the same problem.
>>>>
>>>> --- Jayesh
>>>>
>>>> On Tue, Sep 9, 2014 at 6:22 PM, Răzvan Crainea <razvan at opensips.org>
>>>> 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 Solutionswww.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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140909/f6227f06/attachment-0001.htm>
More information about the Users
mailing list