ASTERISK-29624: Contact identifier is not updated when FDQN resolves to a new address

[Home]

Summary: ASTERISK-29624: Contact identifier is not updated when FDQN resolves to a new address

Reporter: Philip Young (PYoung) Labels:

Date Opened: 2021-08-31 12:46:54 Date Closed:

Priority: Minor Regression?

Status: Open/New Components: Resources/res_pjsip_endpoint_identifier_ip

Versions: 16.19.0 Frequency of
Occurrence Constant

Related
Issues:

Environment: FreePBX : 15.0.17.48 PBX Distro:12.7.8-2107-3.sng7 Asterisk Version:16.19.0 Attachments:

Description: We have PJSIP Trunks on server side configured as follows :

Authentication None
Registration None
SIP Server : FQDN

Everything works fine unless the client's ISP changes the public IP address. The FQDN set in the trunk is updated correctly because I can see the server sending OPTIONS and inbound INVITE to the client's new IP address to which the FDQN now matches. However, outbound calls (from client to this server) are unauthorized. Why ? I noticed the identity in the contact is never updated! I've let it go for 48 hours and it still hasn't updated the identifier of this contact. It will keep the old IP address in the Identifier Match.

Ex :

Server = 100.200.300.400

Client = example.wtv.com

example.wtv.com resolves to 1.2.3.4

Following a power outage or modem reboot or other the ISP gives the client a new IP address 5.7.8.9

The FQDN is updated correctly and the server now sends OPTION or INVITE to 5.7.8.9.

When the client (5.7.8.9) sends OPTION or INVITE, it is unauthorized:

Server logs : SECURITY[2133] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2021-08-18T11:53:21.136-0400",Severity="Informational",Service="PJSIP",EventVersion="1",AccountID="<unknown>",SessionID="350543f20dc11068458494337421216d",LocalAddress="IPV4/UDP/100.200.300.400/5060",RemoteAddress="IPV4/UDP/5.7.8.9/5060",Challenge=""

The peer stays the same :
Peer :
Endpoint: democlient Unavailable 0 of inf
Aor: demo client 0
Contact: democlient/sip:example.wtv.com:5060 2c5be4772a Unavail nan
Transport: 0.0.0.0-udp udp 3 96 0.0.0.0:5060
Identify: democlient/democlient
Match: 1.2.3.4/32

I think this should be updated to 5.7.8.9!

Comments: By: Asterisk Team (asteriskteam) 2021-08-31 12:46:59.287-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

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].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Benjamin Keith Ford (bford) 2021-09-02 10:13:48.526-0500

Can you provide a pcap of the traffic for this? It would be nice to see what's being sent on server and client side.
By: Philip Young (PYoung) 2021-09-07 10:03:33.081-0500

Unfortunately, I cannot provide a packet capture as the server side contains private information that cannot be shared. Although a packet capture of this will only confirm exactly what I described and not give any additional information. I confirmed the following example using Wireshark :

Server = 100.200.300.400
Client = example.wtv.com
example.wtv.com resolves to 1.2.3.4
Following a power outage or modem reboot or other the ISP gives the client a new IP address 5.7.8.9
The FQDN is updated correctly and the server now sends OPTION or INVITE to 5.7.8.9.
When the client (5.7.8.9) sends OPTION or INVITE from the new address, it is unauthorized.

That's all you'll be able to confirm with a packet capture. Unless I'm missing something here. If I am, what exactly are you looking for in this packet capture? I'll pull it out of the trace for you and hide private information.

Thank you!
By: George Joseph (gjoseph) 2021-09-07 12:34:56.365-0500

Generally speaking, clients with changing IP addresses should really be registering but can you give me the exact configuration for the identify? If the match is an ip address rather than a fqdn, there's not much we can do. If it's an fqdn, then we need to take a look.

Another option is to use match_header rather than match. This way you could match on anything in the SIP headers.

By: Philip Young (PYoung) 2021-09-08 15:28:13.449-0500

Here is the result of pjsip show identify democlient :
Identify: <Identify/Endpoint.................................................. .........>
Match: <criteria...........................>
================================================================================ ==========

Identify: democlient/democlient
Match: 1.2.3.4/32

ParameterName : ParameterValue
============================================
endpoint : democlient
match : 1.2.3.4/255.255.255.255
match_header :
srv_lookups : true

By: George Joseph (gjoseph) 2021-09-09 09:28:04.119-0500

So, for outbound transactions, we can do a DNS query each time we create a request. For inbound requests using IP identify matching, what do we look up? The host in the From, Contact, Via, etc. headers can all be spoofed so they're no good. The only thing we can match on is the source IP address. This means that every time we get a new request, we'd have to iterate over all of the identify objects and do a DNS lookup to get an IP address to match to. That's just not practical.

Your alternatives are...
* Make the client register. This scenario is what registration was designed for.
* Make the client authenticate and use the auth_username option in both the global endpoint_identifier_order parameter and the endpoint identify_by option.

By: Jean-Francois Quesnel (jfq) 2021-09-13 14:57:07.520-0500

I'm looking at the code at https://github.com/asterisk/asterisk/blob/master/res/res_pjsip_endpoint_identifier_ip.c
I am not a programmer at all so I may be way off on my assumption.

But from what I can see from the comments in the code of the pjsip_endpoint_identifier_ip module, the resolution from FQDN to IP is only done when you "apply config"

What if the FQDN is a normal A record with a TTL of let's say 24h.
After 24h , you should absolutly resolv again that FQDN, since it is expired.
But this looks like it never happen.

Is there not somewhere in the code that "refresh" the FQDN when its TTL as expired ?

By: George Joseph (gjoseph) 2021-09-14 09:11:00.195-0500

Good point. We do have code that does this already for STUN addresses,

By: Jean-Francois Quesnel (jfq) 2021-10-05 07:42:03.558-0500

Do you have a solution to fix this ?
Is this a matter of waiting for someone to code it ?

By: Joshua C. Colp (jcolp) 2021-10-05 07:46:05.337-0500

Any solutions or fixes would be up for code review and referenced here, as well as the issue would be assigned. As it is the issue is open, but noone is working on it as of this time.