[Home]

Summary:ASTERISK-00505: [patch] New application app_campon
Reporter:pliew (pliew)Labels:
Date Opened:2003-11-10 04:57:33.000-0600Date Closed:2011-06-07 14:04:51
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_campon.c
( 1) campon.conf
( 2) campon.gsm
( 3) Makefile.diff
Description:Allows ability to camp-on a caller with MOH, when the extension is busy. Caller can break out of camp-on by pressing 1 or 2. Drops back onto the dialplan with different priority. This is transferred from the ACD section.

****** ADDITIONAL INFORMATION ******

Sample extensions.conf
[macro-ext]
;
; Standard extension macro:
; ${ARG1} - Technology/Number
;
exten => s,1,Dial(${ARG1},30|tr)
exten => s,2,Voicemail(u${MACRO_EXTEN})
exten => s,102,Campon(${ARG1}) ; phone busy camp the caller on
exten => s,103,Voicemail(b${MACRO_EXTEN}) ; caller decides to leave voicemail by pressing 1
exten => s,203,Directory(Default) ; caller decides to call another extension by pressing 2

You have to record "campon" voice file to instruct the caller ie "extension in busy, press 1 for voicemail, 2 for directory, or hold the line to wait". A repeat voice file "campon-repeat" is used for subsequent instructions every 45 seconds (default). The default MOH used is "default". You can change these by adding to file:

campon.conf
[general]
music => default
recall => 30
reponsetime => 5

I'll upload some demo voice files for "campon.gsm" when I've finished splicing something together
Comments:By: pliew (pliew) 2003-11-10 05:01:28.000-0600

Sorry I've put this into the wrong place - can somebody at digium move it to applications, or close it and I will put it there properly the next time - getting kind of late here in Aus.

By: Mark Spencer (markster) 2003-11-10 11:01:52.000-0600

It seems like this shares a great deal of common code with the queueing system.  Would it not be easier to just register the app under app_queue, so that we don't duplicate as much code?  Also, we'll need a disclaimer.

By: pliew (pliew) 2003-11-10 15:20:34.000-0600

Mark, this was originally a patch to the app_queue code. See bug 464 under ACD. I don't mind which way it goes, leave it to you. Yes, I have sent a disclaimer about 3 weeks ago via snail mail (originally for a patch to chan_sip for incoming limits). I'll fax one in today in case you haven't received it yet. Thanks.

By: tclark (tclark) 2003-11-10 16:25:33.000-0600

can we vote on it here :)
My thoughts are that technically it shares code drived from q's but q's are quite complex & will prolly be more so over time, & this logic will just add bloat
to q that functionaly will have nothing to do with q logic, & will serve to
make the q logic that much more of a maintenance issue ..as we get more
enhancements to each app ...
2cent cdn ...

By: Brian West (bkw918) 2003-11-10 16:28:01.000-0600

I think the queue logic is a bit over kill for such a simple task.  This shouldn't be this big of an app.  Also Campon should accept a filename as an arg to play.  ie.  Campon(SIP/${EXTEN}|campon-${EXTEN}) and may be a patch to voicemail2 to allow recording of campon messages.   Just a thought.

bkw

By: Brian West (bkw918) 2003-11-10 16:30:00.000-0600

I think the only part of this thats needed is the try_calling portion of app_queue.c  Its such a basic task thats all it does.. is loop, play file...try_calling.. loop, play file.. and so on.

By: cypromis (cypromis) 2003-11-12 11:58:09.000-0600

it's fantastic. the queue stuff is much to complex for this and this just solved  the non support part of my pbx system :)

By: pliew (pliew) 2003-11-19 00:06:24.000-0600

I've just added a demo voice file for "campon.gsm". Its spliced together from various sources. Thanks to John Todd for some of his files. Make a copy of this for "campon-repeat.gsm". I've only allowed for the option of leaving voice mail.

By: Brian West (bkw918) 2004-01-27 15:15:55.000-0600

An app for this is over kill but I have put this conf file example to show that this can be done in extension logic.

exten => 765,1,SetVar(CALLEDEXTEN=${EXTEN})
exten => 765,2,Dial(SIP/20,20,m)
exten => 765,3,Goto(campon,camp,1)
exten => 765,103,Goto(campon,camp,1)


[campon]
exten => camp,1,Answer
exten => camp,2,Wait(1)
exten => camp,3,Background(campon)
exten => camp,4,Background(silence/3)
exten => camp,5,WaitMusicOnHold(30)
exten => camp,6,Goto(default,${CALLEDEXTEN},1)

exten => 1,1,Wait(1)
exten => 1,2,VoiceMail(b${CALLEDEXTEN})
exten => 1,3,Hangup

By: Alec Davis (alecdavis) 2010-10-04 02:46:57

Keeping this closed as it's a feature, and a great one, but documenting here the direction forward should this be picked up again.

The issue with the dialplan in ~4235 is that it doesn't keep the order of the callers, IE. Should the destination extension become free, a new caller beats a caller that's been campedon for 25 seconds.

I've recently brought this up on IRC and the preffered method in trunk (post 1.8) would be to use new CCSS methods and events that are now available. Although CCSS calls back at the moment, an extension of CCSS would be to put an external caller into MOH and connect the parties when the destination extension becomes free.

For Asterisk 1.8 and prior, it would still be useful to have this patch maintained using the dynamic queues that this originally introduced.