[Home]

Summary:ASTERISK-10627: asterisk releases progressively breaking queues
Reporter:Stephen Kratzer (kratzers)Labels:
Date Opened:2007-10-26 11:47:07Date Closed:2007-11-21 13:59:19.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) debug_output
( 1) debug.out
( 2) etc_asterisk.tar.bz2
Description:In Asterisk 1.4.13:
- MoH only plays between attempts to dial agents
- DTMF detection does not work at all for queued calls
- when a queued caller hangs up, a phantom call bounces around the queue until an agent answers; the call is then destroyed

In Asterisk 1.4.11
- MoH same as above
- DTMF detection only works between attempts to dial agents
-- one DTMF digit causes the destination channel to be hung up
-- if a second digit is sent/received before another agent is tried, the second digit is matched against the dialplan in the queue's context which is what should happen with the first digit sent

In Asterisk 1.4.9
- DTMF same as above

In Asterisk 1.4.8
- None of the above issues exist in this release

****** ADDITIONAL INFORMATION ******

We're running CentOS 5.0 and kernel 2.6.18-8.1.10.el5 at the moment, but these issues should be reproducible across platforms/distros. Below are the relevant, non-default portions of our very minimal test configs.

== sip.conf ==

[xxA]
context=test
type=friend
secret=XXX
host=dynamic
mailbox=xxA
callgroup=X
pickupgroup=X
dtmfmode=rfc2833
disallow=all
allow=ulaw
progressinband=no
canreinvite=yes
qualify=yes

[xxB]
context=test
type=friend
secret=XXX
host=dynamic
mailbox=xxB
callgroup=X
pickupgroup=X
dtmfmode=rfc2833
disallow=all
allow=ulaw
progressinband=no
canreinvite=yes
qualify=yes

== agents.conf ==

[agents]

agent => xxA,,Person A
agent => xxB,,Person B

== queues.conf ==

[test]
context = queue-exit
strategy = rrmemory
timeout = 18
retry = 2
wrapuptime = 15
reportholdtime = no
announce-holdtime = once
announce-round-seconds = 10
announce-frequency = 0
periodic-announce-frequency = 60
joinempty = strict
leavewhenempty = strict

member => Agent/xxA
member => Agent/xxB

== test.ael ==

context test {
       100 => {
               Queue(test);
       }
}

context agents {
       _XXX => {
               Dial(SIP/${EXTEN});
       }
}

context queue-exit {
       # => {
               Playback(digits/pound);
               Hangup();
       }

       9 => {
               Playback(digits/9);
               Hangup();
       }
}
Comments:By: Mark Michelson (mmichelson) 2007-10-26 17:13:49

I just made a test setup using the latest 1.4 SVN checkout using remarkably similar configs. The only difference between your configs and mine were names of contexts and extension numbers (and the fact that I did not use AEL). I could not reproduce any of the faults you described. I could properly exit out of a queue to a context with DTMF, I could hear MOH at all times before the call was picked up, and there was no extra call after hanging up.

I suspect that there may be other portions of your configuration that may be causing the behavior you're experiencing. Since you have such a small setup, would you mind posting your entire dialplan? Also, could you upload console messages (with debug and verbosity set > 4) that are output in these failure situations?

I did, however, experience a much worse problem, and that was that I had no audio once an agent answered the phone (as described by issue ASTERISK-10606).
By: Stephen Kratzer (kratzers) 2007-10-27 08:03:54

On our test server, the only changes made to the default configs are the ones posted above. I just tried again, and was able to reproduce. Here's what I did:

wget http://downloads.digium.com/pub/asterisk/releases/asterisk-1.4.13.tar.gz
tar -xzf asterisk-1.4.13.tar.gz
cd asterisk-1.4.13
./configure
make && make install && make samples
paste above configs into /etc/asterisk/{sip,agents,queues}.conf and /etc/asterisk/extensions.ael changing only the the extensions to 421 and 426
asterisk -vgcn
dial extension 100 from 426
problem has been reproduced

Note that both agents are logged in, and the second extension must actually ring. If I put both agents on DND, and no extensions are actually being tried (the caller is just sitting in the queue), MoH and DTMF detection work fine, but I still have the phantom call. As soon as there are available agents to try, everything breaks.

Attached is the output of a session. I started asterisk, set debug and verbose to 10, dialed 100 from extension 426, and pressed DTMF digits 9 and pound. I didn't hear MoH, DTMF detection didn't work, and when I hung up, I had a phantom call.

After hanging up, 'show channels', says:

Channel              Location             State   Application(Data)
SIP/426-09f73500     100@test:1           Ring    Queue(test)

Hope this helps.


By: Mark Michelson (mmichelson) 2007-10-29 09:27:31

I am in the process of setting up a test like the one you have described in your bug note. In the meantime, the file you supplied was helpful, but unfortunately no debug messages were printed. Could you please add "debug" and "dtmf" to the line labeled "console" in logger.conf? A lot more messages will appear as a result, and they may be helpful in determining where the problem is.

I will report back soon to let you know how my next round of tests goes.
By: Stephen Kratzer (kratzers) 2007-10-29 13:02:48

