V16, Update 7 Alpha Sports FB & SMS Business Messaging and Live Chat Improvements

[Evolute IT]

@Frederick Marcoux @Mika Olkkonen Are you both using Chrome 86.0.4240.111?

Yes.

Version 86.0.4240.111 (Official Build) (64-bit)

 

[Kevin@voxtelesys]

Thank you for your reply. I'm not a reseller. I've an in-house installation and moved from FreePBX to 3CX due to the benefits it provides (mainly ease of administration and softphone capability). I recently invested in 3CX because I do feel it's a great product. I appreciate the due diligence angle you put forward, but if everyone only invested in the 'now' and not the 'future' very few new products would come to light. I just think it's a bit of a shame that something that one would think is relatively easy to implement (bear in mind nobody from 3CX has said otherwise) couldn't have been 'squeezed' into an update. I do appreciate that with the COVID-19 situation that priorities have moved somewhat, but nonetheless, this is a 5yr old request.

We have customers that use a prefix to send different caller IDs. We just set them up with IP authentication, then they can setup as many trunks on the 3CX with outbound rules based on a prefix.

 

[RadDadIT]

I'm running the Debian ISO image instead of Windows and I've tried using just xxxxxxxxxx, 1xxxxxxxxxx, and +1xxxxxxxxxx and the only one that works for outbound was the 1xxxxxxxxxx. I even had all 3 in the routes at the same time to see if that did anything and it still didn't work. Plus I'm just using the LetsEncrypt certificate that 3CX auto-renews so there shouldn't be any issue with it.

UPDATE!!!
Ok, I did some playing around, and tried with several different numbers. In particular, I added another number from Flowroute in e.164 format to the routes in 3CX and had both numbers routing to the same extension. I also selected the new route for outbound on that extension. Next I tried sending a text to an e.164 formatted number from 3CX and the text went through fine with the exception that it tried routing them through the old number and not the new number. So I initiated a text from the remote number (outside of the system) to the new number I added in Flowroute and incoming worked. Then when I tried replying to it from 3CX, that worked as well but it did use the new route this time. I'm going to try using the old number again and see what I can come up with.

Just to follow up on this in full, I finally got the original number working as well. They are using the +1xxxxxxxxxx format on the routes and the final issue ended up being that with Flowroute you can set a global callback URL, but you can also set a per-DID callback for instances where you need a specific number to use a different callback than the global callback. Way back when SMS was released with Flowroute, I remember playing with their API and evidently set a specific callback URL for that number I tried using to test with on 3CX. Talking with Flowroute support, there is no way to reset this DID to use the global callback anymore and it must be set independently from now on. While this is frustrating, it was an easy fix using a linux command prompt with this command (filling in your appropriate values where needed):

curl https://api.flowroute.com/v2/numbers/1xxxxxxxxxx/relationships/sms_callback -H "Content-Type: application/vnd.api+json" -X POST -d '{"data": {"attributes": {"callback_url":"https://messaging.3cx.com/v1/webhook/XXXXX-XXXXX-XXXXX-XXXXX-XXXXX/flowroute/sms/xxxxxxxxxxxx"}}}' -u access_key:secret_key

 

[Mika Olkkonen]

@Frederick Marcoux @Mika Olkkonen Are you both using Chrome 86.0.4240.111?

Yes, Chrome and same version.

 

[N_G]

Thanks for the information Nick, I don't think it has been fedback before that it's a complex task. Unfortunately the reason why people require Outbound Caller ID set on an Outbound rule is that an extension is required to use multiple caller IDs (multiple clients). Out of interest, what is the difference between assigning an outbound cid based on extension opposed to an outbound rule as far as the SIP trunk is concerned? The trunk would have the DID number assigned to it from a security point of view.

Thank you for the explanation, thats a good point. We are looking into this functionality for the next version which should come after update 7 (its not that far off this new version) When i have more info I will revert...

So we checked into this and its doable to have an outbound caller ID set in an outbound rule. If so it would override the extension caller ID. So

1. if OutboundID set in Outbound Rule, use this value (<-- includes emergency calls)
2. else if OutboundID set in the extension, use this value
3. else if OutboundID set in the trunk, use this value
4. else use trunkID

Would this resolve your issue?

 

[davide.bonavita]

Thank you for the explanation, thats a good point. We are looking into this functionality for the next version which should come after update 7 (its not that far off this new version) When i have more info I will revert...

So we checked into this and its doable to have an outbound caller ID set in an outbound rule. If so it would override the extension caller ID. So

1. if OutboundID set in Outbound Rule, use this value (<-- includes emergency calls)
2. else if OutboundID set in the extension, use this value
3. else if OutboundID set in the trunk, use this value
4. else use trunkID

Would this resolve your issue?

OMG That would be great Nick, we are waiting for this feature for years! We have customers scattered all around the world and we would love to call them using our local DIDs we have registered in their country so that they can call us back making a local call.
We can't do it right now as we have several DID and several SIP Providers that don't support multiple registrations.

 

[CentrexJ]

1. if OutboundID set in Outbound Rule, use this value (<-- includes emergency calls)
2. else if OutboundID set in the extension, use this value
3. else if OutboundID set in the trunk, use this value
4. else use trunkID

Amazing. Ideally both " From : Display Name " and " From : User Part " via outbound rules both fields following the rules set above.

 

[James_K]

