[VoiceOps] What is a Modern SIP Phone?

[Hiers, David]

I'd say two things:


1.      Anything that passes your interop test is acceptable

2.      If you don't test it, it is broken



David

From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Mark R Lindsey
Sent: Wednesday, March 20, 2013 14:08
To: Joshua Goldbard
Cc: <voiceops at voiceops.org>
Subject: Re: [VoiceOps] What is a Modern SIP Phone?

On Mar 20, 2013, at 16:06 , Joshua Goldbard <j at 2600hz.com<mailto:j at 2600hz.com>> wrote:
In short, a modern SIP phone is one that speaks SIP in an RFC compliant manner and plays nicely with most hardware. IMHO, and this is strictly personal opinion, the Cisco 79x0 series is not something I would include in this category.

If all you need is basic calling with G.711, INVITE> 180< 200< ACK> then lots of phones will do it. Unfortunately, that's where many of the vendors seem to complete their testing.

The "plays nicely with most hardware" part is quite a loaded clause! I'd expand that to say that you need your SIP phones to be compatible with the features of YOUR feature server; the trouble spots all relate to the important PBX-replacement features, such as:

            -- Shared Call Appearance / Shared Lines

            -- Busy Lamp Field / Line State Monitoring

            -- Feature Key (DND, CF, etc.) Synchronization

            -- Message Waiting Indicator

            -- N-Way Conferencing

            -- Call Hold Style (mentioned only because The Cisco 7960s still use RFC2543 call hold, IIRC).

            -- 100rel support

            -- Proper handling 183 followed by 180 response

But here's the problem with looking for standards compliance:  some of the important SIP features have never made it to standards-track RFCs. The process often seems to go like this:

            (1) Big customer wants something
            (2) Big vendor wants Big Customer's money
            (3) Big vendor implements proprietary version of feature
            (4) Customer Satisfied
            (5) Big vendor publishes IETF draft
            (6) IETF draft expires
            (7) Big vendor 2 wants Big Customer. Also implements expired IETF draft.

The process can be a lot worse if Big Vendor skips steps 5 and 6, just leaving their implementation as proprietary and barely published. Or the process can go better, where a real standard comes out of it. Sometimes, the IETF standard actually does precede a commercial implementation.

(There are some interesting points buried in this area about the fundamental "end to end argument in system design" and how that works for dynamically negotiated features. We'd all like to believe that we humans could specify standards and the two endpoints could negotiate the best common set of compatible features on each individual call. But we haven't proven that it's even possible.)

When you're evaluating a SIP access device -- phone or PBX -- you're working in this weird milieux of non-standardized-yet-important features, for which interop testing is the only compliance that matters.

>>> mark at ecg.co<mailto:mark at ecg.co> +12293160013 http://ecg.co/lindsey




This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20130320/86945fbd/attachment-0001.html>