Some Domains Resolving Issues
Hello.
I have two records in dialplan:
exten => testA,1,Dial(PJSIP/outgoing/sip:thetestcall@sip.linphone.org)
exten => testB,1,Dial(PJSIP/outgoing/sip:thetestcall@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.
—
7 thoughts on - Some Domains Resolving Issues
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).
16.12.0~dfsg-1 ?
—
sergio.
—
I don’t use packages. I built a fresh copy of 16.13.0 as it is latest and used that.
Joshua is lieing ASSHOLE
Sent from my iPhone
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.
—
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.
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.
Would be nice!
—
sergio.
—