[asterisk-dev] [Code Review]: Revamp app_confbridge into something resembling a state machine

[Terry Wilson]

> On Aug. 23, 2012, 5:43 p.m., jrose wrote:
> > Overall I think this is a very sensible way to solve this problem. One thing that might be worth considering though is that you are handling state transition behavior as part of the events that take place when you are going to change state, and it might eventually be the case that there are multiple ways to perform the same transition. I think transition behavior as well as the state change itself should be put into a separate function from where the need for a state change is determined. That's something that could be broken out at any time though.

I may be misunderstanding what you are saying, and if I am please correct me.

Transition behavior is determined by A) the conf_change_state function (call the state exit, change the state, call the next state entry) and B) what actually happens in those state exit/entry functions. The behavior in the events handlers isn't transition behavior, it is event-related behavior that may or may not result in a state change. You *can't* separate out the behavior in the event handlers because you need to actually do a certain action, for example,  *every single time* that an unmarked leaves a conference in the MULTI state regardless of whether it leads to a state change.


> On Aug. 23, 2012, 5:43 p.m., jrose wrote:
> > /branches/10/apps/confbridge/include/conf_state.h, line 22
> > <https://reviewboard.asterisk.org/r/2072/diff/5/?file=31082#file31082line22>
> >
> >     I notice none of the states actually sets the exit callback. Got any plans for these? It completes the concept, but I think this is probably going to be unused to the point that it's just a waste of a pointer check that happens during every state transition. The performance concern is irrelevant since the memory involved is negligible and so is checking if a pointer isn't NULL,

Yeah. I assumed that I could use the exit function for things like "when leaving the marked conference state, move all of the waitmarked users into waiting list". But, it turned out that I needed to handle that action in the leave event when the last marked user could be determined to have left because whether or not their were waitmarked users determined where we would transition to next, and transitioning from an exit function would be a big no-no.

I basically kept being surprised that I didn't actually need the exit function for anything and just left it in. I don't mind taking it out if we don't find a use for it through the review process.


- Terry


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


On Aug. 23, 2012, 11:01 a.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2072/
> -----------------------------------------------------------
> 
> (Updated Aug. 23, 2012, 11:01 a.m.)
> 
> 
> Review request for Asterisk Developers and Neil Tallim.
> 
> 
> Summary
> -------
> 
> Thank's to flan's tireless testing, issue reporting, and patches it became clear that app_confbridge had some complex logic and was missing some corner cases. In particular, it didn't handle mixing unmarked and waitmarked users very well and was inconsistent in how MOH and muting was applied.  flan's patches seem to fix the issue, but they highlight how hard the code could be to maintain. In an attempt to make things easier to maintain and to more fully enumerate the various cases that exist, I have attempted to break up the logic into a state machine-like setup.
> 
> This should fix all of the issues in the linked bugs, as well as a couple of other issues. I still need to add some documentation, but I thought I'd give people a chance to look at it test it out, and comment.
> 
> One thing to note is that this solution involves treating waitmarked users without a marked user as essentially outside of the conference. For now, I have the announce_user_count stuff taking into account both the counts for waiting and active users which can lead to things like having a single waiting user followed by an unmarked user and the announcement that "there is one other user in the conference" (because we count the waiting user there) followed by "you are the only user in the conference" (because that prompt plays when you are the only active user) being played to the unmarked user. This is easy to fix, we just need to decide which way to go. Count users who are essentially outside the conference (they can't speak or hear) or not?
> 
> 
> This addresses bugs ASTERISK-19562, ASTERISK-19726 and ASTERISK-20181.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19562
>     https://issues.asterisk.org/jira/browse/ASTERISK-19726
>     https://issues.asterisk.org/jira/browse/ASTERISK-20181
> 
> 
> Diffs
> -----
> 
>   /branches/10/apps/app_confbridge.c 371641 
>   /branches/10/apps/confbridge/conf_state.c PRE-CREATION 
>   /branches/10/apps/confbridge/conf_state_empty.c PRE-CREATION 
>   /branches/10/apps/confbridge/conf_state_inactive.c PRE-CREATION 
>   /branches/10/apps/confbridge/conf_state_marked.c PRE-CREATION 
>   /branches/10/apps/confbridge/conf_state_multi.c PRE-CREATION 
>   /branches/10/apps/confbridge/conf_state_single.c PRE-CREATION 
>   /branches/10/apps/confbridge/conf_state_single_marked.c PRE-CREATION 
>   /branches/10/apps/confbridge/include/conf_state.h PRE-CREATION 
>   /branches/10/apps/confbridge/include/confbridge.h 371641 
> 
> Diff: https://reviewboard.asterisk.org/r/2072/diff
> 
> 
> Testing
> -------
> 
> Lots of calls. Need to do more formalized testing.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120824/100eec7a/attachment.htm>