After adding debug and dtmf to logger.conf (console => notice,warning,error,debug,dtmf), I did the following, the output of which is attached:

asterisk -gcn | tee debug.out
core set debug 10
core set verbose 10

took 421 off of DND
dialed 100 from 426 which queued the call in the test queue
pressed 9
pressed pound
hung up on 426
answered the phantom call on 421 (which then was hung up / destroyed by *)
By: Leif Madsen (lmadsen) 2007-10-29 14:11:56

How are you logging the agents in? I'm trying to reproduce this, but I don't understand how you are on DND if the agent is logged in and on the line. I'm obviously missing something here, since I can't call an Agent that isn't logged in, and the Queue() just falls through to the next priority.
By: Leif Madsen (lmadsen) 2007-10-29 14:14:38

And I just noticed a Local channel in your debug... are you sure you're supplying all the required configuration information?
By: Leif Madsen (lmadsen) 2007-10-29 14:38:18

I'm going to request that you attach your extensions.ael because it doesn't appear that you are giving us all the information required to reproduce this issue.

In your debug message you've provided, it contains a Local channel, and you mention DND in a note further down, which indicates you're using a Call Back Agent, which wasn't mentioned originally in this bug.

Instead of try to guess what your dialplan looks like, I'm going to need the whole thing since what you've provided doesn't appear to be enough information.

Thanks!
Leif.
By: Stephen Kratzer (kratzers) 2007-11-01 10:13:06

I attached a tarball of /etc/asterisk which contains the current dialplan being used. Again, it is just the samples plus the minimal changes listed above. Agents are still logged in from a previous dialplan which shouldn't matter.
By: Leif Madsen (lmadsen) 2007-11-01 10:20:51

Actually... I think it does matter, because you have them logged in from a previous dialplan. I certainly won't have those agents logged in, which means I need to know how you have them logged in.
By: Stephen Kratzer (kratzers) 2007-11-01 10:34:09

AgentCallbackLogin(${CALLERID(num)});
By: Stephen Kratzer (kratzers) 2007-11-01 11:00:44

Added the following to extensions.ael:

1 => {
     AgentCallbackLogin(${CALLERID(num)}||${CALLERID(num)}@agents);
}

It's possible that it's due to stale SIP registrations and astdb entries.


By: Leif Madsen (lmadsen) 2007-11-01 12:30:15

OK, I've been trying to reproduce this issue for the last hour, and everything works perfectly fine for me.

Fresh install of CentOS 5 with updates.

Tried both 1.4.13 and latest 1.4 branch from SVN.

* MoH works constantly for me when agents are attempting to be rung (whether the phone is ringing or not)

* Tried putting one and both of the phones on DND -- call is rejected with a 486 Busy Here, and the Queue() keeps trying, but MoH exists the whole time

* At any point in time I'm able to press # or 9 to get the "pound" or "nine" audio file

* I tried unplugging the phones from the network and then calling the Queue() before the phones were deemed to be unregistered -- no ill effects

* I tried calling the Queue() after the phones were deemed to no longer be reg'd -- still no ill effects

* I never saw a phantom call bouncing around at all. 'show channels' and 'sip show channels' confirmed this -- no channels were up



You might want to try reproducing this on a fresh install of CentOS 5 on another box and maybe giving the developers access to the box, because no matter what I do, with the information you have provided, I have been unable to reproduce any of the issues listed in this bug.
By: tdavis (tdavis) 2007-11-02 16:55:17

I have an issue that is possibly related.  I am also using CentOS 5, but with the x86_64 2.6.18-8.1.15.el5 kernel.  I need to do a bit more testing to narrow it down, but I wanted to go ahead and pipe up anyway.  Moved from 0011071 at the request of putnopvut:

I am seeing the following happen under 1.4.11 and 1.4.13.  My agents are not persistent--they log in and out of the queue from their phones.

Consider this:

exten => 2315551212,1,Answer
exten => 2315551212,n,Ringing
exten => 2315551212,n,Wait(3)
exten => 2315551212,n,Queue(support|n)

