Which development team?  The one that created the current interoperability
and donated it, or a new team that is interested in making them work better
and will put together the necessary work to get it done?  These seem to be
distinctly different teams than the one that is working on the current
roadmap. 

 

 If I'm not mistaken, Cisco builds their phones to promote their system,
much like Mitel, Panasonic, and the rest.  Polycom designs to open standards
to maximize interop with the must number of vendors -  today they claim 25
interops.  When you buy into a proprietary system, and then want to make
those components interoperate with others, it's difficult to expect the same
results with products that are designed to be running on open standards and
not proprietary methods.

 

Somebody had discussed using escrow accounts for development of features.
Maybe a pooling of resources for those that want to use Cisco phones with
sipXecs is in order now.  I suspect working together as a "Cisco" team, you
can identify the issues, and the features that work or don't work.  With
that, a list of feature enhancements to the current managed templates could
be developed to improve the interoperability between your Cisco products and
sipXecs.  With most of the developers working for Avaya, do you really see a
huge incentive for them to work on making Cisco work with the product?  The
users that have an investment in Cisco products really are the ones that
have ownership of making them work with sipXecs.

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Rhon
Sent: Thursday, April 22, 2010 3:07 PM
To: Scott Lawrence; [email protected]
Subject: Re: [sipx-users] Cisco and sipX 4.2

 

Hi Scott,

Our problem here is a transition issue (from CME to SipXecs). For some
company like us who can't always afford to replace equipments,
it's not always easy to say just replace your phones with polycoms.

We will greatly appreciate if the development team start looking into
interoperability issues like this. I just hope it will be very soon. :)

Thank you for your attention.

Best regards,

Rhon

On Fri, Apr 23, 2010 at 5:31 AM, Scott Lawrence <[email protected]> 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 [email protected]
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