[Home]

Summary:ASTERISK-10606: No audio on calls into queues with non-persistent agents
Reporter:callguy (callguy)Labels:
Date Opened:2007-10-23 16:04:43Date Closed:2007-11-05 17:29:06.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 11071.patch
( 1) console-output.txt
( 2) dialplan.txt
( 3) queues.conf.txt
Description:For any version of asterisk >1.4.12 when using queues with agent logon/logoff no audio passes on the call. From other reports it seems that something committed from bug 10406 may have contributed to this, but it's unclear.

This is 100% reproducible. I have attached relevant console output, dialplan snippet, and queues.conf. Also of note is that rtp debug shows that the stream is in-fact being passed.
Comments:By: callguy (callguy) 2007-10-23 17:34:29

When running asterisk in debug mode the following message appears on the console after answering:

-- SIP/DEMO-p9071-095dd2e8 answered Local/9071@demo-e45e,2
[Oct 23 18:49:03] DEBUG[20538]: app_queue.c:2167 wait_for_answer: Dunno what to do with control type -1
-- Agent/05555559071 answered SIP/1.1.1.1-095d4760
By: Ted Brown (ted brown) 2007-10-24 02:57:56

callguy: I also see this message with core set debug 5:

[Oct 24 10:04:26] DEBUG[15842]: chan_local.c:295 local_write: Not posting to queue since already masked on 'Local/Agent@internal-4faa,1'
[Oct 24 10:04:26] DEBUG[15843]: chan_local.c:295 local_write: Not posting to queue since already masked on 'Local/Agent@internal-4faa,2'                                                                              

These messages are repeated again and again, I guess once for every rtp packet.
I made an 'rtp debug', and it shows packets are received from the peers, but not sent to them
By: callguy (callguy) 2007-10-24 15:24:30

I've looked into this a bit further. From what I can tell the message we are seeing is in the default case of:

switch (f->subclass)

which gets set by:

f = ast_read(winner);

and ast_read gets a frame from a channel. It looks like either the -1 is a result code of some sort of error condition, or the ast_frame instance is getting set to different things over it's lifetime.

After doing some testing it appears that around line 2225 of channel.c is where Corydon76's patch from 10406 was applied. Reverting that patch seems to make this issue go away, so it seems the ultimate cause is in that area.

I don't know enough about what is going on in this part of the code to make a patch, but hopefully this will help.
By: callguy (callguy) 2007-10-25 12:08:43

This code was added to channel.c (line 2208 in 1.4.12 with the patch from bug 10406).

       /* Check if there's an underlying channel */
/*      if (chan->tech->get_base_channel && (base = chan->tech->get_base_channel(chan)) != chan) {
               int count = 0;
               while (!base || ast_mutex_trylock(&base->lock)) {
                       if (count++ > 10) {
                               f = &ast_null_frame;
                               goto done;
                       }
                       ast_mutex_unlock(&chan->lock);
                       usleep(1);
                       ast_mutex_lock(&chan->lock);
                       base = chan->tech->get_base_channel(chan);
               }
               ast_mutex_unlock(&chan->lock);
               chan = base;
       }
*/      

Commenting this out (as I've done above) gets audio to return to the queue. It seems this code was just added, there was no similar check beforehand. We've tried adding a longer wait to get a lock, but regardless there is no audio. Commenting this out and audio works both directions without issue.


By: callguy (callguy) 2007-10-26 11:05:52

Ted Brown: can you try commenting out the code in my last message, recompiling and see if you get the same results that we do (that calls process normally again)? I would like to verify that it's the same offending code in both of our use cases.
By: Mark Michelson (mmichelson) 2007-10-26 17:09:24

I have reproduced the no audio situation while running another test. I will look into this more when I come back to work next week.
By: callguy (callguy) 2007-10-29 11:13:49

thanks - we have our dev environment set up to test this so if you have anything you'd like us to try let me know.
By: Ted Brown (ted brown) 2007-10-29 11:38:24

callguy: i've tried commenting the lines you say, and the audio works fine.
By: Martin Vit (festr) 2007-10-29 11:43:59

i'm confirming this too. removing lines works for me too.
By: Tilghman Lesher (tilghman) 2007-10-29 14:40:10

Okay, but removing that code also reintroduces a possible deadlock condition.
By: callguy (callguy) 2007-10-29 14:49:24

Right - which is why I wasn't suggesting removing it permanently. My intent was more to verify that that is exactly what's causing the audio issues. there must be a way to keep in deadlock avoidance without breaking audio.

We've tried playing with different permutations to see if we could come up with a patch, but other than removing it I haven't been able to get anything that works.
By: Mark Michelson (mmichelson) 2007-10-31 09:36:17

Just as an update, this issue has been discussed amongst several of us over the last couple of days.

I came up with a patch that kept the deadlock avoidance, got audio to return, but the quality of the audio from agent->caller was terrible (you could barely understand what the agent said). More work will need to be done before we can offer an acceptable solution.
By: Mark Michelson (mmichelson) 2007-11-02 14:03:35

I have uploaded a patch which reworks the deadlock avoidance introduced in issue 10406. Please test this to be sure there are no problems introduced.
By: tdavis (tdavis) 2007-11-02 16:40:42

[Moved to 0011095 at request of putnopvut]


By: Mark Michelson (mmichelson) 2007-11-02 16:49:23

tdavis:

This issue was only caused on agents who logged in via AgentCallbackLogin, and was an issue once the agent answered the phone, no audio was heard. Your problem sounds more like a problem before the agent channel is even rung.

Your issue seems different than this one, however it does sound remarkably similar to ASTERISK-10627. Does the description on that issue sound similar to what you are experiencing? If so, please comment on that one regarding your setup, because tests done locally by blitzrage and I have proved fruitless since we have not been able to reproduce.
By: tdavis (tdavis) 2007-11-02 16:54:13

I moved my report to the other ticket.  Thank you.
By: Ted Brown (ted brown) 2007-11-05 04:58:25.000-0600

Patch tested. Audio works fine, and everything else seems to be better. No new problems
By: callguy (callguy) 2007-11-05 11:44:42.000-0600

We've also tested this patch, no apparent audio issues or other problems during testing.
By: Digium Subversion (svnbot) 2007-11-05 17:27:56.000-0600

Repository: asterisk
Revision: 88826

U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r88826 | mmichelson | 2007-11-05 17:27:55 -0600 (Mon, 05 Nov 2007) | 6 lines

Reworked deadlock avoidance in __ast_read. Restored audio to
callback agents.

(closes issue ASTERISK-10606, reported by callguy, patched by me, tested by callguy and Ted Brown)


------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-11-05 17:29:06.000-0600

Repository: asterisk
Revision: 88827

_U  trunk/
U   trunk/main/channel.c

------------------------------------------------------------------------
r88827 | mmichelson | 2007-11-05 17:29:06 -0600 (Mon, 05 Nov 2007) | 14 lines

Merged revisions 88826 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r88826 | mmichelson | 2007-11-05 17:29:29 -0600 (Mon, 05 Nov 2007) | 6 lines

Reworked deadlock avoidance in __ast_read. Restored audio to
callback agents.

(closes issue ASTERISK-10606, reported by callguy, patched by me, tested by callguy and Ted Brown)


........

------------------------------------------------------------------------