asterisk users - Sep 2020 - some domains resolving issues

Hello.

I have two records in dialplan:

exten => testA,1,Dial(PJSIP/outgoing/sip:thetestcall at sip.linphone.org)
exten => testB,1,Dial(PJSIP/outgoing/sip:thetestcall at iptel.org)

Calling testA works fine while testB fails with "CONGESTION".

Adding debug for console shows that pjsip_resolver.c does
`New queries added, performing parallel resolution again`
for linphone after discovering SRV records, and does not for iptel.

It looks like a bug.

All modules are loaded manually, with autoload=no, res_resolver_unbound 
is not loaded.

Asterisk 16.2.1~dfsg-1+deb10u2 debian stable.

I have another Asterisk 16.3.0 on OpenWrt 19.07.3 that resolves both 
cases, but uses musl.

testB:
res_pjsip/pjsip_resolver.c:477 sip_resolve: Performing SIP DNS 
resolution of target 'iptel.org'
res_pjsip/pjsip_resolver.c:504 sip_resolve: Transport type for target 
'iptel.org' is 'Unspecified'
res_pjsip/pjsip_resolver.c:547 sip_resolve: [0x7f4e740564e8] Created 
resolution tracking for target 'iptel.org'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740564e8] Added 
target 'iptel.org' with record type '35', transport
'Unspecified', and
port '0'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740564e8] Added 
target '_sips._tcp.iptel.org' with record type '33', transport
'TLS',
and port '5061'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740564e8] Added 
target '_sip._tcp.iptel.org' with record type '33', transport
'TCP', and
port '5060'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740564e8] Added 
target '_sip._udp.iptel.org' with record type '33', transport
'UDP', and
port '5060'
res_pjsip/pjsip_resolver.c:616 sip_resolve: [0x7f4e740564e8] Starting 
initial resolution using parallel queries for target 'iptel.org'
res_pjsip_session.c:3538 session_inv_on_state_changed: Source of 
transaction state change is TX_MSG
dns.c:557 ast_search_dns_ex: DNS search failed for iptel.org
dns_system_resolver.c:155 dns_system_resolver_process_query: DNS search 
failed for query: 'iptel.org'
dns.c:557 ast_search_dns_ex: DNS search failed for _sips._tcp.iptel.org
dns_system_resolver.c:155 dns_system_resolver_process_query: DNS search 
failed for query: '_sips._tcp.iptel.org'
res_pjsip/pjsip_resolver.c:277 sip_resolve_callback: [0x7f4e740564e8] 
All parallel queries completed
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740564e8] 
SRV record received on target '_sip._tcp.iptel.org'
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740564e8] 
SRV record received on target '_sip._udp.iptel.org'
res_pjsip/pjsip_resolver.c:419 sip_resolve_callback: [0x7f4e740564e8] 
Resolution completed - 0 viable targets
res_pjsip/pjsip_resolver.c:207 sip_resolve_invoke_user_callback: 
[0x7f4e740564e8] Invoking user callback with '0' addresses


testA:
res_pjsip/pjsip_resolver.c:477 sip_resolve: Performing SIP DNS 
resolution of target 'sip.linphone.org'
res_pjsip/pjsip_resolver.c:504 sip_resolve: Transport type for target 
'sip.linphone.org' is 'Unspecified'
res_pjsip/pjsip_resolver.c:547 sip_resolve: [0x7f4e740593f8] Created 
resolution tracking for target 'sip.linphone.org'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740593f8] Added 
target 'sip.linphone.org' with record type '35', transport 
'Unspecified', and port '0'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740593f8] Added 
target '_sips._tcp.sip.linphone.org' with record type '33',
transport
'TLS', and port '5061'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740593f8] Added 
target '_sip._tcp.sip.linphone.org' with record type '33',
transport
'TCP', and port '5060'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740593f8] Added 
target '_sip._udp.sip.linphone.org' with record type '33',
transport
'UDP', and port '5060'
res_pjsip/pjsip_resolver.c:616 sip_resolve: [0x7f4e740593f8] Starting 
initial resolution using parallel queries for target 'sip.linphone.org'
res_pjsip_session.c:3538 session_inv_on_state_changed: Source of 
transaction state change is TX_MSG
dns.c:557 ast_search_dns_ex: DNS search failed for sip.linphone.org
dns_system_resolver.c:155 dns_system_resolver_process_query: DNS search 
failed for query: 'sip.linphone.org'
res_pjsip/pjsip_resolver.c:277 sip_resolve_callback: [0x7f4e740593f8] 
All parallel queries completed
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740593f8] 
SRV record received on target '_sips._tcp.sip.linphone.org'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740593f8] Added 
target 'sip6.linphone.org' with record type '1', transport
'TLS', and
port '5223'
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740593f8] 
SRV record received on target '_sips._tcp.sip.linphone.org'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740593f8] Added 
target 'sip1.linphone.org' with record type '1', transport
'TLS', and
port '5223'
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740593f8] 
SRV record received on target '_sips._tcp.sip.linphone.org'
res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7f4e740593f8] Added 
target 'sip6.linphone.org' with record type '1', transport
'TLS', and
port '443'
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740593f8] 
SRV record received on target '_sip._tcp.sip.linphone.org'
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740593f8] 
SRV record received on target '_sip._tcp.sip.linphone.org'
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740593f8] 
SRV record received on target '_sip._udp.sip.linphone.org'
res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7f4e740593f8] 
SRV record received on target '_sip._udp.sip.linphone.org'
res_pjsip/pjsip_resolver.c:413 sip_resolve_callback: [0x7f4e740593f8] 
New queries added, performing parallel resolution again
res_pjsip/pjsip_resolver.c:277 sip_resolve_callback: [0x7f4e740593f8] 
All parallel queries completed
res_pjsip/pjsip_resolver.c:326 sip_resolve_callback: [0x7f4e740593f8] A 
record received on target 'sip6.linphone.org'
res_pjsip/pjsip_resolver.c:326 sip_resolve_callback: [0x7f4e740593f8] A 
record received on target 'sip1.linphone.org'
res_pjsip/pjsip_resolver.c:326 sip_resolve_callback: [0x7f4e740593f8] A 
record received on target 'sip6.linphone.org'
res_pjsip/pjsip_resolver.c:419 sip_resolve_callback: [0x7f4e740593f8] 
Resolution completed - 3 viable targets
res_pjsip/pjsip_resolver.c:201 sip_resolve_invoke_user_callback: 
[0x7f4e740593f8] Address '0' is 54.37.202.229:5223 with transport
'TLS'
res_pjsip/pjsip_resolver.c:201 sip_resolve_invoke_user_callback: 
[0x7f4e740593f8] Address '1' is 91.121.209.194:5223 with transport
'TLS'
res_pjsip/pjsip_resolver.c:201 sip_resolve_invoke_user_callback: 
[0x7f4e740593f8] Address '2' is 54.37.202.229:443 with transport
'TLS'
res_pjsip/pjsip_resolver.c:207 sip_resolve_invoke_user_callback: 
[0x7f4e740593f8] Invoking user callback with '3' addresses


