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