"buttons" are about documents. In principle you could send it via HTTP/AJAX (which is IMHO a real alternative) or you can send it in a instant message. We don't like SUBSCRIBE because then there are so many dialogs on the user agent. But yes, of course you could also use a SUBSCRIBE dialog to carry the buttons in NOTIFY bodies.
When sending "buttons" in a IM they are as secure as any other IM. CS -----Ursprüngliche Nachricht----- Von: Daniel-Constantin Mierla [mailto:[email protected]] Gesendet: Mittwoch, 31. Dezember 2008 15:31 An: Christian Stredicke Cc: [email protected] Betreff: Re: [Sip-implementors] Chaos in Dialog subscription "standar" Hello, On 12/31/08 12:09, Christian Stredicke wrote: > It is even worse. There are features that are simply not possible with dialog > state. For example, think about a simple DND button that you want to program > on your phone or just a speed dial. > > I guess dialog state was not designed for the use on phones with buttons and > LED. I regret and apologize that sn** was one of the first to use dialog > state to turn LED on and off. There was simple nothing else. Choosing dialog > state was a big mistake and other vendors followed. Now today you can > problaby not sell a phone without this mistake any more and every RFP has it. > Ouch! > > In the meantime, we have defined something new called "buttons" (see > http://wiki.snom.com/Features/LED_Remote_Control). That solves all problems > that we see in this area and it is very simple. I invide everyone to take a > look at it. It would make SIP in the office environment a lot easier. > I assume the first reply in the example is for REGISTER, not for a SUBSCRIBE, right? Description for second reply seems also wrong. However, my first real question is related to security. Is the device challenging the MESSAGE requests from registrar? Are you aware of someone else (device vendor) going for this approach? Cheers, Daniel > CS > > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag von > Iñaki Baz Castillo > Gesendet: Mittwoch, 31. Dezember 2008 00:46 > An: [email protected] > Betreff: [Sip-implementors] Chaos in Dialog subscription "standar" > > Hi, as far as I can read, RFC 4235 "An INVITE-Initiated Dialog Event Package" > was born in November 2005. I expect 3 years are enough time to implement it. > > But what I see is the fact that each vendor implements "dialog" subscription > in a propietary way. For example, when configuring a Li**** phone for dialog > subscription it requires to choose between subscription server type > (Ast*****, Broa******, RFC4235, ...). > > This is just annoying for me. There are more and more new RFC's and drafts > based on RFC 4235 for different purposses, when the fact is that most vendors > implement such things as they want (it means: in a propietary way). > > This is no good for interoperability. Any explanation of this sad reality? > Thanks a lot. > > -- > Iñaki Baz Castillo > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > -- Daniel-Constantin Mierla http://www.asipto.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
