Fpbx16 chan_pjsip: from contains internal ip on aws

So before i was running fpbx13 on chan_sip, and everything was fine.
By setting my external ip, all my headers showed that ip.

However, since i upgraded, i cannot seem to get the from-header to show the external ip,
which leads to being unable to return missed calls on yealink devices unless outbound proxy is set.

My headers now always look like this:
From: <sip:EXTENSION OR NUMBER@INTERNALIP-OF-EC2>
To: sip:EXTENSION@EXTERNALIP-OF-USER
Contact: sip:EXTENSION@EXTERNALIP-OF-EC2:5060

and i cannot seem to find any way to have the from contain the external ip.

is anyone else facing this same issue, or does anyone have a clue where to look ?

i have set external signalling and media ip, and in calls that establish i have 2-way audio,
it’s just calling back and displaying the correct information that goes wrong.

take a look at your settings > General > Sip and PJSIP pages.
odds are you have an internal / external IP missing from there.

unfortunately it does not seem to be that…
i currently have external ip filled in and local empty on the sip page, and all empty on the pjsip page.

however, before coming here for help, i also tried (and each time restarted -not reloaded- asterisk) with:

  • external ip and local ip filled in on sip page, nothing on pjsip page
  • nothing filled in on sip page, external filled on pjsip page
  • nothing filled in on sip page, external and internal filled in on pjsip page
  • everything filled on both pages
  • and even went as far as adding a domain to “domain the transport comes from”

none of the above has so far changed the behaviour:
the from, pai and rpid all always carry the @internalip instead of the external ip or hostname.

The IP/domain part of the From header does not matter. It could contain anything. The part before the @ is used as caller ID if there’s not another caller ID header (PAI, RPID) set.

This is where you should solve the problem… not in the From header.

I’m pretty sure this is what you’d want to set: https://support.yealink.com/en/portal/knowledge/show?id=fbe64933bbd2f7a9c28b1002

and you have your local subnet flagged as a Local Network? (so it knows to override it?)

Actually it does matter. Whilst, in practice, people use SIP URIs as though they were tel: ones, using just the user part, the domain is also part of the URI, and can matter. It doesn’t seem impossible to me that a phone should treat a From: SIP URI as a direct address for the originator, rather than a phone number, plus some noise. Most phones will allow you to specify a general URI, rather than a phone number, although it may be a pain to do so.

In a similar area, Asterisk does have some, limited, support for processing a full URI during an attended transfer, so it is, in theory, possible for a phone to set up the enquiry leg directly (or at least through a different PABX), and then send REFER/Replaces to Asterisk giving a target URI which is the direct one for the enquiry leg. This does require some special handling in the dialplan, but there is support for it.

Understood - but this is the FreePBX forum and I am talking about within the context of FreePBX. Outside of this context I recognize my advice would be inaccurate.

It’s the phone that is being confused, not FreePBX, and it does matter to the phone, at least when configured in the way it has been configured.

There may be a way of telling the phone to ignore the domain name.

There is probably a way of making the phone treat FreePBX as an outbound proxy, even though it isn’t really acting as one.

But you do have to force the phone to set up the call through FreePBX and not try and make a direct call.

with or without the local subnet, it does not get overriden.

so… it is normal behaviour to now, with pjsip, see the internal ip in all the headers? (from, pai, rpid)
and i need to change all the phones to just accept that ?

for a small installation, i guess that’s fine, but it baffles me that for a large setup you’d have to go through such hoops?
yes, setting outbound proxy to the device seems to fix it.
then again: calling is fine in both ways, and when the phones call out, they behave like good phones and set pbx.mydomain as domainpart.

what i wonder about most: how is it, that now (pjsip) you have the internal ip,
while before, setting the same things, you got your external ip (chan_sip).
am i really the only one facing this issue?

i know it might be more asterisk/chan_pjsip question perhaps, but fpbx13 (and another one i saw on 15) do not share the behaviour that i’m seeing with my fpbx16 pjsip setup now, which is why i was hoping someone here could help me out.

by the way: ip calling is disabled on the phone, but it just doesnt care: a missed call will be user@internalip and calling it back will just fail.

You should be able to control it from the Asterisk end, by using from_domain in the endpoint definition. I don’t know if this is exposed through the GUI, though.

seems like it’s not, unfortunately.
here’s what my phone thinks because of this:

so on line 2 you can see a missed call, which the phone shows as the actual number on the display,
but in the logs its phonenumber@internalip
then, on line 1, you can see what it tries to call back when redialing: phonenumber@internalip@actualhostname (which fails miserably)

image
Asterisk SIP Settings - PJSIP settings

Try putting your preferred From domain in “Domain the transport comes from”

Since Yealink and FreePBX are commonly used together you might want to ask your question differently to get input from Yealink users on best practices for configuration.

Then again you might want to use endpoints that don’t do such ridiculous things…

when i add this to pjsip.endpoint_custom_post.conf it works indeed.
it sets my domain in the from, and the phone has no issues correctly calling back a missed call
but… doing this for every endpoint is probably not going to be a good idea either (delete an endpoint and miss something, add an endpoint and miss something, …)

would there be a way to set it as a default for all endpoints ?

also did that, but it seemed to do nothing, the from header was not changed.

well… yeah, they didn’t do it in fpbx13 because they were seeing the external pbx ip and all was fine,
but now they see that internal one… and apparently don’t really like it.
but, buying other devices in hopes of not having this issue is not really an opption.

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