[asterisk-dev] AMI command for SIP Notify

[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).

-- 
Tilghman