[Home]

Summary:ASTERISK-26735: res_pjsip_endpoint_identifier_ip: "srv_lookups" after match in .conf has no effect
Reporter:Michael Maier (micha)Labels:
Date Opened:2017-01-20 01:11:58.000-0600Date Closed:2017-01-24 07:07:25.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_pjsip_endpoint_identifier_ip
Versions:13.13.1 14.2.1 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Centos 6 / 64bit FreePBX 13.0.190.7 Attachments:
Description:Using DNS SRV functionality with PJSIP leads to a wrong auto generated match entry, if DNS SRV results differ from standard resolution.

Example:
# dig tel.t-online.de

;; QUESTION SECTION:
;tel.t-online.de.               IN      A

;; ANSWER SECTION:
tel.t-online.de.        584     IN      CNAME   ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de.    42403   IN      CNAME   ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de. 42403   IN      CNAME   s-epp-001.isp.t-ipnet.de.
s-epp-001.isp.t-ipnet.de. 165   IN      A       217.0.23.4

Asterisk builds the auto generated match entry on base of tel.t-online.de (217.0.23.4).


The SRV entries are like this:

# dig _sip._udp.tel.t-online.de SRV

;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.     IN      SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 3600 IN      SRV     1 5 5060
hh-epp-009.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600 IN      SRV     0 5 5060
b-epp-009.isp.t-ipnet.de.


# dig b-epp-009.isp.t-ipnet.de

;; QUESTION SECTION:
;b-epp-009.isp.t-ipnet.de.      IN      A

;; ANSWER SECTION:
b-epp-009.isp.t-ipnet.de. 595   IN      A       217.0.23.108



# dig hh-epp-009.isp.t-ipnet.de

;; QUESTION SECTION:
;hh-epp-009.isp.t-ipnet.de.     IN      A

;; ANSWER SECTION:
hh-epp-009.isp.t-ipnet.de. 246  IN      A       217.0.23.140


PJSIP now registers e.g. to 217.0.23.108. This means, all incoming calls are sent from this IP - which is refused by asterisk, because asterisk uses the standard resolution of tel.t-online.de, which is 217.0.23.4 (in my case).

Please do an auto generated match entry on base of the IP address PJSIP registered to.


Workaround:
Manual definition of a huge Telekom net as match entry in pjsip.identify.conf (217.0.18.0/23,217.0.20.0/22,217.0.24.0/24) as nobody really knows which IPs Telekom will use.

If used with stateful iptables rules not that big problem, nevertheless it would be good to have an accurate entry as it took me quite some time to get the reason!
Comments:By: Asterisk Team (asteriskteam) 2017-01-20 01:11:59.093-0600

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: Ross Beer (rossbeer) 2017-01-20 02:47:14.223-0600

Do the following patches resolve your issues?

Asterisk 13: https://gerrit.asterisk.org/#/c/4697/4
Asterisk 14: https://gerrit.asterisk.org/#/c/4698/3

This issue relates to ASTERISK-26693

The above patches should be released in the next asterisk version as they have been merged.

By: Michael Maier (micha) 2017-01-20 04:48:30.593-0600

Yes, diff for 13.13.1 tested. It's working here.

By: Michael Maier (micha) 2017-01-20 04:51:15.218-0600

Will be fixed in one of the next versions like described in comment 2.

By: Michael Maier (micha) 2017-01-22 14:41:39.678-0600

Just realized when switching back to "normal" operation w/o SRV: the SRV matching entries are not removed. They are now used *always* - even if no SRV entries are used. Now, I had to set the entry manually again after reload for normal operation. The patch as tested here obviously only works w/ SRV and not w/o SRV. Please fix it!

By: Asterisk Team (asteriskteam) 2017-01-22 14:41:39.938-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

By: Joshua C. Colp (jcolp) 2017-01-22 14:56:52.123-0600

Can you please elaborate on your last comment? It is confusing. What did you do, what did you set, what happened.

By: Joshua C. Colp (jcolp) 2017-01-22 15:07:38.287-0600

Ah, I see. If you put srv_lookups after a match then it is not in effect at the time of resolution.

By: Michael Maier (micha) 2017-01-22 23:11:25.569-0600

To be more clear:

