[Freeswitch-dev] Channel variables from openzap

Simon Capper scapper at ooma.com
Fri Oct 3 02:00:55 EDT 2008


Is there a way to iterate var_event or do I need to add one?


Simon


On 10/2/08 11:52 AM, "Anthony Minessale" <anthony.minessale at gmail.com>
wrote:

> use a hash to store the vars.
> we have a hashtable you can see being used in zap_io.c
> 
> 
> 
> On Thu, Oct 2, 2008 at 1:21 PM, Simon Capper <scapper at ooma.com> wrote:
> 
>> I see how the var_event mechanism works.
>> 
>> Are you ok with new openzap functions to set/get the vars on the channel,
>> called from outgoing_channel().
>> 
>> zap_channel_add_var(zap_channel_t *zchan, char *var_name, const char
>> *value)
>> 
>> const char * zap_channel_get_var(zap_channel_t *zchan, char *var_name)
>> 
>> And new fields in zap_channel struct to hold the data
>> char * user_vars[];
>> int num_user_vars
>> 
>> 
>> Simon
>> 
>> 
>> On 10/2/08 10:18 AM, "Anthony Minessale" <anthony.minessale at gmail.com>
>> wrote:
>> 
>>> The difference openzp is itself also an abstraction layer so you need to
>>> pass it down.
>>> 
>>> I *will not* violate scope like that.....
>>> 
>>> so the only thing I am ok with is adding channel variables to the openzap
>>> channels.
>>> Then you can either set them all from the vars_event in the mod_openzap
>>> outgoing_channel routine
>>> or with a callback via the core set_variable mechanism.
>>> 
>>> Then your signaling mod could get the variables by name when it was
>> needed.
>>> 
>>> you will learn to understand that due to the years of torture from
>> asterisk
>>> and it's knotted up api that is somehow called an abstraction layer, I
>> will
>>> not bend on scope issues. Things like this are exactly what went wrong
>>> there.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Oct 2, 2008 at 11:04 AM, Simon Capper <scapper at ooma.com> wrote:
>>> 
>>>> The variables would be set before the call by another app, its analogous
>> to
>>>> setting a sip_x variable and having it appear in the sip signaling,
>> don't
>>>> need a callback.
>>>> 
>>>> The parameters are (so far):
>>>> Ring type: (cadences index to ring the phone with)
>>>> Phones to ring list: (proprietary for my ozmod module, don't think it
>>>> should
>>>> be in the library)
>>>> 
>>>> Maybe have a variable  "opanzap_<variable_name>" that mod_openzap looks
>> for
>>>> and adds to the zchan structure by passing a custom variable array to
>>>> zap_channel_open() then the ozmod can read it.
>>>> 
>>>> Simon
>>>> 
>>>> 
>>>> On 10/2/08 6:11 AM, "Anthony Minessale" <anthony.minessale at gmail.com>
>>>> wrote:
>>>> 
>>>>> That would pretty much violate the whole scope of the library.  It's
>> not
>>>>> supposed to even know there is a such thing as FreeSWITCH to get
>>>> variables
>>>>> from.  There could just as easily be a chan_openzap for asterisk
>> (*WINK*
>>>>> *WINK* anyone? buelleur?)
>>>>> 
>>>>> What exactly do you need them for?
>>>>> 
>>>>> The most elegant way would be for the FS core to allow endpoints
>>>>> (mod_openzap) to register a callback to be called
>>>>> when a variable is set on that channel, then add the concept of channel
>>>>> variables to openzap zchans
>>>>> 
>>>>> so then when FS had a channel variable set it mod_openzap would in turn
>>>> set
>>>>> it on openzap zchan and the blind abstraction would be preserved.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Oct 2, 2008 at 2:42 AM, Simon Capper <scapper at ooma.com> wrote:
>>>>> 
>>>>>> I want to access channel variables from an ozmod module in openzap.
>>>>>> I can't see a way to do it in the current code.
>>>>>> 
>>>>>> I'd like to add the feature and provide a patch for openzap when I'm
>>>> done.
>>>>>> I'm thinking of adding a void pointer that could be passed down via
>>>>>> zap_channel_open that could be then be used from the ozmod modules?
>>>>>> Mod_openzap would set the pointer to a function that would give access
>>>> to
>>>>>> channel variables. Thoughts?
>>>>>> 
>>>>>> Simon
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing list
>>>>>> Freeswitch-dev at lists.freeswitch.org
>>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>> UNSUBSCRIBE:
>> http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>>>>> http://www.freeswitch.org
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>>> http://www.freeswitch.org
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>> 
> 
> 





More information about the Freeswitch-dev mailing list