Thank you for the explanation, thats a good point. We are looking into this functionality for the next version which should come after update 7 (its not that far off this new version) When i have more info I will revert...

So we checked into this and its doable to have an outbound caller ID set in an outbound rule. If so it would override the extension caller ID. So

1. if OutboundID set in Outbound Rule, use this value (<-- includes emergency calls)
2. else if OutboundID set in the extension, use this value
3. else if OutboundID set in the trunk, use this value
4. else use trunkID

Would this resolve your issue?

Perfect, Thanks @Nick Galea

 

[Evolute IT]

Thank you for the explanation, thats a good point. We are looking into this functionality for the next version which should come after update 7 (its not that far off this new version) When i have more info I will revert...

So we checked into this and its doable to have an outbound caller ID set in an outbound rule. If so it would override the extension caller ID. So

1. if OutboundID set in Outbound Rule, use this value (<-- includes emergency calls)
2. else if OutboundID set in the extension, use this value
3. else if OutboundID set in the trunk, use this value
4. else use trunkID

Would this resolve your issue?

Except for the emergency calls part, I fully agree. Having this in the outbound rules allow to use prefix to change CID and also, have the same route twice but with different CID based on the calling extension. This would work and my guess is it's relatively easy to do based on the current structure of the system.

 

[StefanW]

Amazing. Ideally both " From : Display Name " and " From : User Part " via outbound rules both fields following the rules set above.

From Display is taken from your settings of the Trunk. If this is equal to the From User then both will be the same.

 

[CentrexJ]

From Display is taken from your settings of the Trunk. If this is equal to the From User then both will be the same.

In Canada and the US we have Number and Name Caller-ID. To provide changing the Number display on the outbound rule would be a great feature, but to allow also changing the Name display on the outbound rule would circle both boxes. We wouldn't want to make them be the same, we would want a Name on the name display and a number on the Number display.

 

[StefanW]

In most cases, the Name will be stripped by the providers when routeing this to another provider.
Therefore register your CNAME on the provider for the DID in question and the remote system can do the lookup for the number. Display name will not be added from our end to be altered separately.

 

[Evolute IT]

In Canada and the US we have Number and Name Caller-ID. To provide changing the Number display on the outbound rule would be a great feature, but to allow also changing the Name display on the outbound rule would circle both boxes. We wouldn't want to make them be the same, we would want a Name on the name display and a number on the Number display.

Agreed.

The basic goal of this feature is to manage CNAME+CID. Not just CID. I will still have many trunks to change the CNAME (outbound params) if not.

In most cases, the Name will be stripped by the providers when routeing this to another provider.
Therefore register your CNAME on the provider for the DID in question and the remote system can do the lookup for the number. Display name will not be added from our end to be altered separately.

I can tell you for a fact, in Canada, it isn't stripped. Also, many providers support the ability to override CID/CNAME on the DID level, but not all. And some do support it, but it doesn't work (which is my current case.)

Also, in Canada, the remote system doesn't do any lookup. We don't have a CNAME DB like the USA, only what the caller provides to the callee.

 

[StefanW]

and you just gave yourself the explanation of why we will not do it!

 

[Evolute IT]

and you just gave yourself the explanation of why we will not do it!

So, we've been waiting 3 years to change just the number via routes? Not even the CNAME. I have to say this is sad. I was really waiting for this because it is used a lot in our cases. Many other PBX (most of them) have this feature, it's called DOD.

 

[StefanW]

you can still do DOD by setting the value From.Display.Name to Extension.Name value and it will overlay the extension name on the given caller ID in the route.

 

[Evolute IT]

you can still do DOD by setting the value From.Display.Name to Extension.Name value and it will overlay the extension name on the given caller ID in the route.

Agreed. But this put the Ext Name in the CNAME field. Which we don't want.

We want to be able to set that CNAME via Ext Groups or outbound rules. So that we can have multiple people use one CNAME and some others use another. Similar to what a lot of people want for multi-company offices (not our case.)

 

[StefanW]

dont place WE on personal requests! In this case, register the CNAME with the Provider. Let's leave it with this as we now detailed outlined what will and what will not be added.

 

[Evolute IT]

dont place WE on personal requests! In this case, register the CNAME with the Provider. Let's leave it with this as we now detailed outlined what will and what will not be added.

I agree. And a lot of people wanted this, not just us.

Our issue is that our provider doesn't have this option. It takes the CID+CNAME from the PBX only. We tried setting the override per DID but it didn't work most of the times. So that's why we really hoped for this in there but okay, we'll live with it.

 

[Kevin@voxtelesys]

Agreed.

The basic goal of this feature is to manage CNAME+CID. Not just CID. I will still have many trunks to change the CNAME (outbound params) if not.


I can tell you for a fact, in Canada, it isn't stripped. Also, many providers support the ability to override CID/CNAME on the DID level, but not all. And some do support it, but it doesn't work (which is my current case.)

Also, in Canada, the remote system doesn't do any lookup. We don't have a CNAME DB like the USA, only what the caller provides to the callee.

The data bases are based on the North American numbering plan so it should not matter if Canada or US. We register Canadian numbers all the time, the only thing that has issues is toll free numbers but that data base is in beta and hopefully coming soon.

If you call a local number in Canada does the CNAM show up? (if that users pays for CNAM dips) If you want to DM me I can do a lookup on some caller IDs you have in question.