Posted: Tue May 12, 2009 1:10 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
I am making some custom changes to app_meetme, which require me to test
whether it has exited the conf_run loop due to a manager Redirect or to
an actual hangup. I want to perform different actions if the caller has
just been redirected to another extension, as opposed to exiting for
any other reason (hung up, timeout, kicked, etc).
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.
Posted: Tue May 12, 2009 1:31 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
Tony Mountifield wrote:
Quote:
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().
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.
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).
--
Russell Bryant
Digium, Inc. | Senior Software Engineer, Open Source Team Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Tue May 12, 2009 1:31 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
On Tue, 12 May 2009, Tony Mountifield wrote:
Quote:
I am making some custom changes to app_meetme, which require me to test
whether it has exited the conf_run loop due to a manager Redirect or to
an actual hangup. I want to perform different actions if the caller has
just been redirected to another extension, as opposed to exiting for
any other reason (hung up, timeout, kicked, etc).
How are you planning to return the reason to the dialplan?
I have a need to distinguish users that were kicked.
Thanks in advance,
------------------------------------------------------------------------
Steve Edwards sedwards@sedwards.com Voice: +1-760-468-3867 PST
Newline Fax: +1-760-731-3000
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Tue May 12, 2009 1:36 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
On Tue, May 12, 2009 at 9:56 AM, Tony Mountifield
<tony@softins.clara.co.uk> wrote:
Quote:
Is there anything else to be aware of? Thanks for the sanity check.
Hopefully you're better at making changes to meetme than I was. My
changes weren't safe and I ended up clogging up my system with threads
(channels) that didn't complete. In general, I'd say:
1) make sure that you've checked trunk and that you're changes aren't
already part of a future release
2) make sure that what you're doing in your code changes can't be
performed in an equally valid way outside of meetme. In my case I was
trying to modify the way recording is performed on conferences, but it
was better to instead manipulate MixMonitor() from the dialplan. I
just didn't know that at the time.
3) once you have your changes in, try throwing a few hundred fake
calls at the system that exercise the code you changed, and make sure
you're not hanging channels like I did when I made code mistakes.
If you finish your changes and they don't break things, file a bug
reporting what you did so it can be part of a future release.
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Tue May 12, 2009 3:23 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
In article <4A09860B.5030205@digium.com>,
Russell Bryant <russell@digium.com> wrote:
Quote:
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.
Quote:
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.
Quote:
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!)
Posted: Tue May 12, 2009 3:25 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
In article <Pine.LNX.4.64.0905120721060.32237@fs.sedwards.com>,
Steve Edwards <asterisk.org@sedwards.com> wrote:
Quote:
On Tue, 12 May 2009, Tony Mountifield wrote:
> I am making some custom changes to app_meetme, which require me to test
> whether it has exited the conf_run loop due to a manager Redirect or to
> an actual hangup. I want to perform different actions if the caller has
> just been redirected to another extension, as opposed to exiting for
> any other reason (hung up, timeout, kicked, etc).
How are you planning to return the reason to the dialplan?
In my case, there is no need, because if the channel is redirected, it
will not return to the next dialplan statement.
Quote:
I have a need to distinguish users that were kicked.
That should be easy. Find the part of the conference loop that tests
for the user being kicked and does a break:
if (user->adminflags & ADMINFLAG_KICKME) {
Then insert the following line just before the break.
Posted: Tue May 12, 2009 3:29 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
In article <3de056a30905120724j6de17e3ck82ce0da099ae2bc5@mail.gmail.com>,
David Backeberg <dbackeberg@gmail.com> wrote:
Quote:
On Tue, May 12, 2009 at 9:56 AM, Tony Mountifield
<tony@softins.clara.co.uk> wrote:
> Is there anything else to be aware of? Thanks for the sanity check.
Hopefully you're better at making changes to meetme than I was.
Hopefully :-)... MeetMe is the part of Asterisk that I have customised
the most over the last five years. Some of those customisations have
made it into the tree and some haven't.
Quote:
My changes weren't safe and I ended up clogging up my system with
threads (channels) that didn't complete. In general, I'd say:
1) make sure that you've checked trunk and that you're changes aren't
already part of a future release
2) make sure that what you're doing in your code changes can't be
performed in an equally valid way outside of meetme. In my case I was
trying to modify the way recording is performed on conferences, but it
was better to instead manipulate MixMonitor() from the dialplan. I
just didn't know that at the time.
3) once you have your changes in, try throwing a few hundred fake
calls at the system that exercise the code you changed, and make sure
you're not hanging channels like I did when I made code mistakes.
If you finish your changes and they don't break things, file a bug
reporting what you did so it can be part of a future release.
Thanks for the comments. Sometimes I do submit my changes, but a lot
of the time I'm too many versions behind.
Posted: Tue May 12, 2009 3:43 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
In article <3de056a30905120724j6de17e3ck82ce0da099ae2bc5@mail.gmail.com>,
David Backeberg <dbackeberg@gmail.com> wrote:
Quote:
1) make sure that you've checked trunk and that you're changes aren't
already part of a future release
As far as I could see, there is nothing like this. Perhaps I'll describe
what I'm doing.
My conference app uses the i/I option to allow the caller to record their
name and to announce them to the conference. It also allows an operator
or system manager to pull a participant into a side conference temporarily
and then put them back in the main conference.
At the moment, when they are pulled out, their departure is announced to
the main conference, and when they return, they have to record their name
again. I want to avoid both these things.
What I am planning is this:
1. When the user has recorded their name, the name of the name file is
stored in a channel variable MEETME_NAMEFILE.
2. When the channel leaves the conference, if the caller has really hung
up, the exit announcement is played as normal, the name file deleted and
the MEETME_NAMEFILE variable removed. However, if they have only been
redirected, then the exit announcement is optionally suppressed
(controlled by another option flag) and the name file is not deleted.
3. When the user joins a conference with i/I options, the variable
MEETME_NAMEFILE will be checked, and it will test whether the referenced
name file exists. If it does, then the user will not be prompted to record
their name, the joining announcement will be optionally suppressed, and
the name of the file remembered for when the user hangs up.
I was also planning to add a MeetmeIntro application that would just do
the recording as for the i/I option, and would set MEETME_NAMEFILE and
then return, allowing this prepared namefile to be used later when joining
a conference. This will also need a matching MeetmeCleanup application
that can be called from the h extension to delete any namefile referenced
by MEETME_NAMEFILE.
Any comments from anyone on this approach are welcome!
Posted: Tue May 12, 2009 4:41 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
Tony Mountifield wrote:
Quote:
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!)
I believe there is a 64-bit version of ast_flags.
You could also start using bit fields - "unsigned int myflag:1;".
If all else fails, you can follow the chan_sip example of having
multiple ast_flag instances in a struct, but that gets quite ugly.
--
Russell Bryant
Digium, Inc. | Senior Software Engineer, Open Source Team Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Tue May 12, 2009 8:08 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
In article <4A09B29B.90202@digium.com>,
Russell Bryant <russell@digium.com> wrote:
Quote:
Tony Mountifield wrote:
> 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!)
I believe there is a 64-bit version of ast_flags.
You could also start using bit fields - "unsigned int myflag:1;".
If all else fails, you can follow the chan_sip example of having
multiple ast_flag instances in a struct, but that gets quite ugly.
The problem I have found is that none of the above approaches seems to
be compatible with AST_APP_OPTIONS. chan_sip only uses multiple ast_flag
instances for internal state flags, not for option parsing.
Posted: Tue May 12, 2009 8:28 pm Post subject: [asterisk-dev] app_meetme - distinguish between redirect and
Tony Mountifield wrote:
Quote:
In article <4A09B29B.90202@digium.com>,
Russell Bryant <russell@digium.com> wrote:
> Tony Mountifield wrote:
>> 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!)
> I believe there is a 64-bit version of ast_flags.
>
> You could also start using bit fields - "unsigned int myflag:1;".
>
> If all else fails, you can follow the chan_sip example of having
> multiple ast_flag instances in a struct, but that gets quite ugly.
The problem I have found is that none of the above approaches seems to
be compatible with AST_APP_OPTIONS. chan_sip only uses multiple ast_flag
instances for internal state flags, not for option parsing.
Cheers
Tony
You should take a look at app_dial.c in trunk. For AST_APP_OPTIONS, there is a
function called ast_app_parse_options64 should do what you want. app_dial.c also
may provide you with other insights regarding the use of 64-bit options, flags, etc.
Mark Michelson
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum