[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=234838#comment-234838 ] 

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

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.

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