How to: sip show peers (vs) pjsip show endpoints (local LAN IP)

General Help
1

Hi:

While using only chan_sip: to find out the local LAN IP of a remote endpoint, we could use the super-cool command:

sip show peers

This would show us (most of the time) the LAN side IP of the endpoint.

Now that we are using PJSIP for lots of PBX units: we do not see the remote endpoints “LAN” IP address when using this command:

pjsip show endpoints

We see an IP address, but it is always the WAN side IP for the endpoint(s).

Is there an easy-enough way to use an Asterisk CLI type command to figure out what the remote endpoints have for their LAN IP addresses?

This makes things much faster and easier for troubleshooting some items with remote phones. Sometimes we want the WAN IP, and other times we want to know the local LAN IP address.

Thanks for your thoughts.

2

I have a work in progress PHP status page. It has no security or anything at this time. So HTTP(S) should not be open to the public.

This uses the $astman object, which is AMI.
image

It currently looks like this:

image
image1288×807 106 KB

2 Likes
3

Your work seems cool.

One good thing about sip show peers was / is:

You get to see the model of phone and its firmware …

Just like in your script.

Do you think if we used your process: we would see the LAN IP of the phone: or the WAN?

4

You can’t get the pjsip contact user agent from the console yet, tho I believe it’s been requested as a feature. Generally I just use

pjsip show contacts

as a stand in for the old sip show peers output.

1 Like
5

Depends on the device. As you can see above, different endpoints send various information.

If you turn on debug (see comments in script), you will get a pre-formatted vardump

image
image440×534 19.8 KB

1 Like
6

It also has a flag to show the URI in a column. Disabled by default because it is messy.

image
image811×830 41.8 KB

Eventual goal is to send commands to the specific URI, like this.

 rasterisk -x 'pjsip send notify reboot-yealink uri sip:[email protected]:12505;transport=TLS;x-ast-orig-host=10.254.103.215:12505'

image
image2043×1692 929 KB

1 Like
7

This conversation has happened on IRC and I will say again what I said there.

The contact having the LAN IP on it means poor SIP handling on the device or its network. The contact should not have a RFC1918 address in it when going over the public Internet.

Doing sip show peers will not show the local IP if the SIP packet is handled properly. The same thing applies to PJSIP. Having to use the received IP ( public IP request came from) means, as I said, poor NAT handling on the device side.

So this is not something that will happen 100% of the time and well should never be the method for getting the local IP of the phone. Ever.

8

Even if you say it here too: doesn’t make it correct or what is actually needed in the “real world” (or) desired by networking types.

You said:
The contact having the LAN IP on it means poor SIP handling on the device or its network. The contact should not have a RFC1918 address in it when going over the public Internet.

I say:
No …
Your point is not the same as what we are speaking about.
RFC1918 addresses: do not travel the internet: agreed.

But:
Because, the endpoint DOES have a LAN IP address, and even if that is not what is it is sending (meaning you see its WAN IP via NAT processes) …

At times (remotely) we need to know it.
Send the WAN IP all you want

But we do desire a way to remotely know the peer’s LAN IP …

You said:
So this is not something that will happen 100% of the time and well should never be the method for getting the local IP of the phone. Ever.

I say:
Yes, sometimes you get the WAN IP and other times you get the LAN IP … and we’ve known this since the FPBX 2.x days …

But: YES: using tools on the server side to know the LAN details is something desired: and does not mean “poor networking” even though you have taken this to mean so.

1 Like
9

The LAN IP is never the URI on a public system. The LAN IP is only possibly on the ViaAddress or CallID.

10

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

11

I don’t follow the first sentence you said, at all.

12

No.
Again you have assumed we have no remote access, and we are not managing this correctly. Both are incorrect which toss out your theory on how this “should be done”.

Also: what you mentioned about FPBX having its own provisioning service: If you are speaking about: EPM
I say: Ha-ha-ha

Quote:
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.

I say:
No. EPM leaves much to be desired because for one point it is cumbersome to manage and use. This is my experience trying out the module since it was in BETA (years back).

You use / promote EPM all you want: it is not all robust.
It is not an effective tool: even if you think it is.
In fact, it brings some techs to tears I hear.

ha ha ha: remote access to a LAN: to configure an end-point is definitely NOT poor practice, but again you have your “scoped in” methods.

