New cloud test, general questions, looking for help.

[yitaozhu]

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 :
https://www.3cx.com/community/threa...with-3cx-15-5-cloud-hosted.49640/#post-201542
Limitations
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:
allow 192.168.0.0/16;
allow 172.16.0.0/12;
allow 10.0.0.0/8;
allow 127.0.0.1;
not working

from my browser:
https://<3cxremoteip>/provisioning/<folder>/<mac>.xml can be reach and see the detail settings,
but
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 ?

 

[N_G]

Hi,

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.

 

[Sopock]

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 ?

You can also find this interesting blog:

Spoiler: IV. Enter 3CX

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.