[asterisk-dev] AMI command for SIP Notify

[Olle E Johansson]

23 aug 2007 kl. 16.08 skrev Tilghman Lesher:

> On Thursday 23 August 2007 02:47:29 Igor A. Goncharovsky wrote:
>> Olle E Johansson writes:
>>> However, this is a syntax I've never seen for AMI. We really ned an
>>> "attachment" for this or the ability to have multiple headers  
>>> with the
>>> same name.  I can't remember if we ever have that, don't think  
>>> so. When
>>> sending, we would simply do a list. At some point, it would be  
>>> better to
>>> have peer groups and send a notify to the group.
>>
>> Yes, we need something like attachment. Or there is no other way,  
>> other
>> the specify multiple values with same name.
>> Idea with peer groups not so good: If external app want to notificate
>> device, it can notify any set of devices.
>>
>>>> But name "Peer" already in use. Should I use other name or  use
>>>> peer in format "Techology/Name"?
>>>
>>> As this is a SIP specific peer, we might want to use SIPpeer, or  
>>> even
>>> better, SIPdevice
>>
>> OK, SIPdevice looks like good name. As I know there are no same
>> techology for other protocols and therefore no need to use peer name
>> with technology.
>> Also question: is it need to make response with confirmation of  
>> notify
>> sent? I think yes, when we get 200 OK from device.
>
>> From a top-down perspective, we have really been trying to get  
>> away from
> customized parameter names in the manager.  Custom names are fine
> for the Event name, but we'd like to see you use common parameter  
> names.
> So I'd prefer something along the following lines:
>
> Action: SIPnotify
> Notify: <notify-type>
> PeerCount: 3
> Peer: <sip-peer-name-1>
> Peer: <sip-peer-name-2>
> Peer: <sip-peer-name-3>
>
> with, of course, PeerCount defaulting to 1, if not specified.  That's
> backwards compatible to the current Notify event.  There is no  
> prohibition
> in the normal manager against having multiple parameters with the same
> name.  There is such a prohibition in the XML manager on the HTTP  
> port, but
> I'd propose solving that issue by adding -1, -2, etc. onto the  
> names, to avoid
> duplicates in those cases (and do it transparently by the same  
> function that
> translates events into XML).
>
maybe we should allow the same as we do in the configuration and  
realtime
in this case, use semicolons so taht

Peer: value1
Peer: value2

Is the same as

Peer: value1;value2

/O