Summary:	ASTERISK-27879: pjsip / SRV uses wrong IP address for OPTIONS packages / qualify
Reporter:	Michael Maier (micha)	Labels:	pjsip
Date Opened:	2018-05-29 03:46:29	Date Closed:	2018-05-29 12:52:01
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_pjsip
Versions:	13.21.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Centos 6 / 64bit	Attachments:
Description:	(not sure about the relevant component) Given is a trunk which uses SRV lookups (tel.t-online.de) and resolves to 3 hostnames / IP addresses: # dig _sip._udp.tel.t-online.de SRV ;; ANSWER SECTION: _sip._udp.tel.t-online.de. 2497 IN      SRV     20 0 5060 d-epp-100.edns.t-ipnet.de. _sip._udp.tel.t-online.de. 2497 IN      SRV     30 0 5060 h2-epp-100.edns.t-ipnet.de. _sip._udp.tel.t-online.de. 2497 IN      SRV     10 0 5060 n-epp-110.edns.t-ipnet.de. (you most probably can't exactly reproduce this lookup, because you're getting other resolutions if you're resolving from outside the telekom net). The problem is: The register is done to d-epp-100.edns.t-ipnet.de (-> d...) - but all OPTIONS - packages are sent to n-epp-110.edns.t-ipnet.de (-> n...) The register is done to d.. and not to n..., because n... is not reachable for my device at the moment - that's why the register uses d... and not n. As I'm having 3 trunks to tel.t-online.de and all of them are showing this behavior, it's seems to be that the options packages are always sent to the primary SRV DNS entry and only if it's not reachable, it is sent to the next one and so on (I can see this behavior here). If n... would be reachable, the packages would go out and would be denied by the provider (I could see this behavior during a short test) because n... doesn't know anything about the registration to d... . Could you please take care to always use the same IP address / DNS entry for each communication started for a trunk - even if there are more than one possible IP addresses? Please always use the same IP as it is used for the register. How to reproduce: - Create a trunk using SRV lookups - Provide more than one different entries in the SRV lookup, maybe 3 or more. - Block the IP of the first entry (here: _sip._udp.tel.t-online.de. 2497 IN      SRV     10 0 5060 n-epp-110.edns.t-ipnet.de.) to be not reachable by asterisk to force it to try the register using the next DNS entry. - Enable qualify => you can see the wrong OPTIONS packages in iptables log (you should log outgoing blocked packages)
Comments:	By: Asterisk Team (asteriskteam) 2018-05-29 03:46:32.069-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Joshua C. Colp (jcolp) 2018-05-29 04:31:29.096-0500 Asterisk 13 does not support failover using SRV records which can result in such behavior. If you use Asterisk 15 (which supports NAPTR, failover, IPv6 better, etc for DNS) does this change? By: Michael Maier (micha) 2018-05-29 05:27:44.531-0500 Well, I would like to test it, but I'm using FreePBX 13. The asterisk-version-switch doesn't support asterisk 15 (max is asterisk 14 beta). By: Richard Mudgett (rmudgett) 2018-05-29 12:52:01.241-0500 Closing as the needed feature to operate as described is not supported by v13.  It was added in v14 and later.