[asterisk-bugs] [JIRA] (ASTERISK-25010) DNS Tests: Failover order

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp closed ASTERISK-25010.
----------------------------------

    Resolution: Fixed

> DNS Tests: Failover order
> -------------------------
>
>                 Key: ASTERISK-25010
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25010
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Tests/testsuite
>            Reporter: Matt Jordan
>            Assignee: Joshua Colp
>
> h2. Failover order
> *Goal:* To ensure that when returned SRV results fail, that the expected order for failing over is respected.
> h3. Procedure:
> # Set up the following DNS records
> {noformat}
>     fast.test.internal   IN A 127.0.0.1
>     slow.test.internal   IN A 127.0.0.1
>      
>     ;;                             Priority Weight Port   Target
>     _sip._udp.test.internal IN SRV        0      3 5061   fast.test.internal.
>                             IN SRV        0      1 5062   slow.test.internal.
>                             IN SRV        1    100 5063   backup.test.internal.
> {noformat}
> # Set up two SIPp scenarios
> ** fast.xml runs at 127.0.0.1, port 5060. It expects an incoming INVITE and responds to the INVITE with a 503 response
> ** slow.xml runs at 127.0.0.1, port 5061. It expects an incoming INVITE and does not respond to it
> # In Asterisk, disable NAPTR lookups. Enable only UDP as a transport.
> # Place an outbound call to sip:test.internal.
> # Ensure that an SRV lookup of _sip._udp.test.internal is performed.
> # Ensure that this results in an A lookup of either fast.test.internal or slow.test.internal. Since SRV weighting has a random factor to it, it is impossible to guarantee which of the two will be chosen first.
> # Ensure a SIP INVITE is sent to the chosen target
> # Ensure that upon failure of the call to the chosen target, that the remaining of fast or slow is chosen as the next target.
> # Ensure a SIP INVITE is sent to the new target. Ensure that the Via header (particularly the branch) is different from the previous outbound INVITE.
> # Ensure that upon failure of the second call, that backup is chosen as the next target.
> # When the A lookup of backup.test.internal returns NXDOMAIN, the test should conclude and not attempt any further lookups.
> h3. Notes
> RFC 3263 section 4.2 states:
> {quote}
>     "If no SRV records were found, the client performs an A or AAAA record lookup of the domain name."
> {quote}
>     My interpretation of this is that since we did find SRV records, we should not fail over to A/AAAA record lookups of test.internal. However, this may be an overly strict interpretation.



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