hi David, maybe i got the issue that is very similar to yours, the scenario is A calls B and B is bridged in lua script (create a new session for leg b and after B answered the call, bridge leg a and b), but when A hangs up before B could answer the call, i found it is not possilbe to have lua get noticed about the hangup.

as i understand, the bridge is made in a synchronous manner, thus you can do nothing before the bridge is finished (successfully or failed), one thing that may help is by using ignore_early_media while originating the b leg call, but this causes other problems for my issue, such as unable to check the result of no answer, so im still seeking a better solution for this.


2013/10/9 Johny Kadarisman Kwan <jkr888@gmail.com>
How about spawn a new lua thread (luarun) before bridge, passing uuid, etc to new script. then on that thread, you check db flagged and/or control call with uuid.

Never done this, but i think should works.


On Tue, Sep 24, 2013 at 6:33 PM, David Villasmil <david.villasmil.work@gmail.com> wrote:
Hello,

I don't think this is something FS can do. Let me explain:

We have FS-A and FS-B, between which are multiple SIP providers. We are checking that the providers between A and B don't divert calls to non-approved vendors. So what I'm doing is:

When relaying the call from FS-A to the provider, I'm adding a SIP header with a unique ID, which is inserted into a DB table. 
When FS-B receives the call, i retrieve the header ID and look it up in the table and mark it as answered.
On FS-A, when the call is answered, it looks up the ID and makes sure it has been marked as "answered" by FS-B.
If it is NOT marked, FS-A MUST disconnect the call.

I hope the explanation was clear, and if anyone has a better idea of how to do this, I'm all ears :)

Thanks

David



On Tue, Sep 24, 2013 at 5:12 PM, Brian West <brian@freeswitch.org> wrote:
Maybe if we understood more we could probably guide the end user in a better way to accomplish their goals!

/b

On Sep 24, 2013, at 9:46 AM, Michael Collins <msc@freeswitch.org> wrote:

> I'm with Brian on this one. The bridge app is epic. So the question is this: what are you trying to accomplish with all this Lua stuff that you can't do with a simple bridge?
>
> -MC
>


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org