*3 Feature (MixMonitor) Assistance

Fellow techies,

I must be doing something wrong, or I’m missing some crazy-basic thing I should (or shouldn’t) have done.

What I’m attempting to do is change the default recording format for the mixmonitor call recording feature, globally, from .wav to .gsm, or anything smaller than uncompressed .wav. Put another way: When I (or another user) hits *3 to record the call they’re on at that moment, the system should generate the resultant audio file in a format more space-efficient than .wav

I’ve been up one side of the configuration files and down the other. I’ve Google-searched 'til I’m blue in the face. No luck! The only things I’ve come across are using the ‘mixmonitor’ function from lines in the dialplan, and that’s not what I’m interested in here.

So – Am I banging my head against the metaphorical wall, or am I missing something simple?

Thanks much.

Using automixmon => *3 I dont see any option to pass parameters to the MixMonitor() app,you must consider use a dynamic feature

I’m not sure I follow. If, by ‘dynamic feature,’ you’re referring to the ‘features.conf’ file, I’ve already configured mine as shown here.

[featuremap]
blindxfer => #1 ; Blind transfer (default is #) – Make sure to set the T and/or t option in the Dial() or Queue() app call!
disconnect => *0 ; Disconnect (default is *) – Make sure to set the H and/or h option in the Dial() or Queue() app call!
automon => *1 ; One Touch Record a.k.a. Touch Monitor – Make sure to set the W and/or w option in the Dial() or Queue() app call!
atxfer => *2 ; Attended transfer – Make sure to set the T and/or t option in the Dial() or Queue() app call!
;parkcall => #72 ; Park call (one step parking) – Make sure to set the K and/or k option in the Dial() app call!

automixmon => *3 ; One Touch Record a.k.a. Touch MixMonitor – Make sure to set the X and/or x option in the Dial() or Queue() app call!

I added an extra space above that last section to make it stand out. What I’m trying to do is change the default behavior of the automixmon feature (make it use a format other than .wav for recording).

Thanks much.

Sorry I was talking about a dynamic features using applicationmap

This is a working example


features.conf

[applicationmap]

mixmon => #8,peer,Mixmonitor(/var/www/html/file.gsm)


extensions.conf

same => n,Set(__DYNAMIC_FEATURES=mixmon)

(insert facepalm here)

Eegads… That makes perfect sense! And, I just realized there’s a whole section of explanation on applicationmap … just a little farther down than I originally stopped reading… in features.conf!

…arrgh…

Thanks. I’ll go and give it a try.

(UPDATE - THE NEXT MORNING)

Thanks to the above post about featuremap, and given a little more research and tweaking, I thought I’d share my version of the solution (and, hopefully, save someone else a lot of frustration).

My specific application was to be able to start or stop recording a call on demand, all from whatever phone the user happens to be on at the time. I had the additional requirements of making the call recordings a mix of both sides of the conversation, and for using a smaller file format than .wav.

The solution turned out to be a combination of macros in the dialplan, and some tweaks to the application map in features.conf.

First, the additions to extensions.conf under the [globals] context:

DYNAMIC_FEATURES=mixmon#stopmix

Next, the two macros:

[macro-callrec]
; Sets up the mixmonitor call recording function with an easily-tweakable filename.
;
exten => s,1,Set(MONITOR_FILENAME=${STRFTIME(${EPOCH},%Y%m%d-%H%M%S)}-${CALLERID(num)}-${CHANNEL})
same => n,Playback(beep) ; optional - hear when recording starts
same => n,MixMonitor(${MONITOR_FILENAME}.gsm,b)
;
[macro-stoprec]
; Shuts off call recording on demand.
exten => s,1,StopMixMonitor(${MONITOR_FILENAME}.gsm,b)

And, finally, in features.conf under applicationmap:

[applicationmap]
;
mixmon => *7,peer,macro(callrec)
stopmix => *0,peer,macro(stoprec)

The nice thing about using a macro is I can also (I think) find a way to call it using a feature button on a VoIP phone. I suspect this would have proven much more difficult with a trigger limited exclusively to DTMF signaling.

I think my only regret is I didn’t figure this out last night. :wink:

Keep the peace(es).