[asterisk-dev] app_meetme - distinguish between redirect and hangup?

Tony Mountifield tony at softins.clara.co.uk
Tue May 12 11:02:43 CDT 2009


In article <4A09860B.5030205 at digium.com>,
Russell Bryant <russell at digium.com> wrote:
> Tony Mountifield wrote:
> > I wanted to check what the correct way to test this was. I think I need
> > to check that the only softhangup flag set is the asyncgoto one:
> > 
> >     if (chan->_softhangup == AST_SOFTHANGUP_ASYNCGOTO) {
> >     	/* channel was redirected, but not hung up for any other reason */
> >     }
> > 
> > Is there anything else to be aware of? Thanks for the sanity check.
> 
> You're on the right track.  I have a couple of comments:
> 
> 1) You may want to check for AST_SOFTHANGUP_ASYNCGOTO using a bitwise
> and instead of equality, to be consistent with how the value is being
> set it ast_softhangup_nolock().

I did think of a bitwise op first, but concluded that the condition I
wanted was "asyncgoto set, but none of the others set", which is why
I used equality. If any of the other bits is set, I want to process
it as a normal hangup.

> 2) Checking for this value will only work for channel's executing the
> dialplan.  In your case, for channels in MeetMe, that is most likely the
> case, but it's not definite.
>
> For example, you can do an originate with the target being a specific
> application and not an extension.  In that case, the channel will not be
> executing the dialplan.

Yes, in my case, the channel will always be in the dialplan; I never do
an Originate to an app, always to an extension.

> For channels not executing the dialplan ... I honestly don't see a way
> to be able to determine what happened.  It's going to look like a hangup
> (a masquerade will have happened).

Yes, because the Redirect will want to put it in dialplan using AsyncGoto.
For my application, this won't arise.

Thanks for the comments.

One other thing I've stumbled across while doing this is that I have run
out of flag bits for CONFFLAG_XXXX in my version of MeetMe. What is the
best way to overcome this? I tried changing flags to unsigned long long in
ast_flags, but that has had all sorts of knock-on effects and seems too
invasive.

I looked in trunk to see if the latest app_meetme had hit and solved this
problem, but it hadn't (although it now uses all 32 bits!)

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org



More information about the asterisk-dev mailing list