I’d rather make phones OpenVPN clients then use EPM.

BTW: you can easily find out an OpenVPN client’s LAN IP from the server side: so in your logic that would be a poor practice to use. Which is nonsense.

13

What brand & models of endpoint do you use, and how do you provision them?

14

For exactly what reason do you need to know the LAN address of your endpoints ?

To do any ‘provisioning’ it depends on the MAC address of the device (layer 2) to let the server know what to provide , the IP address (layer 3) is only a carrier of that part of that process, the provisioning of the device just needs the relevant port of the provisioning server to be forwarded to the local LAN all relevant packets where your endpoint can read it after that endpoint requests it, a VLAN should be doing that natively.

15

I never said you didn’t have it. I was stating things you should have and proper remote management is one of them. If you already have that then kudos for you.

Alright, then don’t use the EPM. You tend to forget the amount of hours we’ve spent talking over the years. During those talks you have stated and claimed to not to just have one provisioning server but two. You also have made the claim that while you have those provisioning servers you still like to do part of it by hand. So why aren’t you using either of those if the EPM isn’t up to snuff for you?

I neither use or promote EPM. Again, in those numerous hours we’ve spent chatting I have told you I have my own provisioning system. You’ve asked numerous questions about it.

Well a VPN server is not the same thing. This is completely comparing apples and oranges.

16

Ok. Thanks for this last follow-up. It helped.
Accepted, and your points taken in.

17

You make a lot of assumptions. I use EPM when it is warranted for the client. I use a private git repo to hold configs most of the time though.

I use the private IP all the time for device troubleshooting, assuming a phone reboot or default did not solve the issue.
Bob on ext X said his phone was doing Z.
It is much easier to look at this (or anything that shows the private IP based on extension) and see that ext X is on IP A.B.C.D, than to remote in to some random system and open the DHCP server and then look up a MAC to get an IP. Not to mention most of the time I am only a telecom consultant and have no access to the DHCP server.

I then remote in to what ever device I am allowed to on that network and hop on the endpoint and see what it shows. Very convenient with Yealink devices screenshot ability to see what the user sees.

image

Used for provisioning? pretty much never, unless provisioning is what if being troubleshot.

18

You’re right, it seems I am. I shall stop doing that. I guess we really do need a feature for chan_pjsip to show the local IP of the phone. So developers, you’ll need to use the via_addr field for this as you can’t guarantee the device will have a local IP in the contact or that the device will use the local IP in the call-id.

Oh, better yet don’t modify the rewrite_contact setting and leave it to the default “no” setting which will guarantee no NAT handling will be done on the contact header and for sure leave the LAN IP in it.

So there you go, two ways to get the local IP for the phone. You can look in the AstDB in registrar/contact for the contact details or you can turn off rewrite_contact which will leave the contact header untouched and the local IP will be retained if present.

I have 100’s of phones out there in the field, I got 100’s of FXS gateways out in the field. I touch the FXS gateways the most due to wiring issues and needed to validate if the FXS port is on/off hook when dealing with analog troubleshooting. As for the phones, I’ve had maybe 4 instances in the last year where I needed to be in the phone to troubleshoot actual problems within the phones. In the same time frame I made numbers changes to phones for customers due to employ changes or adding new line/soft keys for them. All of which were done via the provisioning server and triggering profile updates remotely to the phones.

So I totally get that there are times that you will need to get into the phone remotely for troubleshooting. I just don’t equate troubleshooting with management/configuration updates and in the context of what I’ve been saying, I’ve been referring to the management portion.

–

Right now I have a project I’m consulting on and they have a half dozen locations with almost 700 phones and not a single phone is setup to use provisioning. The project requires replacing the current PBX with a new one and having a spare ready for failure. The biggest hold up? Having to touch all the phones. You know how long it would have taken to make this change if they were all setup on a provisioning server? Less than an hour, instead it’s seriously behind because no one can schedule a time to do this at all the locations within the same time frame. Oh yeah, also the lack of bodies that understand how to actually program the phones.

–
Two weeks ago I had someone call me about needing features in a Yealink setup for EFK keys. Well those types of settings can’t be done in the GUI so it needs config files. They freak because they don’t have a way to do that, I ask for their MACs and 20 minutes later I give them creds to the provisioning server and 10 minutes after that all the phones have the new EFK keys on them.

19

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.