[asterisk-dev] Asterisk / pjsip: control the SRV DNS response set with an option

Michael Maier m1278468 at mailbox.org
Fri Apr 9 12:05:03 CDT 2021


Hello George,

On 05.04.21 at 17:11 George Joseph wrote:
> On Mon, Apr 5, 2021 at 7:38 AM George Joseph <gjoseph at sangoma.com> wrote:
> 
>>
>>
>> On Sat, Apr 3, 2021 at 12:09 AM Michael Maier <m1278468 at 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



More information about the asterisk-dev mailing list