Summary:	ASTERISK-14888: Conference room with app ConfBridge has no audio.
Reporter:	Brendan Martens (shrift)	Labels:
Date Opened:	2009-09-25 08:31:05	Date Closed:	2009-09-29 14:52:32
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Applications/app_confbridge
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) console-beta4.txt ( 1) console-rc1.txt ( 2) console-rc2.txt ( 3) console-sparse-trunk.txt ( 4) extensions.conf.sparse ( 5) full-log-beta4.txt ( 6) full-log-rc1.txt ( 7) full-log-rc2.txt ( 8) full-log-sparse-trunk.txt ( 9) sip-debug-conf-bridge-1.6.2.0-rc2.txt (10) sip-history-beta4.txt (11) sip-history-conf-bridge-1.6.2.0-rc2.txt (12) sip-history-rc1.txt (13) sip-history-rc2.txt (14) sip-history-sparse-trunk.txt
Description:	I have setup a conference in meetme.conf, and am connecting to it with ConfBridge in the dialplan. When I connect, I can see in the console that it sees me entering, and plays the audio file, but my endpoint has no audio. When I join with another endpoint, I still hear nothing either way. This is a bit of a regression it seems. If I go back to -rc1 I actually do get some audio. It seems that if I connect from an internal softphone FIRST I can pass audio from that endpoint to the conference, but if I connect via external sip trunk, I cannot pass any audio into the asterisk, but those sip trunk endpoints do receive audio from the the softphone, if connected first. Also, the softphone itself will not receive any audio after the first announcement of "you are currently the only person in the conference." The hold music for instance, does not seem to play for the softphone, but if I call in from a sip trunk I get the announcement and the hold music. Now for -rc2, I get no audio for anyone in any direction at all. I have not changed my configuration between the scenario I described above to upgrading to rc2. I am baffled further because I am fairly certain that I had a conference fully functioning with confbridge, but somewhere between my first build of 1.6.2 (beta4 maybe?) and now it has stopped working correcly for all versions, and as I mentioned, half works for -rc1. I don't really know how else to debug this, there seems to be limited information available to me in regards to what the confbridge may actually be doing/not doing. I am happy to dig into it more. I hope this is not just a stupid mis-configuration on my part, but as I said, I did have it working, then it stopped and as far as I can tell I haven't changed anything in relation to the conference. ****** ADDITIONAL INFORMATION ****** There isn't a Category for Applications/ConfBridge.
Comments:	By: Leif Madsen (lmadsen) 2009-09-28 12:52:33 Added Applications/app_confbridge and assigned to the category. As for debugging informaion, can you please provide the sip debug, sip history, and console output, with debugging (logger.conf, console => debug,...), and attach it as a file to this issue when you reproduce it? It might be useful to reproduce on -beta4, -rc1, and -rc2 if you're getting different results with the same configuration. Thanks! By: Brendan Martens (shrift) 2009-09-28 13:51:29 Okay, I *think* I've got what you want. There is so much spam with debug stuff on that its hard to tell... In logger.conf I set debug => debug, then tailed that instead of adding it to console, I assume that is ok? It was empty. The console output is combined with sip debug, I don't know of another way to do that. If there is an easier way to capture sip debug then I am all ears. I'll attache the files. ( I think I have to do it separate from my comment?) By: Brendan Martens (shrift) 2009-09-28 13:53:33 If this IS the information your looking for, then I am happy to do it for the other versions as well. Just let me know if I need to adjust the information I'm posting. I have -rc1 installed, but I deleted my beta4, and can no longer find the tar for it anywhere online. if you know where I can get it I can recompile and get the same information for that. By: Leif Madsen (lmadsen) 2009-09-28 14:20:01 Yes, this is pretty much all of it. At least in one of the versions it would be useful for the console output as well though. I think you could get everything by just doing the 'full' logging in logger.conf and attaching that log file. For -beta4: svn co http://svn.asterisk.org/svn/asterisk/tags/1.6.2.0-beta4 By: Brendan Martens (shrift) 2009-09-28 15:03:49 Ok, so this time I'm posting the output of full with this setting in logger.conf "full => notice,warning,error,debug,verbose". Ok, new batch of -rc2 attachments, I think I got everything you wanted this time. By: Brendan Martens (shrift) 2009-09-28 15:34:34 Ok, I got everything attached. The behavior of beta4 and -rc1 were the same (as described in the description of the bug) from the limited testing I did while trying to capture the logs and not produce too much extra. : ( I know that I had a conference working correctly at some point, but I've been doing a lot of tweaking of my dialplan/features.conf etc... I don't know what I could have changed to make it non functional now, but I can try whatever you need to help debug. All of the information generated for the attachments has been with an identical set of conf files. The compiles are mostly the same, with the exception of somewhat different compiled app modules, and I htink -rc2 may be compiled without optimizations. If it matters I can double check. Testing for each release mentioned was done by reinstalling a .deb generated by checkinstall then restarting my asterisk service... I've not noticed that causing any trouble before, but if I need to clean out some files in between to make sure there is nothing overlapping from different versions, i can do that. By: Brendan Martens (shrift) 2009-09-28 15:52:18 One more note... maybe... I believe I have read about the new bridge protocol that it only does an actual bridge once there are more than 2 users in it, until then its the normal method of connecting endpoints. I did in fact try the bridge in -rc2 with 3 users, it gave the same results as 2. I can go back and check the behavior in -beta4 or -rc1 if necessary. By: Leif Madsen (lmadsen) 2009-09-29 08:31:47 It may be beneficial to try and reproduce this on a stock, vanilla Asterisk (not from packages) with a very simple dialplan (only 1 or 2 lines) which demonstrates this problem. Otherwise, this could very well be a configuration issue on your side, at which point I'd direct you to the appropriate asterisk-users mailing list for more debugging. If you can demonstrate this as I describe above, then we can move this issue forward. At this point, there just seems to be too many variables to know whether there is a bug, or if this is a configuration issue. By: Brendan Martens (shrift) 2009-09-29 09:28:12 Ok, I'll dumb down my dialplan. This IS vanilla asterisk. I'm compiling all of them from source, THEN making them into .deb packages on my own. I'll update after I retry with a simpler setup. By: Leif Madsen (lmadsen) 2009-09-29 09:38:21 Oh ok, sorry I misunderstood. Thanks for doing that. Hopefully this will help to narrow down the issue. Thanks again! By: Brendan Martens (shrift) 2009-09-29 10:24:07 Okay... So this build is based on SVN-trunk-r220792. I'll go back and check my -rc2 if you need that. I'm also going to attach the extenstions.con, its pretty bare. Same behavior here as previously with -rc2. I can re run any of the builds that you want/need. By: Leif Madsen (lmadsen) 2009-09-29 10:27:31 Awesome, thanks for doing that. I think that is enough information for now. By: Matthew Nicholson (mnicholson) 2009-09-29 10:50:24 I labbed this up and tested with 1.6.2 rev220725.  Everything worked fine with 2 and 3 channels. I did notice that there was no audio if the channels were not answered before entering the conference.  In your debug logs, it appears that your channels are not being answered before entering the conference.  I don't know if this is a bug, or if it is how app_confbridge is supposed to work. By: Brendan Martens (shrift) 2009-09-29 12:14:05 That is interesting, indeed. I'll check my config to see if that would explain my issue. By: Brendan Martens (shrift) 2009-09-29 12:16:32 Brilliant! This has fixed the problem for me. Thanks for the help guys, I hope I haven't wasted anyone's time with this. By: Brendan Martens (shrift) 2009-09-29 13:32:42 Ok, I think I've got this figured out now, or at least better... After adding the Answer() in front of the ConfBridge() command that seemed to make things work better. Then I restored my old dialplan and started having trouble again. I verified there was an Answer() in all places, then compared how I was calling ConfBridge(), it appears that if you add the "s" option to ConfBridge(), you get no voice for the endpoint that was connected to the bridge using ConfBridge() with "s". This appears to be true for all versions. For reference the s option is: "Present menu (user or admin) when '*' is received                (send to menu)." Removing the Answer() from in front of ConfBridge causes -rc2 to have no audio in any direction, as I had experienced earlier, however, removing the Answer() in -rc1 causes only the announcements to work, but leave all other audio non functional. In -rc1 and -rc2, without the "s" option, and a proper Answer() preceeding teh ConfBridge() command, everything works as expected (except the bug with "s"). It looks to *me* that this is NOT a regression. The behavior in -rc2 is more consistent (not allowing any audio, announcements or voice, through with out an Answer() in front of ConfBridge()). But this is definitely confusing coming from -rc1. I guess thats why they are called betas and release candidates. : ) By: Matthew Nicholson (mnicholson) 2009-09-29 14:19:31 So basically the "s" option is broken? By: Brendan Martens (shrift) 2009-09-29 14:27:09 Yes, that is how it appears to me. By: Matthew Nicholson (mnicholson) 2009-09-29 14:32:20 Heh, the 's' option works fine, except contrary to the documentation, it sets the 'start muted' flag (just like the 'm' option).  I will look into this. :) By: Matthew Nicholson (mnicholson) 2009-09-29 14:41:49 Conversely the 'm' option does what the 's' option is documented to do.  I will commit a fix shortly. By: Brendan Martens (shrift) 2009-09-29 14:49:05 Ah ha, that makes sense. I had been confused about the 'm' option, as it didn't ever seem to mute anything. I just assumed it was somehow useful to be able to mute the user before anyone connected for some arcane call processing reason.... By: Digium Subversion (svnbot) 2009-09-29 14:51:44 Repository: asterisk Revision: 220904 U   trunk/apps/app_confbridge.c ------------------------------------------------------------------------ r220904 | mnicholson | 2009-09-29 14:51:43 -0500 (Tue, 29 Sep 2009) | 5 lines Fix options 'm' and 's'. They were swapped in the code.  Also document the fact that app_confbridge does not automatically answer the channel. (closes issue ASTERISK-14888) Reported by: shrift ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=220904 By: Digium Subversion (svnbot) 2009-09-29 14:52:32 Repository: asterisk Revision: 220905 _U  branches/1.6.2/ U   branches/1.6.2/apps/app_confbridge.c ------------------------------------------------------------------------ r220905 | mnicholson | 2009-09-29 14:52:31 -0500 (Tue, 29 Sep 2009) | 12 lines Merged revisions 220904 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........  r220904 | mnicholson | 2009-09-29 14:49:02 -0500 (Tue, 29 Sep 2009) | 5 lines    Fix options 'm' and 's'. They were swapped in the code.  Also document the fact that app_confbridge does not automatically answer the channel.    (closes issue ASTERISK-14888)  Reported by: shrift ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=220905