+1

Look at SCCP, CDP, Pre-standard PoE, etc. etc. etc.

This is why I avoid proprietary hardware: it never fails to cause problems later because you're stuck with it and you either shell out for all new stuff or keep running on the planned obsolescence/upgrade hamster wheel. Case in point: Nortel's forced upgrade plan for their Meridian systems (Pre-Avaya). An example of this I am personally affected by is in order to purchase more licenses on an older Meridian software release (Option 11c hardware purchased in 2005 but software downgraded to R3 to support connection to legacy Meridian Mail on a separate Option 61c). When we inquired about purchasing an additional 20-30 licenses for an expansion of a department we were told, "no you must upgrade to a CS1000 platform with Call Pilot. Give us $70,000 please to replace all the backend hardware and add some line cards and 20 phones." I then came in and showed them how they could get a brand new (sipX) system and replace all phones with open standards based phones (polycom) that don't care about what backend you run for the same price as the CS1000 upgrade PLUS have a number of features that their current system could not provide. It was a no brainer, they chose the latter.

I think a lot of companies that originally bought into the Cisco VoIP craze back in 2004-2006 are wishing they would have done something else because now they're stuck and the prices keep going up. I know of a few companies/organizations that have moved the backend from CallManager to Asterisk and kept the phones simply because Asterisk has a decent SCCP implementation that allows for full function from the phones. Cisco phones SIP implementation, on the other hand, is very half-baked and while they may have some portion of the IETF SIP standards correctly implemented it is a very SMALL portion.

I really do feel sorry for those that got suckered into the likes of Shortel and various other proprietary platforms. They truly are stuck.

Robert B wrote:
Scott,

That's putting it quite diplomatically. Here's how I'd say it...

Cisco infects... They take emerging standards, dump millions into making 
their own version of it, wait for everyone else to use an open standard, 
do a half-assed implementation of said open standard in their own 
product, then use that as a wedge to sell more of their proprietary 
stack -- which of course works better on their own kit.

I have no reason to think that their SIP implementation is anything 
other than that.

-- Robert




On 4/22/2010 4:31 PM, Scott Lawrence wrote:
  
On Thu, 2010-04-22 at 12:25 -0700, Nathan Nieblas wrote:

   
    
Cisco follows IETF standards for SIP
     
      
With all due respect to Cisco, that statement doesn't mean very much.

There are lots of documents that make up 'standards for SIP', and many
ways in which implementations can be incompatible while still making the
claim that they 'follow' some spec.

Doubtless we will eventually be able to figure out what the issue that
started this thread is, and possibly configure around it.  We may be
able to make a change that prevents the problem but preserves
compatibility with the other phones.

It is true that the core development team does not normally test much
with Cisco phones - they just are not that high a priority for us.  The
configuration support for them is mostly from the community, and for
that we are very appreciative.

If you want to use phones that we test with thoroughly, today that means
mostly Polycom, the Counterpath Bria, and various of the Avaya phones.
Other phones work, but generally are not as well tested by the core
team, and configuration support for them varies more in quality and
frequency of updates.


   
    

_______________________________________________
sipx-users mailing list sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/
  

_______________________________________________
sipx-users mailing list sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to