PJSIP DNS resolve

FreePBX Providers
,
1

Hello,
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[15294]: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo("", "(null)", ...): Name or service not known
[2023-05-03 15:03:16] ERROR[15294]: 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[15294]: 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.

N S

2

The identify section doesn’t use res_resolver_unbound. It uses the system resolver stuff. If that fails then at that point in time the query failed. A packet capture of the DNS traffic may shed light.

3

Show us your endpoint configs for these trunks.

4

This appears to be trying to resolve an empty name!

5

Thank you for the answers. Below is the endpoint configuration of the trunk.

[OTE_2310570XXX]
type=endpoint
transport=0.0.0.0-udp
context=custom-add-9
disallow=all
allow=ulaw,alaw,g722,h264,mpeg4
aors=OTE_2310570XXX
send_connected_line=false
rtp_keepalive=0
language=en
outbound_auth=OTE_2310570XXX
from_domain=ims.otenet.gr
contact_user=2310570XXX
user_eq_phone=no
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rtp_symmetric=yes
dtmf_mode=auto
6

I am honestly not sure how to fix this. Because for example right now, after I “fwconsole restart” it works. And I can’t understand neither why it works, nor why it doesn’t work.

7

You’d need to show the identify section.

8

Here is the relevant identify section. Please keep in mind that the trunk is created exclusively from WEB GUI.

[OTE_2310570XXX]
type=identify
endpoint=OTE_2310570XXX
match=ims.otenet.gr
9

And now the AORs which will have the contact URI details…and the auth section if it has FQDNs in it.

10

Edit: Just hiding the last 3 digits of the phone number, and replaced with XXX.

AOR

[OTE_2310570XXX]
type=aor
qualify_frequency=60
contact=sip:[email protected]:5060

AUTH

[OTE_2310570XXX]
type=auth
auth_type=userpass
password=XXXXXXXXXXXX
[email protected]
11

I’m not sure that chan_pjsip compensates for this URI syntax error; you may need to URL encode the @. Of course, if the other side expects two bare @s, they are broken.

12

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.

13 
user             =  1*( unreserved / escaped / user-unreserved )
user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved  =  alphanum / mark
mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                     / "(" / ")"
escaped     =  "%" HEXDIG HEXDIG

@ is not a valid character in a SIP URI user part.

Either you or the system needs to replace it with %20.

If they really want:

sip:user@domain1@domain2

then they are requiring you to send an invalid URI.

14

There is some confusion here:

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.

15

It is exactly like @Stewart1 said.

Username doesn’t containt ‘@’ and auth does contain ‘@’

image
image875×612 31.1 KB 

pjsip show identify OTE_2310570XXX

the above returns nothing exactly because the resolve never happens.

If I manually add the actual resolved IP in the ‘Match’ field like below:
image

There are no errors and as expected:

*CLI> pjsip show identifies

 Identify:  OTE_2310570XXX/OTE_2310570XXX
      Match: 195.167.16.182/32

@david55
I am not sure if this is relevant, but the equivalent of a working SIP Trunk Registration string is:

image
image902×77 5.88 KB

Edit: Adding a screenshot of a successful registration, in case it helps.

image
image1398×278 18.8 KB

16

Just a guess, does the trunk have SIP Server Port set to 5060? It should be blank. Setting a port number defeats DNS SRV record lookups, which OTE uses for failover.

But I’m confused about the 195.167.16.182 address. From here in US, looking up with Google DNS (8.8.8.8) I get:

> set type=SRV
> _sip._udp.ims.otenet.gr
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
_sip._udp.ims.otenet.gr SRV service location:
          priority       = 20
          weight         = 1
          port           = 5060
          svr hostname   = kole-sbc2bck.ims.otenet.gr
_sip._udp.ims.otenet.gr SRV service location:
          priority       = 10
          weight         = 1
          port           = 5060
          svr hostname   = nyma-sbc2.ims.otenet.gr
>
> set type=A
> nyma-sbc2.ims.otenet.gr
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    nyma-sbc2.ims.otenet.gr
Address:  195.167.16.30

> kole-sbc2bck.ims.otenet.gr
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    kole-sbc2bck.ims.otenet.gr
Address:  195.167.16.29

>

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.

17

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.

I hope that clarifies it.

# nslookup -type=SRV _sip._udp.ims.otenet.gr
Server:         195.167.21.200
Address:        195.167.21.200#53

_sip._udp.ims.otenet.gr service = 20 1 5060 kole-sbc2bck.ims.otenet.gr.
_sip._udp.ims.otenet.gr service = 10 1 5060 nyma-sbc2.ims.otenet.gr.

# nslookup -type=A nyma-sbc2.ims.otenet.gr
Server:         195.167.21.200
Address:        195.167.21.200#53

Name:   nyma-sbc2.ims.otenet.gr
Address: 195.167.16.182

# nslookup -type=A kole-sbc2bck.ims.otenet.gr
Server:         195.167.21.200
Address:        195.167.21.200#53

Name:   kole-sbc2bck.ims.otenet.gr
Address: 195.167.16.181

Yes, I do have port, I will remove it and try again.

18

No change.

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:

[OTE_2310570XXX]
type=identify
endpoint=OTE_2310570XXX
match=195.167.16.182,195.167.16.181
19

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 197.167.16.0/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.

20

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.

Again thank you all.