Hello George,
On 05.04.21 at 17:11 George Joseph wrote:
On Mon, Apr 5, 2021 at 7:38 AM George Joseph <gjos...@sangoma.com> wrote:
On Sat, Apr 3, 2021 at 12:09 AM Michael Maier <m1278...@mailbox.org>
wrote:
Hello!
As Asterisk doesn't care about destinations used for each request if
there is a
DNS SRV set given by the DNS resolution (more than one server in the
response) I
would like to shrink the used destinations received from DNS SRV query to
one
server (as the SRV list is unchanged since years now regarding German
Telekom).
I can do this like in the attached patch - but I didn't find any way so
far to
bring in a (new) option of transport configuration e.g. to this callback.
Isn't
there any way?
I think this would take a lot of investigation and a lot of work. There
are several subsystems involved in the DNS resolution process... the core
DNS stuff (main/dns*), the pjsip resolver callback, the
individual res_pjsip modules that want to do lookups, and pjproject
itself. You'd have to find a way to pass the specific endpoint involved
through all of those subsystems.
Thanks for your estimation.
However, I'm not sure that patch you
attached will actually do what you want, although I guess it depends on
what you wanted :)
This patch just prevents adding more than one of the possible 3 SRV entries received from the lookup to be used by asterisk. This way, asterisk always has to use the same server, because there is only one (and always the same). I know - that's a workaround and not the final
solution you described above. I would be already happy if it would be possible to add a configuration option to define which entry should be used (first, second or third). But I don't see any way to achieve it w/o massive changes.
By the time sip_resolve_callback is called, I _think_
all of the lookups have already been done and sip_resolve_callback is just
iterating over the results. If your intention was to not do all the
lookups you may have even more work to do.
That's the result if you change the patch to always use the *second* entry:
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:485 sip_resolve:
Performing SIP DNS resolution of target 'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:512 sip_resolve:
Transport type for target 'tel.t-online.de' is 'TLS transport'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:555 sip_resolve:
[0x7fe32838d188] Created resolution tracking for target 'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:177
sip_resolve_add: [0x7fe32838d188] Added target 'tel.t-online.de' with record
type '35', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:177
sip_resolve_add: [0x7fe32838d188] Added target '_sips._tcp.tel.t-online.de'
with record type '33', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:177
sip_resolve_add: [0x7fe32838d188] Added target 'tel.t-online.de' with record
type '1', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:626 sip_resolve:
[0x7fe32838d188] Starting initial resolution using parallel queries for target
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:278
sip_resolve_callback: [0x7fe32838d188] All parallel queries completed
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:379
sip_resolve_callback: [0x7fe32838d188] NAPTR record received on target
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:177
sip_resolve_add: [0x7fe32838d188] Added target '_sips._tcp.tel.t-online.de'
with record type '33', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:379
sip_resolve_callback: [0x7fe32838d188] NAPTR record received on target
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:383
sip_resolve_callback: [0x7fe32838d188] NAPTR record skipped because order '20'
does not match strict order '10'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:379
sip_resolve_callback: [0x7fe32838d188] NAPTR record received on target
'tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:383
sip_resolve_callback: [0x7fe32838d188] NAPTR record skipped because order '30'
does not match strict order '10'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:345
sip_resolve_callback: [0x7fe32838d188] SRV record being skipped on target
'_sips._tcp.tel.t-online.de' because NAPTR record exists
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:345
sip_resolve_callback: [0x7fe32838d188] SRV record being skipped on target
'_sips._tcp.tel.t-online.de' because NAPTR record exists
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:345
sip_resolve_callback: [0x7fe32838d188] SRV record being skipped on target
'_sips._tcp.tel.t-online.de' because NAPTR record exists
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:314
sip_resolve_callback: [0x7fe32838d188] A record being skipped on target
'tel.t-online.de' because NAPTR or SRV record exists
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:421
sip_resolve_callback: [0x7fe32838d188] New queries added, performing parallel
resolution again
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:278
sip_resolve_callback: [0x7fe32838d188] All parallel queries completed
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:350
sip_resolve_callback: [0x7fe32838d188] SRV record received on target
'_sips._tcp.tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:350
sip_resolve_callback: [0x7fe32838d188] SRV record received on target
'_sips._tcp.tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:177
sip_resolve_add: [0x7fe32838d188] Added target 'h2-eps-110.edns.t-ipnet.de'
with record type '1', transport 'TLS transport', and port '5061'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:350
sip_resolve_callback: [0x7fe32838d188] SRV record received on target
'_sips._tcp.tel.t-online.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:421
sip_resolve_callback: [0x7fe32838d188] New queries added, performing parallel
resolution again
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:278
sip_resolve_callback: [0x7fe32838d188] All parallel queries completed
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:327
sip_resolve_callback: [0x7fe32838d188] A record received on target
'h2-eps-110.edns.t-ipnet.de'
[2021-04-09 18:42:46] DEBUG[9394]: res_pjsip/pjsip_resolver.c:427
sip_resolve_callback: [0x7fe32838d188] Resolution completed - 1 viable targets
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:201
sip_resolve_invoke_user_callback: [0x7fe32838d188] Address '0' is
217.0.29.37:5061 with transport 'TLS transport'
[2021-04-09 18:42:46] DEBUG[9384]: res_pjsip/pjsip_resolver.c:207
sip_resolve_invoke_user_callback: [0x7fe32838d188] Invoking user callback with
'1' addresses
The complete answer of the SRV lookup is:
> dig +short _sips._tcp.tel.t-online.de. SRV
30 0 5061 d-eps-110.edns.t-ipnet.de.
10 0 5061 s-eps-110.edns.t-ipnet.de.
20 0 5061 h2-eps-110.edns.t-ipnet.de.
=> Asterisk exactly uses the second entry based on priority
(h2-eps-110.edns.t-ipnet.de). That's what I'm expecting.
Thanks
Michael
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
