Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

New cloud test, general questions, looking for help.

Discussion in '3CX Phone System - General' started by yitaozhu, Oct 7, 2017.

Thread Status:
Not open for further replies.
  1. yitaozhu

    Oct 7, 2017
    Likes Received:
    Hi .

    I just actived cloud server for test , no technical support yet, confused with some feature, looking for help ,will be really appreciate!

    1. Is the 3CX cloud server a good option for manage multi business customers ? considering network risk to build my own server, I prefer to try 3CX cloud server, I want to serve more small business customers who will have 5-20 remote extensions ( want to use cisco SPA303/504G..), but I didn't see any settings can group some extensions to different sub-companies,most time company's extensions start from 101..., the cloud seems can't accept same extension number, so will the 3cx cloud server be good option for me to serve more business customers? is any addon feature for billing customers?
    2. I tried to provision remote cisco 504g (firmware7.6.1), no lucky. The extension provision method option only show local lan (in office), no option of SBC, do some search , from :
    Known limitations of Cisco SPA 302, 303, 501G, 502G, 504G, 508G, 509G, 512G, 514G, 525G, 525G2 are:
    No PnP Support
    • No STUN Support
    • No SBC Support
    • No Full CTI Support (Make Call Only)
    • BLF Functionality (only on applicable models)
    • Company Phone Book with limited size only
    • Manual DST Support
    Is this means cloud will not support provision these cisco ip phones remotely ? cisco SPA5XX is so popular ,if not supported ,what is the cloud feature use for ? Have to install 3cx to my own server in order to use remote extensions ?

    Also uncheck "Disallow use of extension outside the LAN" , and tried add my public/local ip to block ip list:
    not working

    from my browser:
    https://<3cxremoteip>/provisioning/<folder>/<mac>.xml can be reach and see the detail settings,
    http://<3cxremoteip>/provisioning/<folder>/<mac>.xml is not reachable.

    Thanks a lot if someone can make it clear. BTW , this kind of general question will not be answered by 3CX offically ? How customers can make decision before buy if nobody response ?
  2. Nick Galea

    Nick Galea Site Admin

    Jun 6, 2006
    Likes Received:

    A short answer to your questions:

    a. You need to make a separate 3CX PBX instance for each customer.
    b. You can not use Cisco phones for 3CX PBX instances in the cloud. You must use a supported phone.
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #2 Nick Galea, Oct 7, 2017
    Last edited: Oct 7, 2017
  3. Sopock

    Sopock Member

    Jul 11, 2012
    Likes Received:
    You can also find this interesting blog:
    We chose Cisco as phone vendor, since phones themselves were of quite good quality and relatively easily customizable. We are talking about Cisco Small Business SPA500 series —originally Linksys products before Cisco bought them. This fact becomes important once we start implementing encryption on these phones.
    For the server side our choice of vendor fell on 3CX, a European company with a sound product with close to being non-proprietary in their implementation of SIP. Hence, further along the lines we will be assuming 3CX as our server-side component.
    Cisco phones came with a pre-installed client certificate and a small list of root certificates that could be trusted. That meant that we would have needed to obtain a certificate for our provisioning server and for our SIP server, signed by Cisco. Indeed, there was a known way to do so, well described on a Cisco support site. It basically said that you would need to generate a certificate request and submit it to Cisco to be signed. It even provided an email-address to send the requests to, but the submission could only be initiated by an official Cisco distributor. We contacted two distributors regarding the task and none of them was even able to understand what we wanted from them, since they had never heard about Cisco SPA phones in the context of
    secure SIP.
    We opened a case with Cisco partner support and, after a week or two emailing back and forth we were able to find a person responsible. A few days later we finally got a signed certificate and were able to install it on the web server (to ensure secure provisioning) and on the SIP server (for SIP/TLS to work). Although SIP/TLS did not work right away, things started moving.
    By now we knew that both Cisco and 3CX used OpenSSL for their implementation of TLS. We looked at how OpenSSL handles these types of requests and saw that it was a matter of linkage options in order for it to start working. It took us some effort to persuade 3CX to investigate the issue, but it took 3CX almost half a year, including QA, to implement the change. Although thankfully, we were provided with a private patch that had the needed functionality and were able to carry on with our findings.

    So, we had to obtain a new certificate that was (a) publicly trusted, (b) trusted by Cisco and (c) was wildcard-capable, because we needed to repurpose it for many different things within our VOIP infrastructure. This normally would not be an accomplishable task — at least during our first experiments — since Cisco phones did not support any third-party certificates. All had to be signed by Cisco. For reasons that now can only cause speculation, and that even Snowden might have an idea about the purpose of such a policy, Cisco suddenly had a pleasant surprise for us in their pipeline.
    Let us see:
    • Asynchronous communication as such is complicated
    • Telephony as such is complicated
    • Interoperability between vendors as such is complicated
    • Cryptography is in many ways (very) complicated
    Had not Cisco imposed restrictions on their PKI we would have been able to use trusted certificates from the very beginning. Had 3CX implemented the integration with OpenSSL correctly we would have been able to use Cisco phones from the very beginning. Had Snom implemented the PKI in their phones properly we might have switched to Snom from the very beginning. Had Cisco used the same code-base for the whole product line we would have not lost so much time scratching our heads over why SPA525 was the only funny phone among the rest of the family. And finally, had Microsoft implemented TLS 1.2 properly all this would finally just work as intended — especially if we think about the fact that the life of TLS 1.0 is coming to an end.
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.