[asterisk-dev] [Code Review] 2550: res_parking: Dynamic Parking Lots

[jrose]

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



/team/group/bridge_construction/CHANGES
<https://reviewboard.asterisk.org/r/2550/#comment16951>

    This is written in anticipation of the extensions being generated.



/team/group/bridge_construction/res/parking/parking_applications.c
<https://reviewboard.asterisk.org/r/2550/#comment16954>

    Put this back in here since the application can play messages to the entering channel on failure and if it isn't answered, we won't hear them.



/team/group/bridge_construction/res/parking/parking_bridge.c
<https://reviewboard.asterisk.org/r/2550/#comment16955>

    This was actually totally unnecessary and was causing a nasty bug because we never really took this reference in the first place.  It was also just plain wrong.



/team/group/bridge_construction/res/parking/parking_bridge.c
<https://reviewboard.asterisk.org/r/2550/#comment16956>

    This is unrelated to the issue, but adding back in the local channel swapping made us not hear music on hold on the channel that got swapped into the parking lot. Setting the roles back up gets around that, but I still need to deal with the ringing option to the Park application here.



/team/group/bridge_construction/res/res_parking.c
<https://reviewboard.asterisk.org/r/2550/#comment16952>

    Oops, left out NULL return here.



/team/group/bridge_construction/res/res_parking.c
<https://reviewboard.asterisk.org/r/2550/#comment16953>

    This isn't necessary. It's from before I added the dynamic argument to parking_lot_build_or_update.


- jrose


On May 17, 2013, 10:13 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2550/
> -----------------------------------------------------------
> 
> (Updated May 17, 2013, 10:13 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and rmudgett.
> 
> 
> Bugs: ASTERISK-21644
>     https://issues.asterisk.org/jira/browse/ASTERISK-21644
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Dynamic Parking Lots. Parking lots that are made based on other parking lots as well as a combination of some variables. They get a little bit of overlap extension checking that they do before actually trying to register any extensions...
> 
> For the most part, they function like normal parking lots. The exception is that they get broken down if they ever become empty. In that sense, they behave as though they have already been disabled, it's just that you can keep parking to them while they are still alive.
> 
> Some of the stuff in this review references functionality that is going to be provided by the extensions registration update once that is finished.
> 
> 
> Diffs
> -----
> 
>   /team/group/bridge_construction/CHANGES 389006 
>   /team/group/bridge_construction/res/parking/parking_applications.c 389006 
>   /team/group/bridge_construction/res/parking/parking_bridge.c 389006 
>   /team/group/bridge_construction/res/parking/parking_ui.c 389006 
>   /team/group/bridge_construction/res/parking/res_parking.h 389006 
>   /team/group/bridge_construction/res/res_parking.c 389006 
> 
> Diff: https://reviewboard.asterisk.org/r/2550/diff/
> 
> 
> Testing
> -------
> 
> Created dynamic parking lots with a number of different variables, made sure I could keep parking additional people to them as long as they didn't break down, made sure they were destroyed when they became empty, made sure they didn't leak memory in any obvious ways (tracked by res_parking.c, parking_bridge.c, and parking_controller.c) made sure they were visible in the UI as long as they were alive.
> 
> 
> Thanks,
> 
> jrose
> 
>

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