[asterisk-dev] [Code Review] 2971: app_confbridge: Allow dynamically created menus via CONFBRIDGE function

[Mark Michelson]

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


Most issues I ran across in my review are memory leaks in off-nominal paths.

I noted a couple of usability concerns while looking over this review.

1) Under this implementation If a user has menu options set via the CONFBRIDGE() function, then when that user enters a ConfBridge(), any specified menu profile name passed as an application argument is ignored in favor of the menu options that were set via CONFBRIDGE().
2) If a user who has set menu options using CONFBRIDGE() is placed into one ConfBridge(), leaves, and enters a second ConfBridge(), the menu options get applied to both invocations of the application.

The two kind of relate to each other because the essential problem at the moment is that once a user is given menu options via CONFBRIDGE(), the privilege cannot be revoked. One way around this would be to only apply the CONFBRIDGE()-created menu options if no menu profile name is provided to ConfBridge(). This way, you can interpret an explicit menu name to mean that the user wants that menu, as configured, to be the menu to use for ConfBridge. A second way would be to require a special name to be passed to ConfBridge() in order to use the menu options set via CONFBRIDGE(). No provided name would use the default menu profile. A third way would be to remove the menu options from the channel's datastore when the channel is removed from a ConfBridge(). This would mean that any user-specific menu options would need to be re-applied in the dialplan prior to a second invocation of ConfBridge(). This third option would only solve problem number 2 and not problem number 1, though.

I'm partial to the first suggestion, myself. What do you think?


/trunk/apps/confbridge/conf_config_parser.c
<https://reviewboard.asterisk.org/r/2971/#comment19332>

    Call conf_bridge_profile_destroy(&bdata->b_profile) in this failure case. Otherwise the bdata->b_profile.sounds are leaked.



/trunk/apps/confbridge/conf_config_parser.c
<https://reviewboard.asterisk.org/r/2971/#comment19333>

    You'll need to be sure to free cpy as well as all the elements in its linked list in this case. Currently it's all leaked.



/trunk/apps/confbridge/conf_config_parser.c
<https://reviewboard.asterisk.org/r/2971/#comment19335>

    To prevent you from having to unlock the menu at each exit point of this function, you could instead use a SCOPED_AO2LOCK() here.



/trunk/apps/confbridge/conf_config_parser.c
<https://reviewboard.asterisk.org/r/2971/#comment19334>

    Calling ast_free(pvt) here isn't enough to ensure that memory is properly cleaned up. The list items that were copied onto &pvt->menu_entry need to be freed as well.
    
    (FYI, I  recognize this wasn't your doing, but I noticed it anyway since I was in the area)


- Mark Michelson


On Oct. 31, 2013, 4:14 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2971/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2013, 4:14 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan, Mark Michelson, and rmudgett.
> 
> 
> Bugs: ASTERISK-22760
>     https://issues.asterisk.org/jira/browse/ASTERISK-22760
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Adds the ability to dynamically create menus using the CONFBRIDGE dialplan function. This includes the ability to use the existing options as well as to specify templates with the 'template' option.
> 
> I suppose it's worth mentioning that there is one minor bit of awkwardness. Both the channel datastore and the conference user will end up with an allocation of the menu. This is probably for the best for a couple reasons though. For instance, the CONFBRIDGE function can modify the contents of the datastore allocated menu while the user is still in the conference if it is set via AMI. We probably don't want the menu to be modified in place during this time (even if it would be cool to be able to edit a menu while the conference is in progress).
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/confbridge/include/confbridge.h 402126 
>   /trunk/apps/confbridge/conf_config_parser.c 402126 
>   /trunk/apps/app_confbridge.c 402126 
>   /trunk/CHANGES 402126 
> 
> Diff: https://reviewboard.asterisk.org/r/2971/diff/
> 
> 
> Testing
> -------
> 
> The following extensions were tested for successful entry with the expected options as well as not having any obvious memory leaks:
> 
> exten => 6060,1,NoOp
> exten => 6060,n,Set(CONFBRIDGE(menu,*)=playback_and_continue(conf-usermenu))
> exten => 6060,n,Set(CONFBRIDGE(menu,0)=leave_conference)
> exten => 6060,n,Set(CONFBRIDGE(menu,*9)=increase_volume)
> exten => 6060,n,Set(CONFBRIDGE(menu,*7)=decrease_volume)
> exten => 6060,n,Answer()
> exten => 6060,n,Confbridge(this_conference)
> 
> exten => 6061,1,Answer()
> exten => 6061,n,Confbridge(this_conference)
> 
> exten => 6062,1,Answer()
> exten => 6062,n,Confbridge(this_conference,,,sample_user_menu)
> 
> exten => 6063,1,NoOp
> exten => 6063,n,Set(CONFBRIDGE(menu,template)=sample_user_menu)
> exten => 6063,n,Set(CONFBRIDGE(menu,0)=leave_conference)
> exten => 6063,n,Answer()
> exten => 6063,n,Confbridge(this_conference)
> 
> With the following sample_user_menu configuration in confbridge.conf
> 
> [sample_user_menu]
> type=menu
> *=playback_and_continue(conf-usermenu)
> *1=toggle_mute
> 1=toggle_mute
> *4=decrease_listening_volume
> 4=decrease_listening_volume
> *6=increase_listening_volume
> 6=increase_listening_volume
> *7=decrease_talking_volume
> 7=decrease_talking_volume
> *8=leave_conference
> 8=leave_conference
> *9=increase_talking_volume
> 9=increase_talking_volume
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131031/858c6635/attachment-0001.html>