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

[Olle E. Johansson]

25 sep 2009 kl. 16.52 skrev Tilghman Lesher:

> On Friday 25 September 2009 09:14:11 Olle E. Johansson wrote:
>> 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:
>>>>>> 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 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.
>
> Understood.  How do you suggest that we differentiate between  
> variables set on
> two different channels, when the AMI call event relates 2 different  
> channels?
>

Sorry, missed this earlier. Reading mail backwards I guess. Long  
answer to explain how I thinks about manager changes and why I'm  
trying to make sure that additions and changes are a bit more logical  
than old stuff.

We currently have too many ways we handle this kind of situation (two  
channels), which is poor. I would like to suggest:

ChanVariable: NAME = VALUE

and

BridgedChanVariable: NAME = VALUE

On the other side, we will have to consider the new dynamic bridge and  
stop assuming that a bridge is always two channels. That will not be  
the case much longer. On the other hand, that also means that we will  
have to change a lot of the existing manager commands and upgrade to  
AMI 1.2. Adding numbers doesn't really make sense.

In the manager event Bridge we do have Channel1: and Channel2: which  
will be hard to extend and keep control of numbers as we get a dynamic  
bridge. A while after we add channel3: channel2 might hang up and we  
end up with channel1 and channel3. If we refer to another channel we  
might have to add a new syntax to AMI, like:

ChanVariable(<chan-id>): Name = value

or using more ietf style attributes

ChanVariable: Name = value ;channel=<chan-id>

(I prefer the first construct).


Let's see what we got in the current set of messages....

In Event: Transfer we have Channel and TargetChannel

ChanSpyStart has SpyerChannel And SpyeeChannel (which should really be  
Channel, since it's the primary)


Going through this, I see that there's a lot of new manager events  
added recently that doesn't follow the standards we tried to set in  
manager 1.1. We should propably do a review before each release,  
unless we can catch them early in the process like this case...

The reason I'm fighting for this is that it's very hard to explain to  
students why a channel identifier has multiple and sometimes confusing  
header names in a protocol that is header:value based. That doesn't  
happen in SIP, http, mail and other header: value based protocols. Why  
is "Channel:" sometimes NOT a channel identifier and why is "Channel:"  
sometimes called something completely different? I don't like that  
lack of logic and it's very hard to explain "Yes, but you see, a  
header is only defined within the context of the event or the action/ 
response. The fact that it means something else or that the same data  
has another header in another event is completely ok".

We want to lower the barrier for developers that start learning AMI,  
not make it harder. Let's try to keep AMI clean and make sure that  
additions and changes has some logic to it.

/O