Summary:ASTERISK-11257: Wrong behaviour using "d" and "D" options in MeetMe(confno,d/D,pin)
Reporter:Iñaki Baz Castillo (ibc)Labels:
Date Opened:2008-01-17 16:34:53.000-0600Date Closed:2011-06-07 14:07:47
Versions:Frequency of
Description:The doc says:
    'd' -- dynamically add conference
    'D' -- dynamically add conference, prompting for a PIN

But try this:

exten => 1,1,MeetMe(1,D,1234)
exten => 2,1,MeetMe(2,D)
exten => 3,1,MeetMe(3,d,1234)
exten => 4,1,MeetMe(4,d)

And call to each one:

 1: It doesn't ask for pin -> ¿?¿
 2: It asks for pin -> OK
 3: It doesn't ask for pin -> ¿?¿
 4: It doesn't ask for pin -> OK

So cases 1 and 3 are unexpected. IMHO they should be:

 1: It asks for pin (1234)
 2: It asks for pin (user provided)
 3: It asks for pin (1234)
 4: It doesn't ask for pin

Yes, cases 1 and 3 are the same. I think that "D" options should ask for user provided pin just in case pin is not defined in "MeetMe()". About case 3 I'm not sure of what should be the behaviour.

But in conclusion, for now is not possible to create a dynamic conference with fixed pin (not user provided when creating the conference).
Comments:By: Iñaki Baz Castillo (ibc) 2008-01-17 17:22:04.000-0600

Of course, the mos buggy case is 1:
 exten => 1,1,MeetMe(1,D,1234)

because we set "D" option (to ask for PIN) and we set a fixed PIN (1234) but in fact it doesn't ask for PIN  !!¿?¿

By: Mark Michelson (mmichelson) 2008-01-17 17:37:04.000-0600

I'm not really an authority on MeetMe, but I think you are misinterpreting the d and D options.

When the first person calls into a MeetMe, since the conference is created then, it will set a PIN by either using what is provided in the dialplan or by asking for one (note that if you use the d option and provide a PIN in the dialplan it is silently ignored). Now that a PIN has been set, when subsequent callers enter, that's when it will either ask for a PIN (D option) or not ask for one (d option). Try making additional calls into the MeetMe after the first caller and see if the behavior seems correct.

Edit: I shouldn't place fault on you for misinterpreting the option if that is the case, as the documentation is not very clear at all. Even if it turns out that it was a misinterpretation on your part, I think the documentation should be updated to clear things up.

By: Iñaki Baz Castillo (ibc) 2008-01-17 18:03:46.000-0600

I understand what you mean, but anyway I repeat that when using:
 exten => 1,1,MeetMe(confno,D,pin)
then the pin is not asked for the first user.

This makes no sense since "D" options forces a user provider pin, and Meetme(XX,XX,pin) forces a fixed pin. So, why pin is not asked?

By: Tilghman Lesher (tilghman) 2008-01-17 18:52:52.000-0600

It's not that it necessarily asks for a pin, but rather that it FORCES the conference to have a pin.

By: Iñaki Baz Castillo (ibc) 2008-01-18 02:42:15.000-0600

> It's not that it necessarily asks for a pin, but rather that it FORCES the
> conference to have a pin.

Sorry but I don't understand what you mean.
The fact is that "exten => 1,1,MeetMe(1,D,1234)" doesn't ask for PIN. Do you say htis is the expected behaviour?

By: Tilghman Lesher (tilghman) 2008-01-18 08:01:14.000-0600

Yes, that's precisely the way it was written.

By: Iñaki Baz Castillo (ibc) 2008-01-19 08:28:12.000-0600

Ok, but it makes no sense for me:

 1,1,MeetMe(1, ,1234)  ->  Asks for pin
 1,1,MeetMe(1,D)       ->  Asks for pin
 1,1,MeetMe(1,D,1234)  ->  Doesn't ask for pin  ¿?¿?¿

By: Tilghman Lesher (tilghman) 2008-02-11 13:06:29.000-0600

I understand that you misunderstood the way that it's written; but this is still not a bug.

By: Iñaki Baz Castillo (ibc) 2008-02-12 02:48:42.000-0600

> I understand that you misunderstood the way that it's written; but this
> is still not a bug.

So, in conclusion, this is not a bug because it "is the way it's written". Maybe you could realize that ANY bug is a bug because "the way that it's written".

If I code:
 if (value == "1")
   echo "value is 0";
then there is a bug, even if "it is the way it's written". ;)

What I ask is: does the written code do the expected behaviour? Obviously not -> so there is a bug. Please, don't tell me again that the code does that, let's speak about the expected and logic behaviour.


By: Tilghman Lesher (tilghman) 2008-02-12 09:42:05.000-0600

I wrote the damn feature, and it's the way that I want it.  If you feel differently, you're welcome to take it up on the mailing lists.