[asterisk-bugs] [JIRA] (ASTERISK-25010) DNS Tests: Failover order
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Fri Apr 24 11:44:33 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-25010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Jordan updated ASTERISK-25010:
-----------------------------------
Status: Open (was: Triage)
> DNS Tests: Failover order
> -------------------------
>
> Key: ASTERISK-25010
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-25010
> Project: Asterisk
> Issue Type: Improvement
> Security Level: None
> Reporter: Matt Jordan
>
> 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)
More information about the asterisk-bugs
mailing list