[asterisk-dev] [Code Review] AST-33: Create a list of channel variables to be posted within AMI call events

[Olle E. Johansson]

24 sep 2009 kl. 22.31 skrev Tilghman Lesher:

> On Thursday 24 September 2009 15:04:09 Olle E. Johansson wrote:
>> 23 sep 2009 kl. 22.26 skrev Tilghman Lesher:
>>>> On 2009-09-17 16:09:01, Olle E Johansson wrote:
>>>>> I am a bit unsure of the syntax here. I need a few more days to
>>>>> come up with an idea or a comment ;-), need to focus on SIPit
>>>>> stuff. Please hold. Thanks.
>>>
>>> How many days is 'a few'?  ;-)
>>>
>>>
>>> - Tilghman
>>>
>>>
>>> -----------------------------------------------------------
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviewboard.asterisk.org/r/368/#review1097
>>> -----------------------------------------------------------
>>>
>>> On 2009-09-17 15:48:06, Tilghman Lesher wrote:
>>>> -----------------------------------------------------------
>>>> This is an automatically generated e-mail. To reply, visit:
>>>> https://reviewboard.asterisk.org/r/368/
>>>> -----------------------------------------------------------
>>>>
>>>> (Updated 2009-09-17 15:48:06)
>>>>
>>>>
>>>> Review request for Asterisk Developers.
>>>>
>>>>
>>>> Summary
>>>> -------
>>>>
>>>> The intent of this patch is to post various variables from a
>>>> related channel, when posting certain call-related events to the
>>>> manager interface.
>>>>
>>>> For example, the following manager.conf entry:
>>>>
>>>> channelvars=SV_OWNER,SV_PEER,DISPLAY_URL
>>>>
>>>> will result in the following manager output for a Newstate event:
>>>>
>>>> Event: Newstate
>>>> Privilege: call,all
>>>> Channel: SIP/200-08b75888
>>>> State: Up
>>>> CallerID: 200
>>>> CallerIDName: Snom Phone
>>>> Uniqueid: 1209084781.0
>>>> Channel1Var-SV_OWNER: a1101
>>>> Channel1Var-SV_PEER: a1116
>>>> Channel1Var-DISPLAY_URL:
>>
>> And in chan_sip we have
>>
>> astman_append(s, "ChanVariable: %s=%s\r\n", v->name, v->value);
>>
>> I don't think we want two different ways and since we already have
>> selected this one, I suggest we keep it.
>
> 1) That only works for the SIP channel.  As you are fond of pointing  
> out, we
> have other channel types.
I don't understand you. It's a manager header that we use to display  
channel variables.
We have a policy of not adding new headers if we already have one we  
use.

> 2) That spits out variables only for the SIPPeers command, not call  
> events.
Right. And?

> 3) That spits out variables set for the peer when the peer first  
> starts up,
> not variables set in the dialplan, and if the variable has changed  
> since
> startup, this command won't show the new value.
I don't see how this command is related. I just pointed out that we  
already have
a header we use for channel variables.

I see no reason not to stick with this header, like we're trying with  
other headers.

/O