[asterisk-bugs] [JIRA] (ASTERISK-30025) PJSIP affected by delays in DNS resolution

[Nicholas Carr (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-30025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258892#comment-258892 ] 

Nicholas Carr commented on ASTERISK-30025:
------------------------------------------

Thanks Joshua,

That is fair enough and I am happy to review the DNS configuration we have if that provides any helpful insight, but it sounds like it might not be.

If pjsip hands off to the OS for DNS resolution and handling, then I agree its out of the scope of pjsip anyway.

Should I close this bug off?

> PJSIP affected by delays in DNS resolution
> ------------------------------------------
>
>                 Key: ASTERISK-30025
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30025
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: pjproject/pjsip
>    Affects Versions: 16.15.0, 16.22.0
>         Environment: Hosted - Microsoft Azure (DS2 v2 - 2vCPU, 8GB, STD SSD) 
> CentOS 7.9
>            Reporter: Nicholas Carr
>            Assignee: Nicholas Carr
>
> Issue causing multiple pjsip trunks to go unreachable at random times. Trunk would return after a random period of time. 
> Whilst the issue first appeared on 16.22.0, we have been able to recreate the issue on 16.15.0 as well. 
> Tested IP based and outbound auth based trunks, both are affected. 
> Tested multiple carriers, all seemed to be affected. 
> PJSIP logger showed registrations and SIP OPTIONS all seem to be sending and receiving just fine. After a debug, we found that the issue would appear when qualifying the aor, the SIP OPTIONS would get sent AFTER the qualify had expired. The SIP OPTIONS would receive its valid response almost instantly but still several seconds too late. 
> As per the community discussion - https://community.asterisk.org/t/pjsip-is-now-unreachable-realtime/92392/5, it was recommended to raise the bug for further investigation. 
> Current work around is simply to increase the qualify_timeout default from 3 to 5 or greater pending the delay. 
> Whether the issue/delay is due to the asterisk -> DNS server query or the DNS server -> remote domain DNS query, we are unsure... happy to help



--
This message was sent by Atlassian JIRA
(v6.2#6252)