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 _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
