URL Handler for Thirdparty app

[Mateo Thiebault]

Hello, I am the developer of a mobile application for notaries.
A number of my clients use your VoIP tool to make their calls. In the contacts section of my application, I offer the option of calling the employee on the number entered via the default calling application.
I intend to offer customers the option of using the VoIP app of their choice rather than the phone app. As your application is one of the options available, I would like to ask you what steps need to be taken to make a call on your application, provided it is installed on the customer's device.
Some of your competitors offer this feature, such as Webex and Rainbow, and allow users to open their app with the number already dialed, using a URI handler and the number to be called as a parameter. I look forward to your response. Have a great day. Thiebault Matéo

 

[VoIPTools]

We provide a REST API that your application can call to place the call. It requires two parameters: (1) the phone extension placing the call, and (2) the other party -- extension or outside number. This implies, however, that they have a phone connected to 3CX. That could be a physical phone, the PWA phone, the web client, or the legacy desktop phone.

 

[Mateo Thiebault]

Thank you for your previous response regarding the REST API. While I appreciate the availability of the Call Control API, I'd like to explain why this approach is not suitable for our use case and suggest a simpler alternative that would benefit many of your customers.

We are developing a mobile app (iOS/Android) where users need to quickly call contacts from within the app. We want to support various VoIP applications, including 3CX.

Current competitor's solution :

• User taps phone number → VoIP app opens instantly → Call starts (< 1 second)
• Examples: Webex uses webextel://, Rainbow uses rainbow://

3CX REST API solution:

• User taps phone number → Loading... → Authentication → HTTP request → Phone rings (3-5 seconds)
• Result: Significantly slower and more complex user experience

With the API Approach, each user would need to configure in our app:

• 3CX server URL (unique per company: pbx.company-a.com, pbx.company-b.com, etc.)
• Client ID
• API Key (secret, shown only once)
• Phone extension number
• Department and role

This is too complex for non-technical end users (lawyers, notaries, etc.).With a URL scheme: Zero configuration needed - just install the 3CX app.

​

Please consider implementing a custom URL scheme for the 3CX mobile app, similar to your competitors like
3cx://call?number=0612345678 or 3cxphone://0612345678
This is a standard feature that would require minimal development

iOS:
- Register URL scheme in Info.plist
- Handle application repenURL: in AppDelegate
- Parse phone number and trigger call

Android:
- Register intent filter in AndroidManifest.xml
- Handle intent in Activity
- Parse phone number and trigger call

 

[KyriacosS_3CX]

For this type of suggestion we have the Ideas section of the Forum, but a partner with enough privileges needs to post it there, so that the request can gain traction

Thank you for describing the scenario in detail. I am sure the relevant team will give it due attention. There is generally what we consider to be good reason behind not permitting a URL based direct dial, but your scenario could be different and worth a look at.

 

[Mateo Thiebault]

Thank you for your reply. So, if I understand correctly, I cannot post in this section myself; I have to wait for a partner to do so.

I remain available if you have any questions about implementation or requirements. Have a nice day.

 

[VoIPTools]

3CX does support the tel: protocol. You would need to have a registered phone, but it works like any other Tel: based solution.

 

[Mateo Thiebault]

3CX does support the tel: protocol, but the user must have registered this application as the default app in their phone settings.
This is not what our users want, and it is not the workflow we have created in our app.

Within our application, users can choose a default app through which calls will be routed between different VoIP services such as yours, Rainbow, Webex, and others.

This choice only affects calls made through our app and not the rest of their phone.

That's why we need a protocol that allows us to launch a specific app.

 

[VoIPTools]

I just re-read your previous posts and you are looking to customize how the 3CX mobile phone works. That is even more restricted because 3CX does not provide an API for modifying any of their client applications -- mobile, PWA, Web, Physical, or Legacy desktop.

With that constraint, I don't know by what magic you are expecting to initiate a phone call, but, if you want to use the tel: protocol, then YOUR application is going to need to instruct Windows what phone device to use. That's how the tel: protocol works.

3CX is a SIP standard phone system, and they do not provide any facility for changing how their clients work. That fact means you cannot incorporate a proprietary protocol for accepting a request and initiating a phone call without another piece of software that can accept the proprietary request and instruct the phone to place a call.

You could build your own proprietary softphone that can both register with 3CX, and also respond to a proprietary (non-SIP standard request). We did something similar recently (not easy). But recreating all the functionality built-into the 3CX clients would be a significant effort. It is certainly possible to do, but where is that funding going to come from? From you?

Remember, I'm not 3CX. You would have to make a very, very compelling proposal for us to even consider making that kind of investment. And forget mucking with physical phone firmware - that is completely infeasible.

In the end, this is most likely going to require 3CX make a change to their client applications, and so far I have not heard anything from you that would remotely justify 3CX making the necessary changes. But, I do not know anything about your customer base (number of paying customers). I suppose if you have zillions of existing customers that are all asking for a 3CX integration, maybe...