<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andrew Thompson wrote:
<blockquote cite="mid:20100318214841.GG28551@hijacked.us" type="cite">
<pre wrap="">On Thu, Mar 18, 2010 at 03:36:53PM -0600, Mark Sobkow wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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
</pre>
</blockquote>
I'll think about that, but for right now our client has the UUID's for
the operator handy to pass back to an Erlang server API. The only
thing our developers have to do is retrieve the extension id from the
softphone for calling Erlang. I'm liking this because it's minimal
work on my part -- the GUI developers are now on the critical path and
I'm waiting for them so we can test this new API. :D<br>
<br>
I just needed _a_ solution to the problem -- it doesn't have to be
"elegant" unless we get complaints from our user community. And this
solution is secured by easily configured user/group memberships (i.e.
via our GUI), rather than having to make different users members of
different dialplan groups (a trained administrator function that
requires tech support intervention.)<br>
</body>
</html>