V16 Update 3 is Here. More secure, user friendly and with HubSpot CRM Integration.

Do we have an ETA on when mobile apps are coming that work with this update?
Android soon, IOS still has a little work, but shouldn't be too far away either.
Sorry, can't be more specific for the time being.
 
I personally prefer the web-client. Are there any plans to have BLF to mimic your desk phone's in the future?

Hi @kent3

The webclient already allows you to set BLFs for your deskphone from its settings.

Also, your colleagues extensions appear like a busy lamp field in the webclient anyway, and you can see who is busy or not and also their statuses. It really just depends on your screen resolution and number of extensions
12515

Just click the Star to make them favorites, and then click on the favorites tab. You now have a custom BLF list in front of you
 
Thanks, yes I am aware you can edit BLF but what I would like is to see is my speed dials and custom speed dials and park keys on the web-client.

Will this come?
 
for the website chat i have entered an email address in my wordpress plugin settings but form the email icon on the chat box it come up with config.emailIntegrationUrl how do i fix this?
Please update to version 1.5.3 version of the WordPress that addresses this issue.

Thank you for your feedback
 
I was really excited to see:
Secondary Proxy – enable the “Alternative Proxy” option and set a secondary proxy host, if supported by your VoIP provider. This method simplifies SIP trunk and DID management, helping you to avoid maintaining two SIP trunks for failover reasons.
However, I'm having issues with implementation. I've gone to the trunk > Options > Checked the Alternative Proxy box > added the 2nd IP of the provider.
I made inbound test calls to the DID on this trunk.
One of the calls came from the provider's primary IP and was accepted as expected.
However, two of the calls came into 3CX from the provider's secondary IP (which I entered in the Alternative Proxy field) and 3CX rejected the invite (SIP Status 403 Forbidden). The calls were then delivered via the primary IP without issue.
In the activity log I see:
Code:
10/04/2019 10:52:55 AM - L:21.1[EndCall:EndCall] Sending: OnSendResp Send 403/INVITE from 0.0.0.0:0 tid=0cB3b1b984d927def0d Call-ID=913048324_105592709@<secondary IP>:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP <secondary IP>:5060;branch=z9hG4bK0cB3b1b984d927def0d
To: <sip:+1XXXXXXXXXX@<3CX Server IP>>;tag=9bce7342
From: "NAME" <sip:+1XXXXXXXXXX@<secondary IP>;isup-oli=62>;tag=gK0c403a6b
Call-ID: 913048324_105592709@<secondary IP>
CSeq: 17170 INVITE
Warning: 499 <FQDN> "Caller is not identified"
Content-Length: 0

I'm assuming the proxy option should work for both origination and termination. Was that not correct?

edit
May have answered my own question, the secondary proxy only applies to outbound calls in my testing. I switched the primary and secondary IPs and retested.
All calls that came in on the IP now entered in the secondary proxy field were rejected by 3CX but outgoing calls were successful.
But why would the blog state this would simplify DID management? If we still have to have a 2nd trunk for the secondary IP, we'd still have to enter all the DIDs a 2nd time and assign them a 2nd time in case the call was delivered to 3CX via the secondary IP.
Am I missing something?
 
Last edited:
@mcbsys The Windows client will not always exist. A windows softphone will, thats a different thing. Client side CRM integration has been deprecated already.
 
  • Like
Reactions: Evolute IT
@mcbsys The Windows client will not always exist. A windows softphone will, thats a different thing. Client side CRM integration has been deprecated already.
Will there be TAPI support for the foreseeable future in the Windows softphone?
 
@accentlogic - Yes absolutely. Who knows we might make it work with our new Google Extension web client which is coming together nicely.....
 
Last edited:
Code:
10/04/2019 10:52:55 AM - L:21.1[EndCall:EndCall] Sending: OnSendResp Send 403/INVITE from 0.0.0.0:0 tid=0cB3b1b984d927def0d Call-ID=913048324_105592709@<secondary IP>:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP <secondary IP>:5060;branch=z9hG4bK0cB3b1b984d927def0d
To: <sip:+1XXXXXXXXXX@<3CX Server IP>>;tag=9bce7342
From: "NAME" <sip:+1XXXXXXXXXX@<secondary IP>;isup-oli=62>;tag=gK0c403a6b
Call-ID: 913048324_105592709@<secondary IP>
CSeq: 17170 INVITE
Warning: 499 <FQDN> "Caller is not identified"
Content-Length: 0

I am not sure which provider you are using but
Warning: 499 <FQDN> "Caller is not identified"
indicates me that for your test the source identification settings do not work and the result which trunk this call belongs to is not 1 (unique)
 
I was really excited to see:

However, I'm having issues with implementation. I've gone to the trunk > Options > Checked the Alternative Proxy box > added the 2nd IP of the provider.
I made inbound test calls to the DID on this trunk.
One of the calls came from the provider's primary IP and was accepted as expected.
However, two of the calls came into 3CX from the provider's secondary IP (which I entered in the Alternative Proxy field) and 3CX rejected the invite (SIP Status 403 Forbidden). The calls were then delivered via the primary IP without issue.
In the activity log I see:
Code:
10/04/2019 10:52:55 AM - L:21.1[EndCall:EndCall] Sending: OnSendResp Send 403/INVITE from 0.0.0.0:0 tid=0cB3b1b984d927def0d Call-ID=913048324_105592709@<secondary IP>:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP <secondary IP>:5060;branch=z9hG4bK0cB3b1b984d927def0d
To: <sip:+1XXXXXXXXXX@<3CX Server IP>>;tag=9bce7342
From: "NAME" <sip:+1XXXXXXXXXX@<secondary IP>;isup-oli=62>;tag=gK0c403a6b
Call-ID: 913048324_105592709@<secondary IP>
CSeq: 17170 INVITE
Warning: 499 <FQDN> "Caller is not identified"
Content-Length: 0

