I have a problem with PJSIP Trunks and resolving the FQDN. When I try to resolve FQDN directly from linux, all work great. Within asterisk this doesn’t happen though I get errors like the following one.
[2023-05-03 15:03:16] ERROR: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo("", "(null)", ...): Name or service not known
[2023-05-03 15:03:16] ERROR: res_pjsip_endpoint_identifier_ip.c:553 ip_identify_apply: Identify 'OTE_2310570XXX' failed when adding resolution results of 'ims.otenet.gr'
[2023-05-03 15:03:16] ERROR: res_sorcery_config.c:422 sorcery_config_internal_load: Could not create an object of type 'identify' with id 'OTE_2310570XXX' from configuration file 'pjsip.conf'
I have read that I can setup Unbound DNS Resolver, which I can see that is already activated within FreePBX distro.
XXX*CLI> module show like resolve
Module Description Use Count Status Support Level
res_resolver_unbound.so Unbound DNS Resolver Support 1 Running core
1 modules loaded
So I am trying to follow from documentation but I really can’t understand how to set it up.
For starters, is this supposed to be created in /etc/asterisk/ ?
How do I test it so that I can see if it works or not ?
I am really confused and I face this problem with various installations where I have converted trunks from SIP to PJSIP. They work for some time and after some point they stop working because there is no Identify. If I “fwconsole restart” it works again, but as before after some point it just stops working.
Could you please elaborate why it is syntax error? If I understand correct this is a part of the equivalent of “Registration String” for SIP. When it was SIP the username was exactly what is shown above.
In the GUI for the trunk settings, we have Username (what goes in SIP URIs) and Auth username (what goes in the username parameter in Authorization headers). Username should not contain an @ character, but Auth username can, and is typically required by ‘IMS’ based systems.
I don’t see an obvious problem with the .conf files so suspect that the in-memory data eventually gets somehow corrupted. With luck, after the error occurs we can view the live data and see a problem, e.g. pjsip show identify OTE_2310570XXX
We can also use tcpdump to see whether a DNS lookup is being performed and how it is failing. IMO, the null name is resulting in the lookup not being done.
So, guessing that the addresses are geo dependant, I tried via my Cyberghost account, connecting to a server in Greece, but that made no difference. My next guess is that OTE is your ISP and their ‘local’ DNS servers resolve ims.otenet.gr differently.
The thing with OTE is that it has two programs that both register to ‘ims.otenet.gr’, Consumer and Business VoIP.
The result you are getting is the Consumer VoIP.
In order to get the IP I am getting I HAVE to resolve ‘ims.otenet.gr’ using specific DNS Server which is reachable only through their own dedicated equipment which is on-premise and directly connected to pbx. In other words, eth0 is internet, eth1 is OTE equipment where all VoIP traffic of OTE is routed, and there is also a relevant configuration file /etc/sysconfig/network-scripts/route-eth1.
For the time being I will just use the IPs manually in ‘Match’ field since it works because I can’t find another way. I would really like to know though what causes the DNS resolve problem in order to fix or workaround it. Even pointing at the correct documentation would work for me.
Anyway, by manually input the IP addresses into the ‘Match’ field, the Identify configuration is changed by FreePBX into:
I took a look at a similar trunk on my system and I see a SRV query followed by A queries for each of the hosts, as one would expect. So, if you have the time, capture the DNS traffic and report what you see.
If you can’t easily fix it or don’t want to bother, based on
consider setting Match (Permit) to 126.96.36.199/23
which will likely cover you if OTE adds new servers or removes existing ones. IMO it’s very unlikely that an attacker could acquire an address in this block.
Thank you all for the really useful help and insight. It was pretty overwhelming when I don’t know how to search what happens “behind the scene”.
I am going to follow the route of manually adding the subnets because I am already on it for 2 days and I don’t have the luxury of spending more time. If and when the problem arises again, I will capture traffic DNS traffic as 3 people already told me already in this post, although I am not sure what I am searching for. I suppose I’ll spot it when I see it.
Just to add that piece of info:
Everything started when I converted OTE SIP Trunk from chan_sip to chan_pjsip. Since there was need to resolve ‘ims.otenet.gr’ from their specific DNS I naturally created dnsmasq file with relevant entries. From linux cli I was getting the correct address resolution (aka Business sbc address).
But, when I used sngrep tool to watch registration traffic, I noticed that asterisk completely forego specific dnsmasq file and used the rest nameservers from /etc/resolv.conf (instead of 127.0.0.1 which redirects to dnsmasq), result is the wrong address resolution (aka Consumer sbc address)
Which is the reason that lead me to res_resolver_unbound.so in the first place trying to setup and started this thread, hoping I could set specific DNS nameservers for chan_pjsip.
I will follow @Stewart1 advice for now and hopefully I find an answer in the future.