Subject: Re: [Sip] INFO Use case

From: "Christian Stredicke" <[email-masked]>
Date: Tue, 18 Nov 2008 21:47:29 +0100

The word "snom" triggered my attention ;-)

Regarding buttons we implemented something on our own which probably addresses the case below (see http://wiki.snom.com/Features/LED_Remote_Control). Not only Cisco does have their own extensions! It is not enough for use to have F1 or HOLD buttons description; we must also be able to control LED and displays associated with the button. So far our little dirty protocol solves that problem in a nice way and we can offer the features that the traditional PBX were able to offer. 

But I agree. The interop level in SIP regarding buttons barely goes beyond POTS and 12-key DTMF. Vendors like snom today have no other choice but a selection box that says what kind of SIP the phones should talk. It is a mess!

CS

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Cullen Jennings
Gesendet: Dienstag, 18. November 2008 21:01
An: SIP List
Betreff: [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-masked] for questions on current sip Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Nov 2008 14:49:04 -0600

I agree Christain, it's a mess. I remain hopeful that the new info  
work will help make this less messy.

On Nov 18, 2008, at 14:47 , Christian Stredicke wrote:

> Regarding buttons we implemented something on our own which probably  
> addresses the case below (see http://wiki.snom.com/Features/LED_Remote_Control) 
> . Not only Cisco does have their own extensions! It is not enough  
> for use to have F1 or HOLD buttons description; we must also be able  
> to control LED and displays associated with the button. So far our  
> little dirty protocol solves that problem in a nice way and we can  
> offer the features that the traditional PBX were able to offer.
>
> But I agree. The interop level in SIP regarding buttons barely goes  
> beyond POTS and 12-key DTMF. Vendors like snom today have no other  
> choice but a selection box that says what kind of SIP the phones  
> should talk. It is a mess!
>
> CS
>
> 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
> 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.
>
> 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.
> This list is for NEW development of the core SIP Protocol Use [email-masked] 
>  for questions on current sip Use [email-masked] for new  
> developments on the application of sip
>
>