Results 1 to 8 of 8

Thread: Cisco SPA50x

  1. #1

    Default Cisco SPA50x

    Seems we can't get SPA9xx phones any longer, they appear to have been replaced by these new SPA5xx models e.g. SPA501G.

    Any ideas if/when this product line will be supported on the Quadro?

  2. #2

    Default same issue

    I also now have the new Cisco 50x phones. In my case, the SPA502G.

    I was comparing the configuration settings side by side with a SPA922 and the fields match up very closely.. only a few minor changes. I would think that the SPA922 line settings, therefore, would work fine for auto provisioning... but no such luck. Is there a way to tweak this manually in the system, or do we need to wait for the phone to be added to the firmware?

  3. #3

    Default solution found...

    I dug a little deeper and saw dmaunder 's response on this thread... http://epygi.com/forum/showthread.php?t=423

    "These phones are actually quite easy to make work. you just setup them up in the Quadro as Sipura841 and enter the MAC address as normal.

    Then you then need to go to the Provisioning tab on the phone and set the Profile Rule to /spa841.cfg and then reboot the phone, that is it. The phone will then be auto-provisioned from the Quadro. This will work for any linksys model.

    FYI For Epygi to support them out of the box, they just need to return the same config file if the required file name is spa???.cfg. this would then work for spa801, spa822, spa842 and spa862."

    I confirmed that this still works even with the new Cisco firmware (basically a cosmetic GUI change anyway)

    I changed the profile rule to spa922.cfg and it worked like a champ.

  4. #4

    Default

    This is not the proper way to do this. These workarounds might have unintended consequences down the road. Epygi should change its' stand and certify these phones ASAP.

    With the advent of new PBX systems from vendors like Snom (PBXnSIP) and Gigaset (Tx00 Pro) who traditionally were only producing handsets for the SMB & Enterprise market segments, Epygi PBX systems are being squeezed out from a lot of potential sales.

    It would be a shame for Epygi to waste all the hard work they have put in so far, and lose potential sales, due to lack of interoperability with new handsets. Now that the QX1000 is out of the door and it can compete with almost any other IP-based PBX, Epygi should concentrate on certifying all the popular new SIP handsets available in the market.

    Otherwise, the integrated solutions of PBX systems with handsets from the same vendor, will win a sizable market segment.

  5. #5

    Default

    Epygi is continuously adding the new phones from main manufacturers to the "supported" list. Please check the firmware release notes for regular updates. If you have specific phone models in your mind that are not supported yet, please let us know.

  6. #6

    Default Support for new SIP UAs

    Please allow me to revise your statement: "Epygi is continuously adding the new phones from main manufacturers to the "supported" list", so it reflects the current state of affairs more accurately:

    Epygi is continuously adding new IP-phones from mainstream manufacturers to the "Tested" list. Not the "Supported" list, which has been languishing with phones from two manufacturers since its' inception in 2007.

    Granted, the inclusion of new IP-phones and ATAs is markedly better on the "Tested" list, but there are some strange absences in its' coverage as well. Prime example, the exclusion of SPA962 when the rest of the Linksys lineup was included in 2008. Could it be that monitoring extensions with the SPA932 was too involved to support?

    A lot of people in this forum have bought, recommended and installed Epygi IP PBX systems for themselves, their colleagues and their clients in the past 10 years. Most of these people have selected Epygi over Asterisk or any other Open-Source solution, for its' custom-built SIP Stack, its' SBC-like architecture, its' built-in PSTN interfaces, and its' hand-&-glove integration with Snom & Aastra IP-phones.

    These people have been served well by Epygi PBX systems in the early years, but have started to bump on a glass ceiling during the past 3-4 years. VoIP based telephony started to take off, a lot of new hardware was introduced to the market at cheaper prices than Snom and Aastra handsets, but their PBX platform of choice who wrote the book on SIP Trunking and Off-Premise extensions, wouldn't allow them to fully utilize other IP-phones or ATAs officially.

    Clearly this state of affairs will not work in the current economic climate. Epygi should became the PBX which works with almost any stable SIP UA. This includes desktop IP-phones, ATAs, PC and Mobile soft-phone Apps. As such, here is a partial list of SIP UAs that are quite popular, our clients are asking for, and we would like to have official support for:

    Cisco SPA303G
    Cisco SPA50xG
    Cisco SPA525G2
    Gigaset A580 IP
    Gigaset S685 IP
    Gigaset DX800A
    Panasonic KX-TGP550

    Regarding the mobile Apps space, I am aware of the iQall App, but as I stated above, Epygi PBX systems should work with any SIP-based App. iQall is currently available only for iOS, not for Android or Symbian. The Apps below have been widely adopted, are stable and well supported:

    Media5 Fone
    Acrobits Softphone
    Acrobits GroundWire
    ipTel SipDroid

    Having said that, I am well aware that fully testing and certifying each SIP UA, with every firmware update available, takes an inordinate amount of time. So, here is what I propose to lighten your burden:

    Publish a spec with all the call scenarios each phone has to pass, in order to be included on the tested list or on the supported list. The interested users in this forum will form a group to perform all or part of the tests, depending on their ability to execute each call scenario properly. For each call scenario to be complete, a SIP and RTP trace will have to be included. At least 3 other forum users will have to confirm the specific phone passed each call scenario.

    If there are issues which point to non-standard SIP behavior, we will contact the manufacturer or ask you to do so, supplying you with the relevant packet traces. During our tests you will produce a patch for each phone based on its' capabilities, so we can test provisioning it as a supported phone on an Epygi IP PBX.

    When all issues have been resolved, you can briefly test each call scenario with SIP UAs residing on Public IPs, in order to ensure we haven't forgotten anything. Based on the relevant success of each SIP UA, you will decide on which list it ends up on, and what additional tests might be advisable to pass in the future.

    I believe most users in this forum, would like to continue recommending, and installing Epygi PBX systems, instead of having to deal with inferior PBX solutions from Gigaset, Snom or Cisco. So they have an inherent interest in helping certifying SIP UAs, and are hopefully keen to help out.

    Thanks for listening.

  7. #7

    Default

    Thank you for the detailed response. Please keep in mind that when IP phones are selected for testing, we decide based on feedback from the IP phone manufacturer, what devices to test and certify. In most cases we test one devices that uses identical configuration files as 'other' models in that range. The 'other' models also fall under the same configuration file layout and will use the same auto configuration template.

    Epygi recommends that our partner installing IP phones that are not on the Epygi list, check with the IP phone manufacturer to determine if the model will work with a configuration template of another model that has been tested. This the best approach for the most current information.

    Please understand that we will only list devices that we have officially tested and continue to test for the supported life of that device. A list covering every variation will never exist because it is not efficient to test 4 devices that all work identically the same from a configuration and setup perspective. We hope this is an acceptable approach.

    Since Epygi does not manufacture our own IP phone, we go to great lengths to test with all the best of breed IP phones on the market. Brands of IP phones that make it into the higher level of supported phones is purely based on the IP phone firmware and flexibility to support our advanced features like plug-and-play setup. Not all IP phone manufacturers support that level of flexibility and in some cases can be very reluctant to work with an open standards IP PBX manufacturer. A sad position open standards products.

    However, any SIP device that conforms to the SIP standard will work with the Epygi products. We do not build in restrictions to our product to limit who you can work with. If there are real issues supporting a SIP device and the device manufacturer has already attempted to resolve the issue, Epygi will investigate the issue further.

    As for the iQall application, the Android version will be release in a week or so. There have been a few press release recently about this. Also we are looking for a few more beta testers. Please keep in mind the iQall application is not a softphone. Epygi supports all open SIP softphones on the market, so feel free to pick the one you like best. For more details on the iQall, please review the products section for this feature. http://www.epygi.com/quadro-software-apps/250#iqall

  8. #8

    Default

    Thanks for replying in such detail. Let me start by saying that I am fully aware about the level of pain incurred when dealing with most established IP-phone manufacturers. Especially the ones that don't seem to have a clear product strategy, or have gone through a few transformations and/or acquisitions.

    I am also aware about the difficulty in establishing a working relationship with a subject matter expert belonging to the staff of any IP-phone manufacturer. And then have to do this over again, when they get re-assigned to other projects, departments, or get laid off.

    I know this will sound as an oxymoron, but the information provided by most IP-phone manufacturers about their product line, should be taken with a grain of salt. Most of the time, their developers are not even aware about crippling bugs in their phones, and their Ivory tower complex doesn't help them discover them quickly enough.

    On the other hand, IP-PBX & IP-phone administrators live with their shortcomings every day. All I propose is that, after you talk to the IP-phone manufacturers, talk to us as well through the forum. We are bound to have tested that phone in the field, and chances are we might have formed a preliminary opinion for it already. If you release at that time a basic template for it so we can provision it as a non-generic IP Line, we would be able to inform you rather quickly what works or not.

    Consider that, if you -an established IP-PBX manufacturer- have such difficulty, to communicate with the right staff-member at an IP-phone manufacturer, imagine how unlikely it is for an IP-PBX installer to do so. Highly unlikely to say the least. So most of us resort to trial and error. If the IP-phone at hand is SIP compatible, it is bound to work with an Epygi PBX.

    Most of the times they do, but not all their lines might be usable, or the BLF feature might not work properly. At least having a preliminary phone template will allow the Epygi PBX to recognize all of its' available extensions.

    I am also painfully aware that "Not all IP phone manufacturers support that level of flexibility and in some cases can be very reluctant to work with an open standards IP PBX manufacturer. A sad position for open standards products." But, here is where we can make a difference. A few of us have some leeway in pressuring the IP-phone manufacturers, to support features we require, when their sales departments are harping at us to buy more of their products. When their next quarterly bonuses are at stake, they will pull strings and get things done with their developers. It certainly does not happen often, but we are in a better position to get results than you are, with certain IP-phone manufacturers.

    When it comes to soft-phone developers, reaching them is generally easier and less of a hassle. Similarly to testing and certifying IP-phones, soft-phones should be integrated as easily as tested IP-Phones in the IP Lines section. In offices with WiFi coverage, soft-phone Apps running on smart-phones, can replace DECT-based SIP phones albeight with some limitations.

    Give us the tools which allow us to help you certify more IP-phones and soft-phone Apps quicker. I am convinced that Epygi's success will be increasingly dependent on it.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. cisco 79xx
    By bsnquadro in forum Hardware Interoperability
    Replies: 6
    Last Post: 05-19-2008, 08:18 PM
  2. Cisco IP phones 7940
    By bsnquadro in forum Hardware Interoperability
    Replies: 3
    Last Post: 02-22-2008, 02:52 AM
  3. Cisco 7941
    By centina in forum Hardware Interoperability
    Replies: 0
    Last Post: 11-28-2007, 12:32 PM
  4. How to configure a Cisco 7970 IP Phone
    By manderson in forum Hardware Interoperability
    Replies: 5
    Last Post: 10-02-2007, 09:19 AM
  5. ENHANCED SUPPORT FOR CISCO PHONES
    By bhummel in forum 'How Do I' Questions
    Replies: 3
    Last Post: 08-02-2006, 04:55 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •