I'm starting a new thread because I screwed the other one up and can't seem to edit the first post.
We're having a problem with a tenant who records all calls. Any call that is parked is recorded up until the point the call is parked but then isn't recorded afterwards.
Originally it wasn't even possible to manually record the call after it was parked but that part I've figured out. However, since all calls are supposed to be recorded automatically it should really record the call after parking without having to do anything.
We are doing the following to park calls:
context => parkedcalls-tenant
parkedcallrecording => both
parkext => 700
parkpos => 701-710
parkingtime => 120
findslot => first
Adding the "parkedcallrecording" allows us to manually record calls after parking which we couldn't do before.
The extensions are set up as:
exten => 701,hint,park:701@parkedcalls-hubris
exten => 702,hint,park:702@parkedcalls-hubris
So I'm thinking that we need to do more here but I'm really not sure what. I've tested this on 1.6.1x and 1.8.7.1 but we're only running Thirdlane on 1.6.1.x currently so I'm not 100% sure how it handles it. I know MTE is sort of broken on 1.6.1.x when it comes to parking but we've set everything up manually and it all works other than this parking issue.
Am I just missing something in the extensions.include here? Surely parking doesn't always break recording.
most likely it would since calling 701 would not invoke any sort of dialplan to generate call recording on parked calls. You would have to create a custom script to unpark the call that had the call recording line preceding the line that unparked the call. This is where you will need asterisk 1.8 since it isnt until recent versions that you can specify the parkinglot with the park, parkandannounce, and parkedcall applications.
-= Info about application 'ParkedCall' =-[Synopsis]
Retrieve a parked call.
[Description]
Used to retrieve a parked call from a parking lot.
NOTE: Parking lots automatically create and manage dialplan extensions in
the parking lot context. You do not need to explicitly use this application
in your dialplan. Instead, all you should do is include the parking lot
context in your dialplan.
[Syntax]
ParkedCall([exten][,parking_lot_name])
[Arguments]
exten
Parking space extension to retrieve a parked call. If not provided
then the first available parked call in the parking lot will be retrieved.
parking_lot_name
Specify from which parking lot to retrieve a parked call.
The parking lot used is selected in the following order:
1) parking_lot_name option
2) ${PARKINGLOT} variable
3) 'CHANNEL(parkinglot)' function (Possibly preset by the channel
driver.)
4) Default parking lot.
[See Also]
Park(), ParkAndAnnounce()
so your dialplan could be something like
_70Z pattern to run custom script
exten => s,1,MixMonitor(your-file-naming-convention,options)exten => s,n,ParkedCall(${MACRO_EXTEN},parkinglot_${tenant})
I did notice that theres a lot of places where MixMonitor is used in existing scripts with the 'b' option, which might explain why the recording stops when its parked. but unless you wanted the recording to continue the whole parked time, and still be named based on the one who originally parked the call, this is your best solution if it works for you.
I would like to also point out that its generally a bad idea to let one tenant hog the resources of MTE all to themselves by imposing something as taxing as 'recording every single call' they make or receive. Surely if their needs are so important they would be willing to spring for their own STE edition of thirdlane wouldn't they? Compound the situation with a sales team that follows the 'whats good for the goose' philosophy subsequently allowing other tenants to also record every call and you may have a recipe for disaster.