[asterisk-dev] AMI command for SIP Notify

[Tilghman Lesher]

On Friday 24 August 2007 02:23:56 Olle E Johansson wrote:
> 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

I really don't like that approach, because it means we need to start dealing
with escape syntax in the Manager.  Adding a new line neatly avoids that
sticky problem.

-- 
Tilghman