When I call in *when an agent is available to take the call* (i.e. my call doesn't have to wait in the queue), then I just hear silence. No ringing, no MOH, nothing. However, once my call is answered, I can hear the other person just fine and vice versa. "rtp debug" shows that no RTP packets are sent before the call is answered.

Let me reiterate that if all agents are busy and my call has to go in the queue, then I do hear the friendly Asterisk lady tell me that my call is in line as expected, and I do hear the MOH that follows her. However, I still don't hear the ringing.

Now, if I modify that dialplan to add in a call to Playback like so:

exten => 2315551212,1,Answer
exten => 2315551212,n,Playback(beep) ; kludge >:-(
exten => 2315551212,n,Ringing
exten => 2315551212,n,Wait(3)
exten => 2315551212,n,Queue(support|n)

...then after the beep I hear the ringing and MOH just fine in all cases. "rtp debug" shows RTP packets being set immediately after answer.

Forgive my uninformed speculation, but it's as if the RTP doohickey isn't initialized until a sound is played back, whether that's via the Playback() above or via the friendly Asterisk lady speaking up. Thus when an agent is already available, the friendly Asterisk lady doesn't have to tell me anything, which causes the RTP doohickey to not initialize, which causes silence.
By: Dmitry Andrianov (dimas) 2007-11-02 18:45:58

To me, your issue looks unrelated. Honestly I do not understand why you expect ringing sound at all. If you want ringing instead of MoH when user is in the queue - add 'r' flag to the queue.
If you want ringing before - I believe you should use PlayTones not Ringing. (see issue 10825 for some explanation)
By: tdavis (tdavis) 2007-11-03 16:29:41

dimas,

I expect ringing because I call Ringing().  Also, because the caller hears silence until the agent answers.  If for some reason the agent is unable to pick up for, say, 10 seconds, the caller is going to start assuming their call has been dropped or they've been put on hold or something.  It is not intuitive to the caller.

I do not want ringing instead of MOH.  I want ringing when the agent's phone is ringing, which seems intuitive to me.  I have read 10825 and will try PlayTones() Monday morning when I'm back on the job, but it isn't intuitive to me why Ringing() in one of those two dialplans produces an audible ringback and the other doesn't.
By: Dmitry Andrianov (dimas) 2007-11-04 08:47:46.000-0600

tdavis,
so you want caller to hear MoH until he has 1st position in the queue and then he start hearing ringing? I'm not sure this is achievable. And also it would be really strange. What happens if agent does not answer his phone? The caller who just heard ringing will be hearing MoH again before directed to another ageng? Yeah, pretty "intuitive".

Repeating myself - Ringing just indicates ringing, not producing any sounds. Probably a lot depends on channel driver. You are not saying anything about what channels you receive cals on - Zap/SIP/something else. For example, when I call using SIP softphone (ZoIPer), Ringing after Answer NEVER ring the phone no matter - did I Playback(beep) or not.

However I still do not understand how your problem is related to this specific issue - I see nothing in common...
By: Stephen Kratzer (kratzers) 2007-11-04 12:01:45.000-0600

I deleted all asterisk-related directories, reinstalled Asterisk 1.4.13, and still have the issues. Sometime next week, I'll try a fresh OS install, and fresh Asterisk install. If I can still reproduce the issues, I'll see what I can do about giving shell access to a developer.
By: tdavis (tdavis) 2007-11-05 09:17:48.000-0600

dimas,

I am not explaining myself very well.  The Ringing/Wait parts of the dialplan are red herrings.  I thought they helped illustrate the problem.  Let me try it again.  The reason why this is relevant is as follows:

If an agent is available when a call comes in, then with this dialplan:

exten => 2315551212,1,Answer
exten => 2315551212,n,Queue(support|n)

...the caller hears nothing but silence until the agent picks up their phone.  The caller does not hear MOH.

However, by changing it to this:

exten => 2315551212,1,Answer
exten => 2315551212,n,Playback(beep) ; kludge >:-(
exten => 2315551212,n,Queue(support|n)

...then the caller hears the beep and then the MOH is heard as expected.

The Answer/Ringing/Wait idiom I mentioned before is something I've seen in numerous tutorials, such as on voip-info.org.  A caller typically expects to hear a couple of rings after they dial a number.  This is not, however, directly relevant.

The channels are SIP channels.


By: tdavis (tdavis) 2007-11-05 09:21:36.000-0600

For the record, this doesn't work, either:

exten => 2315551212,1,Answer
exten => 2315551212,n,PlayTones(ring)
exten => 2315551212,n,Wait(3)
exten => 2315551212,n,StopPlayTones
exten => 2315551212,n,Queue(support|n)

Same as before, I have to add a call to Playback() before PlayTones() to hear the ringing.
By: Leif Madsen (lmadsen) 2007-11-05 09:35:55.000-0600

tdavis:  Where are the calls coming from (technology wise?) because I get MoH as soon as I enter the Queue() from a SIP channel and get MoH the entire time until the Agent answers.
By: Dmitry Andrianov (dimas) 2007-11-05 09:40:59.000-0600

tdavis,
makes sense now. However, it looks like your problems are not Queue-related if Answer+PlayTones does not work too.
I just tested it with SVN-branch-1.4-r85720M using SIP softphone and the following (AEL) dialplan:

120 => {
Answer;
PlayTones(ring);
Wait(10);
};

DOES work - I hear ringing. So if your problem is 100% reproducible, I would creaet new issue for it. (be prepared that debug output will be first thing you will be asked)
By: tdavis (tdavis) 2007-11-05 10:15:19.000-0600

I regret that I owe an apology.  Your saying that it worked fine for you made me go back to the drawing board, and I found that the softswitch we register to had started sending us RTP traffic from a different IP that had not yet been added to our firewall rules.  Apologies for the distraction.
By: Leif Madsen (lmadsen) 2007-11-05 10:52:53.000-0600

Glad you found it tdavis!

Thanks for the update.
By: Stephen Kratzer (kratzers) 2007-11-21 13:55:53.000-0600

All issues have been fixed in 1.4.14.
By: Mark Michelson (mmichelson) 2007-11-21 13:59:18.000-0600

Closing since the problem is fixed.