Hi,
We have noticed that since the last update the extension status no longer shows the internal IP which was really handy for when supporting end users remotely.
Here is how it used to look:
but here is how it is now:
I have tried rebooting the phones but still no joy. Was this part of the update or is there and easy fix?
Thanks
We are running this version:
Hi, have a look at pjsip endpoints.
It should show you IPs.
Does this help you?
Or was it really the internal ip? Which would be handy, I agree.
Hi,
No unfortunately its only showing me the external IP and not the internal one.
It was really handy as you could click the hyperlink and it too you straight to the IP of the phone.
Nice find, let’s see what they say.
It’s a t48g vs t46u. Nothing to do with that?
I did wonder that, but all the T46U , T48U, W70 and W80 units that this tenant uses were all def reporting in and then only after the last update they seemed to stop.
I have rebooted 3 sites worth but still not checked in. I hope they can fix it as it was such a handy feature.
That information is automatically generated by Asterisk. VitalPBX just shows the information that Asterisk provides.
Anyway, depending on the environment, it’s normal that you cannot see the internal IP of the phone sometimes.
Here’s more information about the x-ast-orig-host header.
x-ast-orig-host is a header we add to incoming requests when rewrite_contact is on AND the host we get the request from is different from the host in the contact URI. We do this so we can restore the original contact URI when we send responses. Here’s the scenario…
A client behind a firewall sends Asterisk a REGISTER request. The contact URI is probably going to be a non-routable ip address like 192.168.0.1 but the host the packet comes from will be the public ip address of the firewall. In order to properly route responses and subsequent requests, the “rewrite_contact” option can be used to force Asterisk to substitute the private ip address in the contact header with the public ip address we actually got the packet from. This way we send responses and new requests to the public ip address. This all works well except for 1 scenario… When a client sends a REGISTER request, they can use the IP address in the contact header of the response to match it to the request. If we’ve rewritten the contact header, they won’t be able to match it. So we save off the contact host into that x-ast-orig-host header and when we send responses back to the client, we still send it to the public ip address git we reset the contact host back to what was in the original request. We then strip all x-ast* headers before we actually send the packets.
Thanks so much for the quick reply.
What I’m confused about is that it was working fine for several months and then it just stopped and as far as I’m aware there was no changes to the firewall where the voice network breaks out so I’m not sure why it’s changed.
I’ve checked some other tenants who share the box and theirs was all working too and they seems to have stopped.
Is there a way to check for a user change log on the pbx to see if another admin has changed anything that could cause this behaviour?
This is not a feature, this is a behavior that Asterisk implements when a device is behind NAT.
Thankyou for your detailed response. I still dont quite understand how its been working how it shows in my first screenshot for months and then only in the last couple of weeks it just stopped.
Is there another way that we can see the internal IP of the handset to aid in remote support of the users?
Thanks
Hi,
Is there a way in the CLI we can find what the internal IP of the phone is?
It just seems that we are now missing the x-ast-orig-host= header but it used to be there 
