VOIP.ms no IP-based auth

[NateDoc]

Just checking to see if 3CX is now forcing all newly-configured SIP trunks to be reg-based instead of IP auth? We've used IP-based for VOIP.ms for years now and prefer it for various reasons. Or do we have to use a generic SIP trunk now?

 

[Guillaume Bourgeois]

We've used IP-based […] prefer it for various reasons

Could you tell us your reasons? The fact that failing to detect whether the SIP proxy is down or up should normally be enough to convince you to switch to REGISTER. It also allows switching to the secondary route without attempting the primary one if the proxy is down.

Otherwise, you would have to export your configuration, modify and import it, or use the generic template, but… this is not the right strategy.

Especially with the new rInstance parameter, which only works in “REGISTER” mode.

 

[NicholasP_3CX]

Voip.ms is a supported provider and can be configured with a username and password.

Please see our guide for voip.ms https://www.3cx.com/docs/sip-trunk/voip-ms-canada/

 

[NateDoc]

Could you tell us your reasons? The fact that failing to detect whether the SIP proxy is down or up should normally be enough to convince you to switch to REGISTER. It also allows switching to the secondary route without attempting the primary one if the proxy is down.

Otherwise, you would have to export your configuration, modify and import it, or use the generic template, but… this is not the right strategy.

Especially with the new rInstance parameter, which only works in “REGISTER” mode.

We started setting them up with IP auth primarly due to the simplicity of setup along with better security as well as removing one point of failure (registration). The main benefit at the moment is for a handful of clients that require separate outbound profiles to change caller ID / call display name based on a dialing plan rule. With IP auth, we can have multiple SIP trunks configured to handle this for the same account with different CID/CDN configured on the trunk, which you can't do with the register method. If 3CX provided a method for callers to change their CID/CDN on the fly (outbound rule or other easy method) then we wouldn't need this specifically any further. There are a couple other reasons, but they're escaping me at the moment.

 

[NicholasP_3CX]

You can change the CID that is sent to the provider with an outbound rule.



That would then be on the provider if they accept it or not.



Specifically it is a limitation from the providers side that they do not accept different caller IDs, hence your requirement for multiple accounts from the provider.

However if you look at the configuration guide, I can see that in step 4, they have the option for the PBX to pass its own Caller ID to the provider.

You may need to clarify this with them.

 

[Guillaume Bourgeois]

with better security as well as removing one point of failure (registration).

Security? No problem, you can be registered and still apply an IP restriction.
As for CallerID, I can't explain it any better than Nicholas already did.

Personally, I think you should revisit your strategy. Don't be like those who complain about progress and resist taking advantage of changes, even when they are far more beneficial. Protocols change, solutions evolve, and so do best practices.

Be better!

 

[rayfield]

We started setting them up with IP auth primarly due to the simplicity of setup along with better security as well as removing one point of failure (registration). The main benefit at the moment is for a handful of clients that require separate outbound profiles to change caller ID / call display name based on a dialing plan rule. With IP auth, we can have multiple SIP trunks configured to handle this for the same account with different CID/CDN configured on the trunk, which you can't do with the register method. If 3CX provided a method for callers to change their CID/CDN on the fly (outbound rule or other easy method) then we wouldn't need this specifically any further. There are a couple other reasons, but they're escaping me at the moment.

I've done this for years, while using Register-based authentication. Actually, with our VoIP service, I use both Register-based AND IP-based authentication. So 3CX is set up for Register-based and our Proxy Servers look at both the Username/Password AND the IP address from which the Registration Request is coming. IP addresses can be spoofed, so this makes it harder for hackers to 'mimic' a customers' registration information, since they would have to Username/Password AND IP address.

John Rayfield, Jr.

 

[NateDoc]

You can change the CID that is sent to the provider with an outbound rule.



That would then be on the provider if they accept it or not.



Specifically it is a limitation from the providers side that they do not accept different caller IDs, hence your requirement for multiple accounts from the provider.

However if you look at the configuration guide, I can see that in step 4, they have the option for the PBX to pass its own Caller ID to the provider.

You may need to clarify this with them.

Hi Nicholas,

I'm aware of this method but it doesn't allow for the change of the Call Display Name, which is static per sip trunk connection. If we had a variable way of managing that instead of having to use multiple sip trunks, I'd use it. Feature request perhaps?

 

[Guillaume Bourgeois]

doesn't allow for the change of the Call Display Name,
[…]
Feature request perhaps?

CNAM provide by the PBX is a feature for Canada, typicallly.
The ILECs in the U.S. do not support it.

Learn more about an external source :
https://en.m.wikipedia.org/wiki/Calling_Name_Presentation​

Instead of configuring your trunks in an unsupported or non-recommended way, you should follow the recommendations. There are good reasons why these recommendations are in place.

If you wish to use a feature that is specific to Canadian providers, you should ask your provider to offer this solution. I don’t see why 3CX would provide a solution that only benefits Canada.

Some providers offer the possibility, for outbound calls, to set the CNAM based on various conditions such as the source number (CallerID) .
Check with voip.ms, they might support this feature !

 

[NateDoc]

Regardless of it being a Canadian-only (at this time) use case, it is something we need. Forcing our hand without much or any communication regarding these configurations is a bit frustrating. If it is 3CX's stance to move away from IP auth, it'd be good to know about it officially. Our carriers support it, and recommend it. Here's an example:

