When you do a sip show peer xxx you will have two things you need to look at:
Addr->IP : 108.x.x.x:5060 <-- This is the Received IP
Reg. Contact : sip:[email protected]:5060 <-- That is the location of the contact in the contact header.
Now the registered contact location is to tell the system where to send the call so this is telling Asterisk to send to send requests/calls to 10.11.102.117 which cannot traverse the public Internet so NAT repairing replaces it with the Received IP. NAT repairing involves looking at two key things 1) The top Via header and 2) Contact header, neither of these should have an RFC1918 IP in them. If they do then NAT repair must be done.
Now here’s a PJSIP contact and keep in mind that chan_pjsip sees huge NAT handling improvments.
Result of pjsip show aor showing the public IP registered with.
Contact: 680/sip:[email protected]:53628 3421231c6a Avail 23.906
Results from the registrar/contact in the AstDB. The place you are requesting information to be displayed from:
/registrar/contact/680;@3421231c6aed4e6064935188360c516d: {"via_addr":"192.168.3.100",
"qualify_timeout":"3.000000",\
"call_id":"[email protected]",
"reg_server":"",
"prune_on_boot":"no",
"path":"",
"endpoint":"680",
"via_port":"5060",
"authenticate_qualify":"no",
"uri":"sip:[email protected]:53628", <-- Note the IP in the uri field. This is the result of rewrite_contact=yes because the contact should have a routable IP over the public Internet.
"qualify_frequency":"60",
"user_agent":"Yealink SIP-T46S 66.84.0.125",
"expiration_time":"1634862097",
"outbound_proxy":""
}
So now there really isn’t a Received IP (Addr->IP) equivalent. Sure the call-id has the LAN IP but not all devices use call-id’s that show the IP. So I guess you’ll need to show the Via_Header for this. Which again, will only have the LAN IP depending on how the device and/or the network deals with SIP and NAT handling.
You should not be using this to figure out what the LAN IPs of the remote phones are. You should have proper remote access that can show you a DHCP lease pool and by matching MACs you can easily find the IP of your phone. But more importantly, the need to get the IP means you are going to be remoting into the phone to touch its configuration. That, in itself, is a poor management practice. FreePBX comes with a full provisioning server and that is what should be used to manage the configurations of the phones. Solves this “What’s the LAN IP so I can add a BLF button” nonsense.
EDIT: BTW, here’s a chan_sip peer that is behind NAT connecting to a hosted cloud VM. Not a single LAN IP involved.
Addr->IP : 65.x.x.42:5060
Reg. Contact : sip:[email protected]:5060
AstDB Registry details:
/SIP/Registry/100 : 65.x.x.42:5060:3600:100:sip:[email protected]:5060
In contrast the same registry details for the above SIP peer:
/SIP/Registry/5407 108.x.x.x:5060:120:5407:sip:[email protected]:5060