On Thu, Mar 18, 2010 at 03:36:53PM -0600, Mark Sobkow wrote:
Ok, so that new originate command will give me another UUID, and I'll have to bridge it to the original call's UUID, correct? i.e. Someone dials the 66xxxx extension, it calls back to Erlang and parks. Erlang issues the originate command, returns a UUID for the new call, and I do a uuid_bridge so the caller can hear the eavesdrop.
The only thing I'm a little puzzled by is the user/agentname string. The caller is already on the phone, so how can Freeswitch call them?
Alternatively maybe I could set the operator UUID into a variable and establish the call through a dialplan extension, but I think that ends up with the same problem of the caller being busy.
I do have one other option -- we have a softphone built into our front-end application, so I could have a button press/menu selection on that application issue a command to Erlang, which would mean it could call the softphone because it's not busy trying to dial a special 66xxxx extension. That actually might be the best solution, because then there is no "secret" extension in the dialplan that unauthorized users might learn about. I just need to have one of our other developers provide an API to retrieve the configured extension/registration information for the softphone so it can pass along the extension to Erlang for building a dial string. The only "downside" to that approach is that it _requires_ our client application to work, but I think our user community will be ok with that because managers need that application for a whole host of features, not just the softphone.
Oh, I see what you wanted. Why not just bridge the call to an inline dialplan that calls eavesdrop() then? That way you don't have to serve up an extension or anything annoying. something like uuid_transfer CallerUUID 'eavesdrop:EavesdropUUID' inline ? Andrew