[Freeswitch-users] UUID from Extension Number

[Michel Brabants]

It's also a patch ofcourse and I think that an extension that lists the
uuid's for an extension would be usefull anyway.

Michel


On Wed, Oct 30, 2013 at 5:58 PM, Michel Brabants
<michel.brabants at gmail.com>wrote:

> I've written a patch for freeswitch that allows you to execute a
> dialplan-command/api from the dialplan when the transfer succeeds ... It
> has been lying around for some time in my local branch waiting to be
> uploaded as a jira-patch ...
>
> I think that this would solve you problem.
>
> Michel
>
>
> On Wed, Oct 30, 2013 at 4:12 PM, Jeremy Childs <jeremyc at ssimicro.com>wrote:
>
>>  Yes, that works fine, except in the case where the incoming call
>> bounces off a receptionist.
>>
>> Receptionist takes call - UUID 1234 is mapped (via mod_db) to the
>> receptionist's extension number.
>> Receptionist begins an attended transfer - new UUID is generated (6789) -
>> this UUID is mapped to the tranfer target (extension 101).
>> Receptionist completes transfer - new UUID (6789) is discarded and UUID
>> 1234 is now the UUID of the call.
>> Eavesdropper wants to listen to whatever extension 101 is doing... no
>> mapping for this.
>>
>> I have a patch for mod_dptools ready to submit that allows eavesdrop to
>> lookup an extension number, I'm just checking to see if I've missed some
>> other way to do it.
>>
>>
>>
>> On 10/30/13, 2:01 AM, Steven Ayre wrote:
>>
>> Use mod_db to store the current call's uuid and then again to look it up.
>>
>>
>> On 29 October 2013 15:54, Jeremy Childs <jeremyc at ssimicro.com> wrote:
>>
>>> I'm trying to create a "works-anywhere" eavesdrop extension. I've got
>>> the demo application that uses the hash/spymap functionality working
>>>      correctly, but you would need the caller-id of the incoming call in
>>> order to eavesdrop on incoming calls. This could be fixed by capturing
>>> the destination number instead of the caller-id number for incoming
>>> calls (and I've done this, it works fine).
>>>
>>> However, this breaks in the case where an attended transfer has happened
>>> (the UUID of the call that gets connected "belonged" to the
>>> receptionist).
>>>
>>> The most robust thing I can think of is to do a live lookup of the call
>>> UUID using the "final" extension number. Is there any way to do this
>>> lookup from the dialplan?
>>>
>>> To be clear, what I'd like to do is this:
>>>
>>> Incoming call is picked up by receptionist (ext 100). Receptionist
>>> transfers call to extension 101. The Boss (extension 200), dials *88101
>>> which looks up the UUID of extension 101's current call, provides this
>>> UUID to the eavesdrop extension, and the eavesdrop proceeds.
>>>
>>> There doesn't appear to be any way to do this from the dialplan, however
>>> -- am I missing something?
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:consulting at freeswitch.orghttp://www.freeswitchsolutions.com
>>
>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>
>> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
>>
>> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20131030/afc0f4d1/attachment.html