[asterisk-dev] [Code Review] MeetMe requests a PIN twice in some circumstances

[David Vossel]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1305/#review3861
-----------------------------------------------------------



trunk/apps/app_meetme.c
<https://reviewboard.asterisk.org/r/1305/#comment7685>

    !ast_strlen_zero(cnf->pin) || (!ast_strlen_zero(cnf->pinadmin) && ast_test_flag64(&confflags, CONFFLAG_ADMIN))
    
    This logic looks like it could result in prompting for an admin's pin even if we already have an admin pin just because the cnf->pin is empty.  Is that the expected result?
    
    To be honest this if statement is so complex I'm having difficulty following all the different paths it can take.  Can we get some sort of comment above this statement describing the different conditions?


- David


On July 7, 2011, 9 a.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1305/
> -----------------------------------------------------------
> 
> (Updated July 7, 2011, 9 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> If a call to MeetMe includes both the dynamic(D) and always request PIN(P) options, MeetMe will ask for the PIN two times: once for creating the conference and once for entering the conference.  This behavior was introduced in rev 311616 when adding the CONFFLAG_ALWAYSPROMPT option to the logic branch controlling PIN entry for joining a conference.
> 
> 
> This addresses bug AST-601.
>     https://issues.asterisk.org/jira/browse/AST-601
> 
> 
> Diffs
> -----
> 
>   trunk/apps/app_meetme.c 325090 
> 
> Diff: https://reviewboard.asterisk.org/r/1305/diff
> 
> 
> Testing
> -------
> 
> Tested with one and two SIP conference users with and without specified conference numbers.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110712/63fab00f/attachment-0001.htm>