pjsip distinguishes between two modes: resolving the DNS name "via" dig tel.t-online.de or dig _sip._udp.tel.t-online.de SRV. This is done based on missing or not missing port after the domain information (tel.t-online.de:5060 vs. tel.t-online.de (-> SRV)).

W/o the mentioned patch, asterisk uses as match entry *always* the result of dig tel.t-online.de. W/ this patch, *always* the result of dig _sip._udp.tel.t-online.de SRV is used. In other words, the resolution doesn't cover the resolution mode used by pjsip. But Telekom does distinguish between these two modes and provides completely *different* ipaddresses.
Most probably it would be the easiest way, if you just use the target ipaddress from each REGISTER pjsip does. Or, if you don't know the mode pjsip uses, you should add the ipaddresses of both, dig tel.t-online.de and dig _sip._udp.tel.t-online.de SRV.

By: Joshua C. Colp (jcolp) 2017-01-23 09:58:48.249-0600

[~micha] There is an option which I am fixing to work 100% of the time that can be used to turn the SRV behavior on/off. As well if you are registering have you tried the line option[1] to see if it would make the use of identify no longer needed?

[1] http://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/

By: Michael Maier (micha) 2017-01-23 10:55:32.563-0600

I tried to test it, but I don't know how to apply this option as I'm using FreePBX, that doesn't allow adding additional options for PJSIP via GUI. Therefore I added the options to pjsip.endpoint_custom.conf like this:

[telekomPJSIP-225] # same section name as in pjsip.endpoint.conf
line=yes
endpoint=telekomPJSIP-225

Without the additional section name, asterisk can't read the config any more. Therefore, I'm sure, asterisk is reading pjsip.endpoint_custom.conf.

When added as written above, asterisk is running and registering - but no line parameter is added to contact. Maybe wrong endpoint value? I'm not sure which value to provide for endpoint= .... Can it be a random string or must it match some other section of the configuration?

By: Joshua C. Colp (jcolp) 2017-01-23 11:01:25.458-0600

[~micha] It matches the endpoint for the ITSP. What that would be in FreePBX I'm not sure. I'm also not sure how to have it be added under FreePBX.

By: Michael Maier (micha) 2017-01-23 11:55:41.350-0600

I tried to add it temporary here:

[telekomPJSIP-225]
type=endpoint
transport=0.0.0.0-udp
context=from-trunk
disallow=all
allow=g722,alaw,ulaw,g726,g729
aors=telekomPJSIP-225
language=de
outbound_auth=telekomPJSIP-225
from_domain=tel.t-online.de
from_user=+49....
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=rfc4733
line=yes
endpoint=telekomPJSIP-225

but I got this error message:
config_options.c: Could not find option suitable for category 'telekomPJSIP-225' named 'line' at line 128 of /etc/asterisk/pjsip.endpoint.conf

in other words: the option line isn't known. Is there an extra patch needed?

By: Friendly Automation (friendly-automation) 2017-01-24 07:07:26.392-0600

Change 4765 merged by George Joseph:
res_pjsip_endpoint_identifier_ip: Read settings before resolving.