https://support.skyetel.com/hc/en-us/articles/4409130351255-IP-Auth-vs-SIP-Registration

I'm just asking for some transparency here so we have time to plan for substantial changes to our operations.

 

[Guillaume Bourgeois]

Prioritizing SIP via IP-Based or Register is a matter of preference, not compliance.

Register is the easiest to configure—even those with poorly managed network configurations behind the PBX can make it work.

For a while, 3CX has recommended SIP Register. If you’ve followed the blog, you’ll know IP-Based templates have shifted from "Supported by 3CX" to "Supported by Third-Party." The SMB service (formerly StartUP) always required "Register."

Skytel favors IP-Based, which is fine. I worked for a Skytel competitor (Quebec < Canadian SIP provider), and they took the opposite stance.

Skytel lists reasons but omits that rInstance only works in "register" mode, essential for Multi-Tenant Mode.

Skytel’s conclusion is spot on: "When comparing these technologies, consider your use case. For small offices with their own PBX, SIP Registration is easier, especially with a dynamic IP. Hosting PBX in a datacenter? Use IP Authentication."

Additionally:
- If your PBX is in a datacenter with Multi-Tenant, use register.
- To manage provider redundancy, register is recommended.
- In IP-Based mode with redundant 3CX PBX, you'll need to configure two trunks per provider for each IP, but in Register mode, you avoid this.

Both models have pros and cons, but 3CX chooses what suits most customers. Some may be disappointed, but most were already using Register.

I can already predict your next comment : "Why not offer a choice?"

Did you know 3CX supports 202 provider templates (excluding the two generic ones) ?
Imagine if 3CX had to support two configurations while managing the limitations. It would be overwhelmed with support.

3CX chose one model: Register, the most popular.
You can still configure an unsupported setup. Use the Generic Trunk template, but remember, 3CX offers no support for this model.

Providing transparency is tough. If 3CX publishes too many blog posts, people don’t read them (many Partners ask questions already answered in the blog).

It takes effort to write and respond. Do you have a blog for your clients? It’s a lot of work...

And yet, some are still on versions older than V18.9 and were surprised when downgraded to 2SC, then blamed 3CX for not communicating enough! (Really?!)

All over a caller ID issue that most Canadian providers already allow you to manage in their portal.

The Smart CallerID service enables you to dynamically customize the telephone ID for outgoing calls according to predefined conditions. This gives you greater flexibility in adjusting the name and number displayed to provide relevant information on outgoing calls.

Possible conditions for adjusting the display of your identifier are:

1. Source Number ID
   Corresponding to a specific number or regular expression
   
2. Destination Number Identification
   Corresponding to a specific number or regular expression
   
3. Region (Destination)
   Corresponds to a Country, and/or a State/Province and/or a Region when applicable
   
4. Local to Destination
   When the number to be displayed is local to the destination
   
5. Distance (radius in KM)
   When the distance between the number to be displayed and the destination corresponds to the radius in KM.

Experience endless possibilities with our Smart CallerID service. Boost your image, capture attention, and make every call count.
Elevate your communication. Elevate your success.

You can still use the unsupported generic template. If this feature is important, check the Ideas section, vote, or reach GOLD partner level to post your idea. If popular, 3CX will notice.

Personally, I prefer 3CX focuses on AI and API features, which offer more value than a feature most Canadian providers already support.

I'm simply trying to help you realize that when we look at a situation from another perspective, it allows us to see beyond ourselves. We also need to consider the challenges faced by the manufacturer!​

Best regards,

 

[NateDoc]

What's the provider you're quoting for that Smart CallerID feature?

Also, I do read the blog, and haven't seen them explicitly mention this shift. If it's implied, it's definitely not clear enough. When 3CX mentioned about maintaining free status on self-hosted instances running v18, we acted - because they warned us repeatedly. So they are capable of communicating important changes - it would be nice if they were more consistent. Just what I've noticed over the years of maintaining our 3CX systems. Anyway, it seems this is a permanent change, so we'll have to roll with it like we usually do.

 

[Guillaume Bourgeois]

What's the provider you're quoting for that Smart CallerID feature?

Internet Infinity through their service (WholeSale) called BeeVox .
He is known for their service called VoiceMeUp (supported provider), which is aimed at end users.
However, they are not the only ones offering Smart CallerID feature; they didn’t reinvent the wheel.

I do read the blog, and haven't seen them explicitly mention this shift.

https://www.3cx.com/blog/docs/supported-sip-trunk-providers/
https://www.3cx.com/blog/releases/ip-based-trunks-hosted/
https://www.3cx.com/blog/docs/voip-provider-template/
https://www.3cx.com/blog/voip-howto/testing-voip-provider/
For years, 3CX has communicated that it is preferable to configure using SIP Register.
They may not have officially announced the removal of IP-Based templates, but that doesn’t affect you.
You just need to use the generic template.... The templates are really just a way to identify what is supported and what is not.

Why reintegrate an IP-Based template when the generic one does the exact same thing?
Why are you "refusing" to use the generic template?

Anyway, it seems this is a permanent change, so we'll have to roll with it like we usually do.

Generally, if a manufacturer suggests a way to use their product, it's probably the ideal solution. You could ask Voip.MS to implement a feature similar to SmartCallerID,
Or
continue working as you are, but instead of selecting the Voip.MS template, use generic template .. is same !
Or
Change SIP Trunk providers.