Re: [asterisk-users] Using PauseMonitor with MixMonitor
On Fri, Jul 12, 2013 at 9:14 AM, Ishfaq Malik wrote:
> Hi
>
> I'm using asterisk 1.8 on CentOS 5
>
> I'm initiating call recordings with MixMonitor and trying to pause them
> with the features.conf.
>
> Whenever I try to pause the recording the call dies. Is PauseMonitor
> incompatible with MixMonitor?
>
> Here are some key log excerpts
>
> features reload
> == Parsing '/etc/asterisk/features.conf': == Found
> == Registered Feature 'testfeature'
> == Mapping Feature 'testfeature' to app 'Playback(tt-monkeys)' with code
> '#9'
> == Registered Feature 'pauseMonitor'
> == Mapping Feature 'pauseMonitor' to app 'pauseMonitor()' with code '#00'
> == Registered Feature 'unpauseMonitor'
> == Mapping Feature 'unpauseMonitor' to app 'UnpauseMonitor()' with code
> '#01'
>
> -- Feature Found: pauseMonitor exten: pauseMonitor
> -- Executing [h@x:1] System("SIP/xxx.xxx.x.xxx-000c",
> "php agi-bin/process-call.php 0 "2013-07-12 15:09:30" inbound")
> == MixMonitor close filestream
> == End MixMonitor Recording SIP/213.166.5.185-000c
>
> I've tried executing it on self and peer with the same result.
>
> Any thoughts?
>
The PauseMonitor and UnpauseMonitor applications work with the Monitor
application not MixMonitor. If a Monitor is not active on the channel then
the PauseMonitor and UnpauseMonitor applications hangup the channel.
Richard
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AMI timeouts
On Jul 11, 2013, at 2:40 AM, Alexander Frolkin wrote: > The Java process has an AMI connection to Asterisk which it keeps open > continuously. When sending an AMI request, the process will wait a > certain amount of time for a response (I think the timeout is 5 seconds) > and if it hasn't received it, will retry the request up to 5 times. Timeout based retries on AMI is probably going to be a problem. AMI uses TCP, which has its own retry/retransmission logic. While the TCP connection is alive, you can safely assume that the message is either on its way to Asterisk, Asterisk is processing the message, or the response is heading back to you. Now if the TCP connection fails after you've sent a request, but before you receive a response, then you really have no way of knowing if the request was received/processed/rejected/etc. At that point, the best you can do is reestablish the AMI connection and retry the action. > Occasionally, the Java process logs show AMI requests timing out (after > 5 tries). What I see in packet captures of the AMI traffic is: > > 1. Java process sends a request (e.g., add member to queue) Do you see the TCP ACK coming back from Asterisk? > 2. Retries 5 seconds later > 3. Retries again 5 seconds later > 4. Retries again 5 seconds later > 5. Retries again 5 seconds later > 6. Logs a timeout > 7. After a few more seconds, Asterisk replies to all five requests > in one go (in a single packet; so, e.g., for "add member to queue" > it would reply "success", then four failures because the member is > already added); however at this stage, the Java process has given > up During the quiet period while you're waiting for the response, do you receive events over that AMI connection? Are there other actions that you're attempting to execute? Is there any consistency as to which commands are getting delayed? > It feels like Asterisk queues up the AMI responses and then > periodically sends out all the responses in the queue in one go. Is > something like this going on? Does the frequency at which Asterisk > flushes the queue depend on load? Are there any tunable in the config > for this? No, there's no response queue in Asterisk. For the action's I've looked at, it pretty much immediately processes the request and sends the response. There are any number of reasons why the response would be delayed, but the >25 seconds delay you're seeing is excessive for any of the reasons I can think of. The resource you're using AMI to access may be busy doing something else. Or the request is simply taking that long to process. Packet loss could cause delays in getting responses, but usually not for the lengths of times you're talking about. I know it's not a lot of info, but hopefully you can turn up some logging or packet captures to narrow down what's going on. > Thanks in advance, > > Alex -- David M. Lee Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Using PauseMonitor with MixMonitor
Hi
I'm using asterisk 1.8 on CentOS 5
I'm initiating call recordings with MixMonitor and trying to pause them
with the features.conf.
Whenever I try to pause the recording the call dies. Is PauseMonitor
incompatible with MixMonitor?
Here are some key log excerpts
features reload
== Parsing '/etc/asterisk/features.conf': == Found
== Registered Feature 'testfeature'
== Mapping Feature 'testfeature' to app 'Playback(tt-monkeys)' with code
'#9'
== Registered Feature 'pauseMonitor'
== Mapping Feature 'pauseMonitor' to app 'pauseMonitor()' with code '#00'
== Registered Feature 'unpauseMonitor'
== Mapping Feature 'unpauseMonitor' to app 'UnpauseMonitor()' with code
'#01'
-- Feature Found: pauseMonitor exten: pauseMonitor
-- Executing [h@x:1] System("SIP/xxx.xxx.x.xxx-000c", "php
agi-bin/process-call.php 0 "2013-07-12 15:09:30" inbound")
== MixMonitor close filestream
== End MixMonitor Recording SIP/213.166.5.185-000c
I've tried executing it on self and peer with the same result.
Any thoughts?
Thanks in Advance
Ish
--
Ishfaq Malik
Department: VOIP Support
Company: Packnet Limited
t: +44 (0)845 004 4994
f: +44 (0)161 660 9825
e: i...@pack-net.co.uk
w: http://www.pack-net.co.uk
Registered Address: PACKNET LIMITED, 2A ENTERPRISE HOUSE, LLOYD STREET
NORTH, MANCHESTER
SCIENCE PARK, MANCHESTER, M156SE
COMPANY REG NO. 04920552
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] [SPAM] - Re: queue moh - Email found in subject
Hi Ioan, I have done that [Set(CHANNEL(musicclass)=…] but it still doesn’t work when a ‘queue’ call is put on hold. So, I can get it to play the correct moh when I use the ‘r’ option – but still get silence when I don’t include the ‘r’. So I’ve sort of fixed my second point (with the ‘r’) but the first point (without the ‘r’) is still not working. Thanks for your feedback ☺ Cheers Andy From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Ioan Indreias Sent: 10 July 2013 20:24 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [SPAM] - Re: [asterisk-users] queue moh - Email found in subject Hello Andy, Have you tried using SetMusicOnHold command before Queue command? BR, Ioan On Wed, Jul 10, 2013 at 7:55 PM, Andrew Thomas wrote: Hi All, Sorry if this has been covered already, but I don't tend to follow this list as close as I should these days. Problem is that if a call comes in to a queue without option 'r' specified - moh plays as expected. Now, when that call is answered, all is fine. Trouble comes when that person then puts the caller on-hold. No moh is heard by the caller (in fact, they get silence). If I use 'r' - then ringing is heard - but the queue's musiconhold/musicclass is ignored completely. When the caller is put on hold, they do hear moh but the default moh context is used - not the moh of the queue. What I need is for the queue's moh to be used when the caller is put on hold (and without using the 'r' feature). Is this possible? * 1.8.16.0 (tried on various flavours of 1.8). Queue static and realtime (same outcome). Cheers Andy -- If you have received this communication in error we would appreciate you advising us either by telephone or return of e-mail. The contents of this message, and any attachments, are the property of DataVox, and are intended for the confidential use of the named recipient only. If you are not the intended recipient, employee or agent responsible for delivery of this message to the intended recipient, take note that any dissemination, distribution or copying of this communication and its attachments is strictly prohibited, and may be subject to civil or criminal action for which you may be liable. Every effort has been made to ensure that this e-mail or any attachments are free from viruses. While the company has taken every reasonable precaution to minimise this risk, neither company, nor the sender can accept liability for any damage which you sustain as a result of viruses. It is recommended that you should carry out your own virus checks before opening any attachments. Registered in England. No. 27459085. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] analog phone digit delay
Have you tried finish the dialed number with "#"? I'm not sure if this is working on your setup but this is one workaround that we give to our users when they initially complain about big delays on SIP phones (where we have not changed yet the default dialplan). HTH, Ioan. On Fri, Jul 12, 2013 at 12:33 AM, Justin Killen < jkil...@allamericanasphalt.com> wrote: > The dahdi source already specifies an 8 second inter-digit timeout. The > problem is that it's erroneously using the matched pattern timeout instead, > because the error handling part of the dialplan isn't distinguishable from > the 'meat' of the dialplan. > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