% host iptel.org
iptel.org has address 212.79.111.155
iptel.org mail is handled by 50 mx3.zoho.com.
iptel.org mail is handled by 10 mx.zoho.com.
iptel.org mail is handled by 20 mx2.zoho.com.

% host -t SRV _sip._tcp.iptel.org
_sip._tcp.iptel.org has SRV record 0 100 5060 sip.iptel.org.

% host -t SRV _sip._udp.iptel.org
_sip._udp.iptel.org has SRV record 0 25 5060 sip.iptel.org.

% host sip.iptel.org
sip.iptel.org has address 212.79.111.155

I've already tried to ask community.asterisk.org without success.

https://community.asterisk.org/t/resolving-issue/85861

-- 
sergio.

On Wed, Sep 30, 2020 at 8:47 AM sergio <sergio at outerface.net> wrote:
> Hello.
>
> I have two records in dialplan:
>
> exten => testA,1,Dial(PJSIP/outgoing/sip:thetestcall at
sip.linphone.org)
> exten => testB,1,Dial(PJSIP/outgoing/sip:thetestcall at iptel.org)
>
> Calling testA works fine while testB fails with "CONGESTION".
>
> Adding debug for console shows that pjsip_resolver.c does
> `New queries added, performing parallel resolution again`
> for linphone after discovering SRV records, and does not for iptel.
>
> It looks like a bug.
>
> All modules are loaded manually, with autoload=no, res_resolver_unbound
> is not loaded.
>
> Asterisk 16.2.1~dfsg-1+deb10u2 debian stable.
>
> I have another Asterisk 16.3.0 on OpenWrt 19.07.3 that resolves both
> cases, but uses musl.
>
I am unable to reproduce this on the latest version of 16 on Ubuntu. This
means it is either due to your old version of Asterisk, or something in
your specific environment (be it Debian or something DNS related).

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200930/854e0192/attachment.html>

On 30/09/2020 14:59, Joshua C. Colp wrote:
> latest version of 16 on Ubuntu
16.12.0~dfsg-1 ?


-- 
sergio.

It was due to a lack of tcp or udp sections with transport declaration 
in pjsip.conf.

But it's still unclear,

1. How should I find this? Is a log so poor and needs to be reported, or 
am I missing something?

2. Why I need to set bind? I use this transport only for outgoing 
connections.


-- 
sergio.

On Wed, Sep 30, 2020 at 10:02 PM sergio <sergio at outerface.net> wrote:
>
> It was due to a lack of tcp or udp sections with transport declaration
> in pjsip.conf.
>
> But it's still unclear,
>
> 1. How should I find this? Is a log so poor and needs to be reported, or
> am I missing something?
>
At startup we actually do output messages about what transports are
available and what the resolver will check. We could extend that to runtime
as well.

>
> 2. Why I need to set bind? I use this transport only for outgoing
> connections.
>
For TCP the PJSIP stack requires it in order to work, and to allow
connections back in case the remote side doesn't do connection reuse. For
UDP there is no such thing as a connection so you need something listening
to receive incoming traffic.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20201001/f66e3757/attachment.html>