Since what Asterisk 13 version are FQDNs supported for external signaling settings in PJSIP?
External signaling settings has been supported for quite awhile, media address is a recent addition specifically 13.18.0.
Are FQDNs also supported in the
match= parameter in the identify section, as well as
contact= parameter in AOR section?
Yes, they are. When used in the contact section it will also do SRV and if using 15 failover and NAPTR.
When matching inbound on IP via the
match= parameter, how does Asterisk know which IP address the FQDN in
match= resolves to? Via regular hostname lookups configured in
It does SRV and A record lookups, getting all IP addresses (not just one) that it can be resolved to. It’s not periodically done currently.
If it’s not periodically done, when is it done?
If configured in .conf at the time it is loaded. If configured using realtime at the time it is pulled from the database.
So on load time it would resolve the name in
match=, but when the IP address of that name changes, asterisk wouldn’t know until next reload?
That is correct, it would not.
Using inbound registration matching on username would then be better than using a FQDN in the
match= parameter, trying to match on IP.
Are there any plans to get regular lookups configured with
match=, cause if not, FQDNs wouldn’t really work very well with that?
dnsmgr would be suitable for that.
I know of noone actively working on such a thing and you are the first person in my memory to even ask about it. Generally matching based on IP address is for things like ITSPs, where addresses are unlikely or rarely to change. If it’s a truly dynamic environment then user/pass based is more reliable indeed.
How do I match on user/pass but without using registration?
Registration has nothing to do with using user/pass, it just tells the server where you are. We match on endpoint using the user portion of the From header and if inbound authentication is specified we challenge.
What parameter in pjsip.conf makes inbound Invites match on IP, the
And if that’s omitted, matching is done via user/pass?
The identify section with a match is what configures IP based matching. It’s not whether it’s omitted or not - there is an order (which is configured in pjsip.conf) that dictates what takes priority. For example you can do IP first and then username, or the reverse.
Although you can, on a per-endpoint basis, disallow types from matching (like specifying an endpoint should only be matched using a username). All depends on what you want to do and the environment.
So if there is an identify section configured, matching will be done on IP (provided it’s first in the order). If there is no identify section matching will be done on whatever is next in the order.
Yes, that is correct.
So it is possible to e.g. force to only match on username, or auth_username, despite an identify section being present?