Summary:	ASTERISK-17039: meetme "a" option not working properly with realtime
Reporter:	Sebastien Peterson (morchea)	Labels:
Date Opened:	2010-11-28 17:34:39.000-0600	Date Closed:	2012-02-10 16:31:12.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_meetme
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I am using meetme app with realtime. Since I have been using realtime for meetme, the meetme app option "a" (admin user flag) does not work properly anymore. I could find an easy example where adding a "Playback" in the dialplan before the "Meetme" command fails the meetme user to be flagged as (Admin). In more complex dialplans, different combinations seems to influence the feature to work or not. When not using Realtime, meetme Application never fails this feature for my same diaplan. ****** ADDITIONAL INFORMATION ****** I can reproduce the following scenario that fails tagging the meetme user with the (Admin) flag. Bad scenario. ------------- extensions.conf: **************** exten => 802,1,Playback(welcome) exten => 802,2,MeetMe(103,a,12345) asterisk4*CLI>  == Spawn extension (local, 802, 2) exited non-zero on 'SIP/sip_phone_202-00000055'  == Using SIP RTP CoS mark 5    -- Executing [802@local:1] Playback("SIP/sip_phone_202-00000056", "welcome1") in new stack    -- <SIP/sip_phone_202-00000056> Playing 'welcome1.slin' (language 'en')    -- Executing [802@local:2] MeetMe("SIP/sip_phone_202-00000056", "103,a,12345") in new stack  == Parsing '/home/speterson/open4ip/asterisk/etc//meetme.conf':   == Found    -- Created MeetMe conference 1023 for conference '103'       > Starting recording of MeetMe Conference 103 into file ..    -- <SIP/sip_phone_202-00000056> Playing 'conf-onlyperson.ulaw' (language 'en') asterisk4*CLI> meetme list 103 User #: 01 sip_phone_20 sip_phone_202        Channel: SIP/sip_phone_202-00000056     (unmonitored) 00:00:04 1 users in that conference. You see that meetme user is not tagged with (Admin) Good scenario. -------------- If I change to this config: extensions.conf: **************** exten => 802,1,MeetMe(103,a,12345) asterisk4*CLI>  == Using SIP RTP CoS mark 5    -- Executing [802@local:1] MeetMe("SIP/sip_phone_202-00000058", "103,a,12345") in new stack  == Parsing '/home/speterson/open4ip/asterisk/etc//meetme.conf':   == Found    -- Created MeetMe conference 1023 for conference '103'       > Starting recording of MeetMe Conference 103 into file ..    -- <SIP/sip_phone_202-00000058> Playing 'conf-onlyperson.ulaw' (language 'en') asterisk4*CLI> meetme list 103 User #: 01 sip_phone_20 sip_phone_202        Channel: SIP/sip_phone_202-00000058 (Admin)    (unmonitored) 00:00:04 1 users in that conference. And the meetme user is properly tagged as (Admin) Please have a look at this, I am dying for realtime here, but does not work for now... Cheers, Morchea.
Comments:	By: JoshE (n8ideas) 2011-10-17 01:39:09.209-0500 I can reproduce this issue on Asterisk 1.8.7 as well.  It turns out that if you set the "P" option, forcing PIN entry to happen in app_meetme, the problem (sorta) goes away.  You at least get market users entered properly.  There may be something else at work here.  I'm not positive what the interplay between the realtime database column "adminopts" and what is entered in the dialplan manually, but there's definitely something funky here. By: JoshE (n8ideas) 2011-10-17 01:52:06.546-0500 Here's a little more info.  It appears that the issue has to do with pre-entering a pin in the application's 3rd argument.  If you let the module itself select the PIN, it will correctly identify the admin user.  In addition, it looks like entering arg2 options for MeetMe actually doesn't do much of anything.  When the DB is available, it is the authoritative source of values. Still definitely a bug in here somewhere, but it can be worked around by letting the module handle the PIN entry. By: Mark Michelson (mmichelson) 2012-02-10 16:31:06.530-0600 I've had a look at this, and I have reproduced the non-honoring of the 'a' setting when using realtime meetme. I reproduced the problem on 1.6.2.14, as originally reported, and I have confirmed that in the tip of the 1.8 branch, this no longer occurs. @JoshE: Your problem doesn't quite sound the same as the one reported by Sebastien, and if it is and I misunderstood you, I believe it to be fixed. Please try with the latest 1.8 release and see if you're still experiencing the problem. If so, please open another issue and describe what is happening.