Kick Dynamic MeetMe

I’m trying to fix a bug with our paging script. Right now, it works fine if the person is not on a call. But if a user is on a call, and a page occurs, they will still be in the dynamic meetme conference AFTER the originator has hungup.

In the CLI, I can CLI>meetme and determine the conference #. What I want to do is add a section into the script like so…

(pseudo code)

exten => s,n,Wait(10)
exten => s,n,MeetMe(${DynamicConference#},K) ;kick all users from the conference created by the page command
exten => s,n,Hangup

If I can do this it will destroy the call that is showing up on people’s phones after the page has completed.

…Is there just some way I can force the Page() command to use a pre-defined conference room #? This dynamic conference room crap is killing me…

there was a page script on voip-info which first checked to make sure each channel in the page group was available… that might help?

Also do the conference rooms stick around for a long time? Theoretically it should be destroyed as soon as the user who called it leaves, but in practice I find it can take up to about a minute for the BLF lights to go out in some cases…

One of the problems with Page() is that everyone in the meetme conference bridge is listed as the actual user who started the conference.

For example, if you use:

Page(SIP/xxx&SIP/xxx…etc)

You will create a dynamic meetme

If you then go to the Asterisk CLI> and type:

meetme

You will see the dynamic conference #

If you (in the CLI>) type:

meetme list [dynamic conference #]

Every user in the conference is listed as the originating caller…

Which is, in my opinion, one of the problems with the command. If a SIP phone is currently in use when you issue a Page() cmd, even if the originating caller hangs up, the user who is on their phone will get the Page after they finish their current call.

I’ve tested it pretty heavily. If we could just do one of the following:

  1. Have the ZAP-pseudo destroy the conference ASAP
    or
  2. Be able to specify the Page() into a static conference room
    or
  3. Have the Page() cmd use the MeetMe option which allows for “# to exit” which if the originating caller used it would destroy the conference
    or
  4. Figure a way to load the dynamic conference # into a variable and then issue a CLI>meetme kick [dynamic conf #] 1 (would kick user one, and destroy the conference)

Seems so silly that to get basic paging we have to do this…

Maybe I’m missing the boat, but I’ve tried using a mix and match of Dial(), MeetMe() and other things like Chanisavail()…sigh.

but if its working correctly, only the user who ACTUALLY started the page is Marked, so it will be destroyed shortly after he leaves…

Here’s an example of what I’m talking about, this is straight from my CLI.


  == Spawn extension (from-inside, h, 1) exited non-zero on 'SIP/214-b6425ee0'
    -- Executing Macro("SIP/214-b6425ee0", "tl-check-voicemail") in new stack
    -- Executing Answer("SIP/214-b6425ee0", "") in new stack
    -- Executing Wait("SIP/214-b6425ee0", "1") in new stack
    -- Executing Playback("SIP/214-b6425ee0", "voice-mail-system") in new stack
    -- Playing 'voice-mail-system' (language 'en')
    -- Executing Wait("SIP/214-b6425ee0", "1") in new stack
    -- Executing GotoIf("SIP/214-b6425ee0", "1?channel") in new stack
    -- Goto (macro-tl-check-voicemail,s,9)
    -- Executing Set("SIP/214-b6425ee0", "MY_CHAN=214-b6425ee0") in new stack
    -- Executing Set("SIP/214-b6425ee0", "MYEXTENSION=214") in new stack
    -- Executing NoOp("SIP/214-b6425ee0", "214") in new stack
    -- Executing VoiceMailMain("SIP/214-b6425ee0", "214@default") in new stack
    -- Playing 'vm-password' (language 'en')
    -- Executing Macro("SIP/203-b64232c0", "sel-paging|SIP/214&SIP/218|q") in new stack
    -- Executing SIPAddHeader("SIP/203-b64232c0", "Alert-Info: Answer") in new stack
    -- Executing Page("SIP/203-b64232c0", "SIP/214&SIP/218|q") in new stack
    -- Created MeetMe conference 1023 for conference '882029189d'
    -- Launching MeetMe(882029189d|mqxdw) on SIP/218-08204f68
  == Spawn extension (macro-sel-paging, s, 2) exited non-zero on 'SIP/203-b64232c0' in macro 'sel-paging'
  == Spawn extension (macro-sel-paging, s, 2) exited non-zero on 'SIP/203-b64232c0'
    -- Hungup 'Zap/pseudo-593409797'
    -- Playing 'vm-password' (language 'en')
    -- Executing Hangup("SIP/214-b6425ee0", "") in new stack
  == Spawn extension (from-inside, h, 1) exited non-zero on 'SIP/214-b6425ee0'
    -- Launching MeetMe(882029189d|mqxdw) on SIP/214-0822b8c0
    -- Created MeetMe conference 1023 for conference '882029189d'
    -- Hungup 'Zap/pseudo-117375504'

As you can see, if user 214 is doing something like checking the VM, and a Page is initiated, AFTER SIP/214 hangsup from VM, they are dumped into the MeetMe conference, even though the originator is already gone. The MeetMe conference will stay on indefinitly, and not timeout (I’ve already watched it stay active for over 4 hours.

im guessing the problem is something like this:

you set the header and Page() the people
those who are on the phone, the Pcom phone does not answer but lets it keep ringing
then when they hang up, it answers and puts them into the meetme conference again.

This could definately be solved with a tweak to the Page() app, either a. dont join paged members with a create dynamic clag, b. after marked user hangs up forcefully kill the meetme room, c. after paging user hangs up make sure all spawned calls are killed…

for you what i’d suggest is first use ChanIsAvail() to make sure that all the extens in your page group are available, and remove the ones that arent before you call Page(). As I recall, there was a script on voip-info that would do this…

from ftp.digium.com/pub/asterisk/ChangeLog-1.2.12.1

2006-09-11 21:47 +0000 [r42697-42783] Tilghman Lesher tilghman@mail.jeffandtilghman.com

* apps/app_meetme.c, apps/app_page.c: When paging, only wait 5
  seconds for the marked user to enter the conference. After that,
  assume the paging already completed by the time the channel
  entered the conference and drop back out. (Issue 7275)

perhaps this fixes your problem? it would be in 1.2.12.1…