Summary: | ASTERISK-25010: DNS Tests: Failover order | ||||||
Reporter: | Matt Jordan (mjordan) | Labels: | |||||
Date Opened: | 2015-04-24 11:35:57 | Date Closed: | 2015-05-13 04:46:48 | ||||
Priority: | Major | Regression? | |||||
Status: | Closed/Complete | Components: | Tests/testsuite | ||||
Versions: | Frequency of Occurrence | ||||||
Related Issues: |
| ||||||
Environment: | Attachments: | ||||||
Description: | 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. | ||||||
Comments: |