Summary:ASTERISK-08813: user pin doesnt work like expected
Reporter:Clod Patry (junky)Labels:
Date Opened:2007-02-15 00:18:05.000-0600Date Closed:2007-06-30 09:20:00
Versions:Frequency of
Description:in SVN-branch-1.4-r51087,
if you change the conference user pin for a new value and you module reload app_meetme.so, that new password will be refused until a restart occurs.


When you reload a module, you considerate all changes has been successfully overwritten.

This is with non-realtime (meetme.conf)

I've tried changing the call with dynamic for build_conf, but once the conf has been created, it will keep that old pin.

Imagine this scenario, user 1 joined the conf with pass 123, you change the value to 456 in meetme.conf, you relaod the conf, the password will still be 123 instead of 456.

Is clearing all the flags in load_config could be a solution, like after a restart?

Patch ASTERISK-5100 was exactly to solve this kind of issues.
Comments:By: Clod Patry (junky) 2007-02-15 00:25:28.000-0600

I also noticed, conf isnt destroyed right after the last participant left:
2006 isnt destroyed, while 200635353 doesnt exists at all (even if the .conf)

clea*CLI> meetme list 2006
0 users in that conference.
clea*CLI> meetme list 200635353
No such conference: 200635353.
clea*CLI> exit

If we could make sure the conf is really destroyed after the last participant left, that will simplify a lot the changes of any passwords too.

By: Clod Patry (junky) 2007-02-16 12:06:55.000-0600

just make sure we really destroy the conference, even there's a pin set could be the shortest way?
What's your feeling about it?

By: Russell Bryant (russell) 2007-02-16 13:18:24.000-0600

Well, conferences not getting properly destroyed is a different bug, really.

Also, the conferences in meetme.conf don't get parsed on reload.  meetme.conf is parsed when the conference is created.  So, the solution is to check meetme.conf every time someone calls in, just in case the pin has been changed.

I'll work on a patch to fix the pin problem ...

By: Tilghman Lesher (tilghman) 2007-02-16 14:04:07.000-0600

This isn't really a pin problem; this is a conference not getting destroyed problem.  The pin is only read when the conference is created, which is correct.  A conference which is already in existence should not be disturbed by a reload.

By: Clod Patry (junky) 2007-02-16 14:16:08.000-0600

corydon: we'll figure out why conf isnt destroyed if it has a pin, since the conf is never destroyed, the new pin is never considerate.
Do you think changing the cnf->pin to a new value at any point could hurt something? Since there's no read to that value, once the 1st user joined the conf.  I mean, is this safe to change that value?

By: Russell Bryant (russell) 2007-02-16 15:15:07.000-0600

This has been fixed in revisions 54955, 54969, and 54970.

You still may see conferences sitting around with nobody in them, but pin changes in the config should still take effect.  The conferences still sitting around is a different issue.  I'll look into it, though.

Feel free to open a new issue for that, if you'd like.

By: Russell Bryant (russell) 2007-02-16 16:42:17.000-0600

Ok, so I changed my mind.  I agree that the real issue here is just the conference that is still sitting around.  I originally thought that my change to re-read meetme.conf for pin changes would be a good idea in case it is changed during a conference, but I don't anymore.

I'm going to revert my changes that did that and then we should just figure out why the conference isn't going away.  Then, we should just accept that once a conference is created, the pin can not change until it goes away and is created again.

By: Russell Bryant (russell) 2007-02-16 16:56:34.000-0600

I can't seem to recreate a situation where a conference stays around when it shouldn't.  If you can come up with a way to make this happen, that would be very helpful.

By: Clod Patry (junky) 2007-02-16 19:43:39.000-0600

what you cant reproduce exactly?
clea*CLI> meetme list 2007
0 users in that conference.

this is my setup.
ive some confs in meetme, some with pin and some with pin and admin too.

im calling all my meetme conf via AGI:
core_ast_send("EXEC MeetMe $conf|pMT\n");

By: Russell Bryant (russell) 2007-02-20 19:05:11.000-0600

This should be fixed in revisions 55758 and 55762 in 1.4 and trunk.  Please re-open this bug if you still have a problem.