chan_iax2: Add log message for rejected calls.

[InterLinked1]

Certain calls can fail due to networking/DNS misconfigurations where a call is made to a loopback address on which chan_iax2 is not listening. When this happens, there is no relevant logging currently, making this very difficult to track down. This issue can be detected reliably, so this adds a warning message to direct users to check their configuration.

Resolves: #413

[seanbright]

“Possible network issue?”

How is this useful?

[github-actions]

REMINDER: If this PR applies to other branches, please add a comment with the appropriate "cherry-pick-to" headers as per the Create a Pull Request process.

If you don't want it cherry-picked, please add a comment with cherry-pick-to: none so we don't keep asking.

If, after adding "cherry-pick-to" comments, you change your mind, please edit the comment to DELETE the header lines and add cherry-pick-to: none.

The currently active branches are now 18, 20, 21 and master.

[InterLinked1]

“Possible network issue?”

How is this useful?

It's something to go off of, and there are more comments in the code that can be used if needed.
I didn't want to get too specific like "Check /etc/hosts for non-canonical loopback addresses" because it's not guaranteed that the issue is there, that's why I tried to keep it generic.

[jcolp]

This is why I suggested actually digging in more to truly understand the scenario and what is going on to provide a better and more helpful message in the correct situation.

[InterLinked1]

This is why I suggested actually digging in more to truly understand the scenario and what is going on to provide a better and more helpful message in the correct situation.

If chan_iax2 isn't listening on the particular loopback address, the packets are being sent somewhere and not actually getting processed, hence the lack of a valid call number at this point. Why it is that someone is trying to dial a loopback address that isn't being listened on is really their issue to resolve, but this should clue them in on that hopefully.

[jcolp]

On further looking, they were actually being received so my initial analysis was incorrect - why things went awry I don't know, but it was seemingly due to not explicitly binding. I don't think it's actually understood why it's doing what it is doing, beyond that binding explicitly causes it to work.