I'm assuming the proxy option should work for both origination and termination. Was that not correct?

edit
May have answered my own question, the secondary proxy only applies to outbound calls in my testing. I switched the primary and secondary IPs and retested.
All calls that came in on the IP now entered in the secondary proxy field were rejected by 3CX but outgoing calls were successful.
But why would the blog state this would simplify DID management? If we still have to have a 2nd trunk for the secondary IP, we'd still have to enter all the DIDs a 2nd time and assign them a 2nd time in case the call was delivered to 3CX via the secondary IP.
Am I missing something?
The reason the blog post states that it would simplify DID management is because up to now, there were quite a few users that were creating 2 SIP Trunks to have outbound resilience so they could put 1 IP in each.
This also lead to them having sometimes to create DIDs multiple times in both trunks and duplicate Inbound rules (not all cases, but in some yes).
So, giving this ability to use a secondary proxy, it makes life easier.
 
  • Like
Reactions: accentlogic
Hello @pmterp

Can you tell us which provider you are using and how the provider is setup? Do you only have one trunk from the provider? Are the DIDs in multiple trunks?
Do you have source identification enabled on the trunk?

As you correctly noted the Alternative proxy option is used by the PBX for outbound calls. If you primary IP is not responding then the PBX will try the alternative proxy address. For Inbound calls the PBX works the same as before.
If you have multiple trunks with the same DIDs or you have the source identification option enabled along with the "Use both "Call Source Identification" rules and "Caller Number/Name -> CalledNum" field mappings (Note: Disables catch all routing capability) " option then i would recommend disabling those and deleting any extra trunks. Then try again.
 
Why have you guys added those ugly apple store and google play store icons in the webclient?
The webclient was fine the way it was. After updating this weekend my customers are calling me today what the icons mean and what they should do with it. It is confusing. Especially since I told them last months to focus on the webclient as it has everything they need.

If those icons really need to be in the webclient, can they be moved to this page: /webclient/#/settings/qrcode
It would make more sense to have them there anyway.
 
The reason the blog post states that it would simplify DID management is because up to now, there were quite a few users that were creating 2 SIP Trunks to have outbound resilience so they could put 1 IP in each.
This also lead to them having sometimes to create DIDs multiple times in both trunks and duplicate Inbound rules (not all cases, but in some yes).
So, giving this ability to use a secondary proxy, it makes life easier.

Interesting. One of the providers we use has multiple IPs for incoming and outgoing (for failover) and we had setup multiple incoming and outgoing trunks to accommodate.
I see the value in adding the DIDs to the trunks used for incoming so calls are routed appropriately regardless of the IP that delivers the call but not for outgoing, I don't understand the value in adding the DIDs to the outgoing trunks.

Hello @pmterp
As you correctly noted the Alternative proxy option is used by the PBX for outbound calls. If you primary IP is not responding then the PBX will try the alternative proxy address. For Inbound calls the PBX works the same as before.
This answers my question, thank you. I do appreciate this update that allows for the outbound proxy.
I'd love to see a future enhancement that would allow the trunk to receive calls from multiple designated IPs to eliminate the need to add the DIDs to multiple trunks and then assign each one.
 
This answers my question, thank you. I do appreciate this update that allows for the outbound proxy.
I'd love to see a future enhancement that would allow the trunk to receive calls from multiple designated IPs to eliminate the need to add the DIDs to multiple trunks and then assign each one.
By default the PBX does not mind where the calls are coming and can match calls by DIDs only. So even if calls do come in through different IPs the PBX will accept them. That of course depends on the trunk configuration. You can see how the PBX matches the call with a trunk here:
https://www.3cx.com/docs/sip-trunk-inbound-calls/
 
  • Like
Reactions: accentlogic
Ran into some issues this morning after installing update 3 over the weekend.
Came in this morning to SIP trunks not registering.
Had to make a change to the timeout and within the sip setting had to select the auto discovery options.
 
Why have you guys added those ugly apple store and google play store icons in the webclient?
The webclient was fine the way it was. After updating this weekend my customers are calling me today what the icons mean and what they should do with it. It is confusing. Especially since I told them last months to focus on the webclient as it has everything they need.

If those icons really need to be in the webclient, can they be moved to this page: /webclient/#/settings/qrcode
It would make more sense to have them there anyway.

I agree with this. Just noticed it on my beta system and they look like adverts. They dont fit well with the theme at all. They should be with the QR code.
 
Just installed 3CX this morning, sent out a welcome email and the links to the Mac/Windows soft-phone have been removed as well as the provision attachment. Is this the death of the Mac/Windows client?

Sorry the provisioning attachment is there but the link isn't
I agree, can you please put the download links for the desktop clients back into the welcome email. A lot of customers still use and like this client and don't want to swap over to the web based one.

It's much easier for us to delete the links from the template if they are not required than for us to have to put them back in manually if they are not there.

thanks
 
Can you confirm if the changes to Speech-to-Text transcription have been released in v16 Update 3? I'm waiting for the ability to selectively transcribe voicemails but not call recordings which I believe was due in this version
 
Can you confirm if the changes to Speech-to-Text transcription have been released in v16 Update 3? I'm waiting for the ability to selectively transcribe voicemails but not call recordings which I believe was due in this version
Yes. The option has been added in Settings -> Voicemail -> Transcription
 

Latest Posts

Forum statistics

Threads
111,990
Messages
590,164
Members
164,926
Latest member
tohoken1