[OpenSIPS-Users] calling t_uac_cancel from opensips script
Jayesh Nambiar
jayesh1017 at gmail.com
Wed Sep 10 12:15:34 CEST 2014
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 <jayesh1017 at gmail.com>
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 <jayesh1017 at gmail.com>
> 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' '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
>> <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: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/20140910/a4f4cc74/attachment-0001.htm>
More information about the Users
mailing list