Questions: 1) Do you achieve any better interoperability by preventing this happening? Will SNON build something that is directly equivalent in functionality to Cisco + Nortel
2) If an individual vendor specifies their own package, then can we control this except by expert review? And if we do that expert review, do we provide a barrier to registration. At least if we have an open registration we could keep an eye on the registration page and encourage people who are registering similar things to cooperate on a combined package. And finally, I believe we are pushing in the direction of it is up to the package specifiers to specify the interaction with any other package, and therefore SIP will not specify any of "they need to be one atomic action so they are not interpreted as the wrong thing or as double key presses". regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Cullen Jennings > Sent: Tuesday, November 18, 2008 7:52 PM > To: SIP List > Subject: [Sip] INFO Use case > > > Let's imagine that there is a base DTMF package defined that > supports the 12 basic keys. Now cisco makes a vendor specific > package that is > pretty much the same but includes key presses for the "HOLD" > button. > Nortel does pretty much the same but calls it the "F1" > button. Now SNOM wants to build a phone that supports both > and in fact is operating in an environment with a Nortel PBX, > Cisco Voice Mail, and Asterix SBC which understands both - > the phone really needs to send both and they need to be one > atomic action so they are not interpreted as the wrong thing > or as double key presses. > > It seems that things along the lines of the above will happen > and need to be considered. I don't know if this means an INFO > needs to carry more that one thing or not. The worst possible > solution I can imaging to this is that SNOM builds a new > package that combines the Cisco and Nortel package. > > Cullen <in my individual contributor roll> > > PS - I do not care if people want to solve this use case or > not. I just mention it as something I view as somewhat likely > to happen. I am happy with whatever get's decided. > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
