[Freeswitch-users] HA recovery of custom channels variables

[Danny Gershman]

Ok cool I think we are going to go the Redis route.  We were using it to
store information about the channel for our own application, essentially
arbitrary information about our system.

Regarding mod_redis... this doesn't already do this does it?  What does
mod_redis do?

On Fri Nov 21 2014 at 2:32:38 PM Michael Jerris <mike at jerris.com> wrote:

> The information is updated on bridge, unbridge, answer, and media
> negotiation.  Basically any time the switch_core_recovery_track function is
> called.  It would be fairly easy to add a way in dialplan for you to
> manually update, you could give that a try, and submit a patch.  The other
> option wold be to do it on every dialplan execute, but I think that would
> be far to high a cost to do.  The trick here is finding the right places to
> re-write the state information to the db, as there is cost involved, we
> don't want to do so in too many places.  This is why your actual scenario
> matters.
>
> Mike
>
> On Nov 21, 2014, at 2:02 PM, Danny Gershman <danny.gershman at gmail.com>
> wrote:
>
> I did another test with this, if I do a transfer right after I set the
> variable then it's available.  Is there a way to propagate the channel
> variables into the xml doc without doing a transfer or executing inline?
>
> On Fri Nov 21 2014 at 1:03:49 AM Danny Gershman <danny.gershman at gmail.com>
> wrote:
>
>> I have done a simple test, I call in with a softphone to a conference.  I
>> grab the uuid and I run uuid_setvar.
>>
>> On Thursday, November 20, 2014, Michael Jerris <mike at jerris.com> wrote:
>>
>>> it depends when you are setting them.  If they are not in the xml doc
>>> when you go to do recovery, they will not be re-populated.  When/how are
>>> you setting them?
>>>
>>> > On Nov 20, 2014, at 5:49 PM, Danny Gershman <danny.gershman at gmail.com>
>>> wrote:
>>> >
>>> > I'm using some custom channel variables for storage and I noticed that
>>> when I do a recover they are not preserved because they are populated to
>>> the table 'recovery'.
>>> >
>>> > Is there something that I'm not doing to make this work?
>>> >
>>> > --Danny G
>>> >
>>> _________________________________________________________________________
>>>
>>>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.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/20141121/a14c18e8/attachment.html