[https://gerrit.asterisk.org/4765|https://gerrit.asterisk.org/4765]

By: Friendly Automation (friendly-automation) 2017-01-24 07:09:36.840-0600

Change 4764 merged by George Joseph:
res_pjsip_endpoint_identifier_ip: Read settings before resolving.

[https://gerrit.asterisk.org/4764|https://gerrit.asterisk.org/4764]

By: Friendly Automation (friendly-automation) 2017-01-24 08:22:45.082-0600

Change 4766 merged by George Joseph:
res_pjsip_endpoint_identifier_ip: Read settings before resolving.

[https://gerrit.asterisk.org/4766|https://gerrit.asterisk.org/4766]

By: Michael Maier (micha) 2017-01-24 10:05:39.139-0600

Sorry for reopening again. Unfortunately, this patch doesn't fix the problem, too. Maybe I wasn't clear enough. Therefore I'll try it again.

1. Given is the following configuration for a trunk (*default* entry via freepbx - autogenerated):

contact=sip:+4912345678@tel.t-online.de:5060
server_uri=sip:tel.t-online.de:5060
client_uri=sip:+4912345678@tel.t-online.de:5060

This means: pjsip will do normal lookups. Your default of srv_lookups is *yes* (can't be switched by FreePBX): Things will horribly break, because you are using SRV lookups and pjsip is using normal lookups -> all incoming calls are blocked.

2. Manually setting of contact, server_uri and client_uri (removing the port information):

contact=sip:+4912345678@tel.t-online.de
server_uri=sip:tel.t-online.de
client_uri=sip:+4912345678@tel.t-online.de

Now, your auto match creation with srv_lookups=yes matches to the action pjsip does: it uses SRV lookups, too. Things will work. But this is not the default in FreePBX - you have to add it manually!

Conclusion:
Your patch misses the *synchronization* of the behavior of *asterisk* on the one hand and *pjsip* on the other hand. They are both working completely independent. That's why things break in 50% of all cases.

In other words: If srv_lookups is set to yes, pjsip *must* use SRV lookups. If srv_lookups is set to no, pjsip has not to use SRV lookups - completely independent of the configuration given by contact / server_uri / client_uri.

Another solution would be to force FreePBX to provide the logic: If srv_lookup is set to yes, contact, client_ and server_uri must be w/o port indication (this would be default), and if srv_lookup is set to false, contact, client_ and server_uri must have port indication. But this should be discussed with the FreePBX developer.

From my point of view, asterisk already should ensure that things never can't diverge. I would have done it the same way as pjsip did: check for the existence of the ports: if they are given, use standard lookups, if they are not given, use SRV lookups. This would be consistent.

By: Asterisk Team (asteriskteam) 2017-01-24 10:05:39.585-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

By: Joshua C. Colp (jcolp) 2017-01-24 10:11:43.173-0600

Ports can't actually be specified in a match. The match is strictly a hostname, it doesn't understand SIP URIs or use that resolution method. Things are very separate and synchronizing the two inside of Asterisk is not possible. They are completely unaware of each other. I'm not sure what the best way forward for Asterisk would be.

By: Michael Maier (micha) 2017-01-24 10:48:32.479-0600

Wouldn't it be possible to just parse contact, server_uri and client_uri (or only server_uri? I'm not sure) and check for existence of ":port" at the end: if a port is given, use standard lookups to resolve the host given at match parameter, if no port is found at contact, server_uri and client_uri, use SRV lookups. This would be just another signal for using SRV or not: instead of srv_lookups switch use the same signal as used by pjsip. Going this way things wouldn't diverge between pjsip and asterisk.

By: Joshua C. Colp (jcolp) 2017-01-24 10:53:16.186-0600

An identify section has no relation to an AOR or outbound registration or any of that. There is no association between them, so you can't know what registration it is in relation to without explicitly adding that association in some sort of new config option.

By: Michael Maier (micha) 2017-01-24 11:27:35.343-0600

Ok, this is most probably the reason, why a match parameter given for one trunk works for all other trunks, too - if they use the same provider. Even if the other trunk has match entries which wouldn't work at all as they are shown in "show endpoint telekomPJSIP", ... . One more discrepancy :-).

trunk1 match=217.0.34.17,217.0.34.18 - registered to 217.0.34.17 -> incoming call ok
trunk2 match=217.0.34.120 - registered to 217.0.34.18 -> incoming call ok because of match entry for trunk1

The only solution I'm seeing here, which wouldn't break things, would be: always add all ipaddresses to the match entry you can get, regardless if they are the result from SRV lookup or not. This even wouldn't need the srv_lookups parameter at all.

By: Friendly Automation (friendly-automation) 2017-01-26 22:12:30.101-0600

Change 4832 merged by zuul:
res_pjsip_endpoint_identifier_ip: Fix memory leak of hosts when resolving.

[https://gerrit.asterisk.org/4832|https://gerrit.asterisk.org/4832]

By: Friendly Automation (friendly-automation) 2017-01-27 07:02:41.542-0600

Change 4830 merged by George Joseph:
res_pjsip_endpoint_identifier_ip: Fix memory leak of hosts when resolving.

[https://gerrit.asterisk.org/4830|https://gerrit.asterisk.org/4830]

By: Friendly Automation (friendly-automation) 2017-01-27 07:03:07.999-0600

Change 4831 merged by George Joseph:
res_pjsip_endpoint_identifier_ip: Fix memory leak of hosts when resolving.

[https://gerrit.asterisk.org/4831|https://gerrit.asterisk.org/4831]