This is why I had to bridge to internal extensions, then after a timeout another bridge to all extensions plus the cells. And this is why if you pickup exactly between extensions you have to hangup and pickup to get the call. A real pain. Dropping enterprise fixes it but caused other issues. I am interested if your trick will work, but the even if it does the potential problem is that FS may change and this "trick" might stop working. I had that happen when I upgraded FS this year. Had situations were sometimes the caller was actually one of the targets (don't ask why), worked from 2010 to spring 2012 and the bridge stopped working. Something changed and I had to execute another extension so I could test the caller (can't do nested if/then/else). So the moral of the story is that unless the technique is officially supported, it may not work in the future. On Jul 26, 2012, at 2:04 AM, Alex wrote:
I did wonder if there would be a cunning way to workaround this by having each enterprise destination that needed it to have a fake first destination
eg
<FirstRealDestination>:_:<FakeDestination>,[leg_delay_start=10]<SecondDestination>:_:<FakeDestination>,[leg_delay_start=20]<SecondDestination>
The fake destination would never answer, but would have to be of the right type to avoid the problem that non-enterprise origin has (which is that it doesn't work with multiple SIP registrations)
You can use it in each sub originate between :_: but not at the top level, that would require some kind of feature bounty enhancement. each string sep by the :_: is its own entire function originate, so it really would never work how you expect once you clear that up.
On Wed, Jul 25, 2012 at 3:09 AM, Alex <alex@thewinelake.com> wrote:
Also suffering from this problem and it's a biggie for us. I suppose the problem is due to the way in which the legs communicate. Looks like using enterprise originate was just a little too optimistic! Wish I'd known about this sooner and could have got on with writing our own lua script that can do the job better. If anyone's done this already and prepared to share, do get in touch.
_________________________________________________________________________ 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
Join Us At ClueCon - Aug 7-9, 2012
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
Join Us At ClueCon - Aug 7-9, 2012
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