PJSIP bundled doesn't fallback to A record after NAPTR/SRV lookup failure

Asterisk Asterisk Support
1

Hi everyone,

I’m facing an issue with the bundled PJPROJECT in Asterisk and I’d like to know if anyone has seen this behavior before.

Environment

  • Asterisk 18.24.3
  • Bundled PJPROJECT (2.14.1)
  • Alpine Linux
  • OpenSSL 3
  • Transport: UDP
  • DNS resolver works normally

The system was compiled with --with-pjproject-bundled. but without-pjproject also tested and i got the same problem.

Problem

When sending an outbound SIP request to a hostname that only has an A record, PJSIP performs a NAPTR lookup but never falls back to the A record as defined by RFC3263.

No SIP INVITE is generated.

The resolver finishes with:

Resolution completed - 0 viable targets

___________________________________________________
DNS configuration

The target hostname is:
lb-sip-presence.ligo-voice.local

It resolves to an AWS Network Load Balancer.

A record

$ dig A lb-sip-presence.ligo-voice.local

ANSWER SECTION:
10.99.8.18
10.99.9.97

NAPTR
$ dig NAPTR lb-sip-presence.ligo-voice.local

status: NOERROR
ANSWER: 0

SRV
$ dig SRV _sip._udp.lb-sip-presence.ligo-voice.local

status: NXDOMAIN
According to RFC3263 I would expect:

NAPTR
↓
(no records)
↓
SRV
↓
(no records)
↓
A lookup
↓
Send INVITE
Instead, the resolver stops after NAPTR.
___________________________________________________

What we’ve already tested

DNS

  • dig A works
  • dig NAPTR works
  • dig SRV behaves as expected
  • /etc/resolv.conf is correct
  • Linux resolver works correctly
  • Same behavior using:
    • Route53 private zone
    • AWS NLB DNS name directly
      ___________________________________________________

SIP URI

We tested both:
sip:lb-sip-presence.ligo-voice.local
And
sip:ligo-voice-sip-presence-xxxxxxxx.elb.us-east-1.amazonaws.com
Same behavior.
___________________________________________________

Network

Everything works if we replace the hostname by the IP address.

For example:

sip:10.99.8.18

Immediately generates the INVITE.

So:

  • networking is OK
  • transport is OK
  • endpoint configuration is OK

The only difference is hostname vs IP.

___________________________________________________

Compilation

PJPROJECT is bundled.

We initially had some issues compiling PJPROJECT on Alpine/OpenSSL 3, but they were fixed.

The bundled PJPROJECT version is:
2.14.1

Resolver debug

The resolver performs a NAPTR lookup.

It then reports:

Resolution completed - 0 viable targets

No SRV lookup appears.

No A lookup appears.

No INVITE is generated.

Debug log (relevant part)

CLI> channel originate PJSIP/000001@sip-presence application Playback,demo-congrats

[Aug  3 13:11:25] DEBUG[...] res_pjsip_session.c:4579 handle_outgoing_request:
PJSIP/sip-presence-00000003: Method is INVITE

[Aug  3 13:11:25] DEBUG[...] res_pjsip_session.c:4589 handle_outgoing_request:
PJSIP/sip-presence-00000003

[Aug  3 13:11:25] DEBUG[...] res_pjsip/pjsip_resolver.c:475 sip_resolve:
Performing SIP DNS resolution of target 'sip.example.local'

[Aug  3 13:11:25] DEBUG[...] res_pjsip/pjsip_resolver.c:502 sip_resolve:
Transport type for target 'sip.example.local' is 'UDP transport'

[Aug  3 13:11:25] DEBUG[...] res_pjsip/pjsip_resolver.c:545 sip_resolve:
[0xffffbd684038] Created resolution tracking for target 'sip.example.local'

[Aug  3 13:11:25] DEBUG[...] res_pjsip/pjsip_resolver.c:174 sip_resolve_add:
[0xffffbd684038] Added target 'sip.example.local'
with record type '35', transport 'UDP transport', and port '5060'

[Aug  3 13:11:25] DEBUG[...] res_pjsip/pjsip_resolver.c:616 sip_resolve:
[0xffffbd684038] Starting initial resolution using parallel queries
for target 'sip.example.local'

After this point, no additional DNS resolution is logged (no SRV lookup, no A lookup), no SIP INVITE is transmitted on the network, and the resolver eventually reports that there are no viable targets.
sip.example.local is not the real dns, i just change in the log for security but the data in general is a real log

___________________________________________________

Question

Has anyone seen bundled PJPROJECT stop the RFC3263 resolution after the NAPTR lookup instead of falling back to SRV and finally to the A record?

Is there any known issue in PJPROJECT 2.14.1 or Asterisk 18.24.x related to SIP DNS resolution?

Any ideas on where to instrument the resolver to understand why it finishes with 0 viable targets would also be appreciated.

Thanks!

2

Is the issue with only that particular hostname or does any/all hostname lookups stop after the NAPTR attempt?

Are you using res_resolver_unbound? If not, can you try with it? If you are, can you try without it?

Are you running a local caching resolver?

3

The issue is with any hostname.

We tested again with res_resolver_unbound completely removed, forcing Asterisk to use the system DNS resolver.

The behavior is identical.

The resolver starts correctly, launches parallel DNS queries (NAPTR, SRV for TCP/TLS/UDP), but every query immediately fails and the resolver reports:

Resolution completed - 0 viable targets

o A lookup is ever attempted after that.

We have confirmed outside Asterisk that:

  • NAPTR returns NOERROR with no records.
  • SRV returns NXDOMAIN.
  • A returns two valid addresses.

According to RFC 3263, after no usable NAPTR/SRV records are found, we expected the resolver to fall back to an A lookup, but that never happens.

We reproduced the issue both with res_resolver_unbound and with the system resolver, so the resolver backend does not appear to be the cause

4

Well, if all A record resolution is failing altogether, the issue has got to be somewhere in your environment. If you can reproduce the issue with a current version of asterisk it’ll be much easier to help.