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

[Joshua Colp (JIRA)]

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

Joshua Colp commented on ASTERISK-26735:
----------------------------------------

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.

> 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)