[asterisk-bugs] [JIRA] (ASTERISK-26735) res_pjsip_endpoint_identifier_ip: "srv_lookups" after match in .conf has no effect

Tue Jan 24 10:07:10 CST 2017

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234836#comment-234836 ] 

Michael Maier commented on ASTERISK-26735:
------------------------------------------

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 at tel.t-online.de:5060
server_uri=sip:tel.t-online.de:5060
client_uri=sip:+4912345678 at 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 at tel.t-online.de
server_uri=sip:tel.t-online.de
client_uri=sip:+4912345678 at 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.

> res_pjsip_endpoint_identifier_ip: "srv_lookups" after match in .conf has no effect
> ----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26735
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26735
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_endpoint_identifier_ip
>    Affects Versions: 13.13.1, 14.2.1
>         Environment: Centos 6 / 64bit
> FreePBX 13.0.190.7
>            Reporter: Michael Maier
>            Assignee: Joshua Colp
>
> 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!

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