I’ am develoing an asterisk plugin with C++. According to the requirements, I should close all AMI connections after terminating the call.
Could you please help me about it? How can I close the current AMI connections ?
Thanks & Best Regards
I’ am develoing an asterisk plugin with C++. According to the requirements, I should close all AMI connections after terminating the call.
Could you please help me about it? How can I close the current AMI connections ?
Thanks & Best Regards
The same way you would close any other TCP connection in the language you are using for your AMI action. You should probably send a Logoff to avoid having warnings logged.
Note there is no correlation between calls and AMI connections, except in your application.
Do you mean “ast_manager_unregister” event by saying that “send a Logoff” ? If so, as far as I can see, this event is called for a specific action. ( ast_manager_unregister(“SIPpeers”); ) But, I want to close all AMI connections, and don’t want to listen these actions anymore. Is there a way of doing this ?
He’s not referring to an event, he’s referring to the actual Logoff action[1] which a client can send before disconnecting. The ast_manager_unregister you are referring to is not an event but an internal C function used to unregister an AMI action from AMI support.
If you are actually writing C code and want the Asterisk server side to disconnect someone and stop accepting connections, I don’t believe we provide a mechanism for that.
[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerAction_Logoff
I am using AMI Hook to be able to listen & catch related events. According to the scenario, I can easily make call recording by getting talking status with AMI Hook. After ending the first call, I can not make a second call record, it stays in just calling state. It sends SIP INVITE message to Astersik server but Asterisk does not respond him. Most probably, some tcp connections or sockets are pending. I am not sure but it maybe the reason of why I can not make the second call. Do you have any idea about the cause of problem or the usage of AMI hook ? The second question I would like to ask is about AMI event listening mechanism in the application layer. I’ve found AMI hook, but can not use it effectively as I stated above. Do you know any other altenative instead of AMI Hook while listening AMI events ?
If you are referring to inside of Asterisk, your options are an AMI hook or writing an AMI client in Asterisk which then connects to itself. An AMI hook itself does not create a TCP connection.
If your AMI hook is causing this problem then it’s likely because of the hook somehow. Have you done any debugging to see what is going on? Reduced what the hook does? Looked at a backtrace to see if something is deadlocked?
I’ve checked asterisk logs, but no error log is written when the problem occured. Is there anything to be checked you would like to suggest ? By the way, I added AMI Hook impl. to be able to put VOX feature into call recording by listening ConfbridgeTalking event with TalkingStatus . After removing AMI hook implementation, I can make call recordings recurrently. How can I check deadlock situations ? Could you please suggest methods if you know ?
The wiki contains a page[1] for getting a backtrace from a running Asterisk. It then needs to be examined to determine if anything is deadlocked. If you are making changes at a C level this is something you need to learn, as well as being able to look at locking and such. If things aren’t done correctly then you’ll get exactly what you are seeing.
[1] https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=5243139
Firstly, thanks for the detailed explanation. But, I couldn’t manage to work applicaiton. There are two goals I would like to achive.
I can make call recording( first one ) recurrently. Here is the dial plan function of it;
exten => _XXXX,1,Set(__VOX=false)
exten => _XXXX,2,NoOp( VOX: ${VOX})
exten => _XXXX,3,Recording(recorderServer1&recorderServer2,in)
exten => _XXXX,4,Answer()
exten => _XXXX,5,Echo()
exten => _XXXX,6,Hangup()
I fail while making the second VOX featured call recording. To be able to put VOX feature, I used AMI hook, caught ConfbridgeTalking event. So, I can detect user talking status. No record is made if user does not talk. I’ve used conference channel for VOX feature, when the user leave conference channel, I stop recording, remove RTSP session. When I try to make the second call, the dial plan funciton is not called anymore. Here is the dialplan function of VOX enabled call recording ;
exten => _XXXX,1,Set(__VOX=true)
exten => _XXXX,2,NoOp( VOX: ${VOX})
exten => _XXXX,3,Recording(recorderServer1&recorderServer2,in)
exten => _XXXX,4,Answer()
exten => _XXXX,5,ConfBridge(4444,)
exten => _XXXX,6,Hangup()
Do you have any idea about why dial plan function is not called for the second time ?
You haven’t provided any dialplan output or further information, so people can only guess.
Sorry, I couldn’t understand… What do you mean by saying dial plan output ?
When a channel is executing dialplan things are output to the console and depending on configuration the /var/log/asterisk/messages file. I’d suggest you learn those basics, as they are extremely useful to debugging and to knowing what is going on.
I know it, I just thought that there is something new. When the second call is made, I’ve checked CLI output and messages, there was no log…So, that’s why I suspect that dialplan function is not called. Do you have any idea about what’s going on ?
No, but we seem to be going around in circles. You should get a backtrace like I previously mentioned to see if something in your own code is causing a deadlock or problem, resulting in handling being stopped in some way.
When I reinstall asterisk after enabling these compiler flags, I can not make any call. Asterisk ends itself when I start to make call. But there is no core file generated although I declare “dumpcore = yes” in asterisk.conf file.
According to the link you provided, I run the following command ;
gdb -ex “thread apply all bt” --batch /usr/sbin/asterisk 12345 > /tmp/backtrace-threads.txt
This command is ended within 1-2 seconds with the following message
81 …/sysdeps/unix/syscall-template.S: No such file or directory.
Due to the fact that, this command is ended in 1 seconds, I can not apply my problem scenario. Do you have any advice ?
Are you using any third party modules or other things? If so then they may stop it from loading and have to be built the same way.
gdb should end quickly. That command is taking a snapshot of an already running program. It doesn’t take long to take a snapshot.
You start Asterisk, get it into the problem state, then run gdb. You can’t possibly know the correct thing to substitute for 12345 unless you have had Asterisk properly started, already.
Thanks for the hint, it just worked out. After starting asterisk, I run the command and focused on the thread which refers to recording module.
Thread 30 (Thread 0x7f4e3410c700 (LWP 11881)):
#0 0x00007f4e36fcbc44 in pthread_mutex_lock (mutex=0x7f4e352bea80) at forward.c:192
#1 0x00007f4e350bb0da in _Unwind_Find_FDE () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#2 0x00007f4e350b8507 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#3 0x00007f4e350b96d8 in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#4 0x00007f4e36fcea06 in __GI___backtrace (array=, size=32) at …/sysdeps/x86_64/backtrace.c:109
#5 0x000000000050876e in ast_bt_get_addresses (bt=0x7f4df0001fd0) at logger.c:1580
#6 0x0000000000500da2 in __ast_pthread_mutex_lock (filename=0x7f4dff39b3c4 “res_recording.c”, lineno=1861, func=0x7f4dff39d7f4 <PRETTY_FUNCTION.14419> “do_rtsp_thread”, mutex_name=0x7f4dff39b5c5 “&(&seslist)->lock”, t=0x7f4dff59f450 <seslist+16>) at lock.c:196
#7 0x00007f4dff398324 in do_rtsp_thread (data=0x0) at recording.c:1861
#8 0x0000000000596ed4 in dummy_start (data=0x2a387e0) at utils.c:1093
#9 0x00007f4e35e4c184 in start_thread (arg=0x7f4e3410c700) at pthread_create.c:312
#10 0x00007f4e36fbe03d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111
According to the backtrace, it seems like it is about locking thread which creates rtsp session. Do you have any additional comment ?
Seems like it, but as I don’t know the code or what is normal - can’t say for certain.
I’ve realized that, messages file includes app_mixmonitor related logs after the first call ended;
[May 31 17:35:58] VERBOSE[17097][C-00000000] file.c: -- <Bridge/0x7fb100001358-input> Playing 'confbridge-leave.slin' (language 'en')
[May 31 17:35:59] VERBOSE[17099] app_mixmonitor.c: == MixMonitor close filestream (mixed)
[May 31 17:35:59] VERBOSE[17099] app_mixmonitor.c: == End MixMonitor Recording ConfBridgeRecorder/conf-4444-uid-1979955278
[May 31 17:36:01] NOTICE[17019] chan_sip.c: Received SIP subscribe for peer without mailbox: 4502
[May 31 17:36:03] VERBOSE[17019][C-00000001] netsock2.c: == Using SIP RTP CoS mark 5
These logs belongs to “mixmonitor_thread” function. I couldn’t understand why this application is run while I try to make VOX enabled call recording only ?