SOLVED 'internal' SIP profile assigning random port instead of 5060

[stin]

Hello, again.

Another issue is that the 'internal' sofia profile seems to be choosing it's own port number instead of the port I configured:

URL sip:mod_sofia@<PublicIP>:46443
BIND-URL sip:mod_sofia@<PublicIP>:46443;maddr=192.168.42.249;transport=udp,tcp


Also, the protocol seems to be it's own choice - It is supposed to be 'udp'

I was hoping that the full reinstall I did of FusionPBX had fixed the issues I was having with a corrupted 'external' profile

Thank you for any information you can give me

 

[stin]

I've given it a reboot and the port is currently 5060... Fingers crossed.

Spoke too soon... I restarted the profile and it's picked a random port again:

URL sip:mod_sofia@5.70.7.190:42326
BIND-URL sip:mod_sofia@<PublicIP>:42326;maddr=192.168.42.249;transport=udp,tcp

Protocol configuration is still not being honoured, either.

Not sure why it's not behaving as configured.

Anyone with any ideas?

I read on another post that FusionPBX isn't good at implementing config changes - You have to save other settings pages to get the changes to take effect.

Out of ideas... I'll try another reboot to see if settings are honoured, then.

Anyone else experience this strangeness?

 

[DigitalDaz]

Where are you making these changes and why would you want to have sip bind to some random port?

 

[DigitalDaz]

FusionPBX changes settings perfectly, if someone says you need to change other pages to get things to save its probably some newbie without a clue who happened to think that way because cache expired or something. Flush your cache on the SIP status page. What many people do not realise is that cache even survives a Freeswitch restart.

 

[stin]

I have set the correct port in the interface:




It is reading the correct port number from the configuration:

2020-06-20 03:20:52.753892 [DEBUG] sofia.c:4628 sip-port [5060]

However, it isn't implementing it:

URL sip:mod_sofia@<PublicIP>:57758
BIND-URL sip:mod_sofia@<PublicIP>:57758;maddr=192.168.42.249;transport=udp,tcp

This is verified by the open ports on the system. However, IPv6 seems to listening on the right port:

$ netstat -nlpt
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:8021 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 192.168.42.249:5080 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN -
tcp 0 0 192.168.42.249:57758 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:5432 :::* LISTEN -
tcp6 0 0 ::1:5080 :::* LISTEN -
tcp6 0 0 ::1:25 :::* LISTEN -
tcp6 0 0 ::1:5060 :::* LISTEN -

I can't register any endpoints.

 

[stin]

Where are you making these changes and why would you want to have sip bind to some random port?

I am not. That's the point of my post. It shows I have set the options properly, but FreeSWITCH isn't employing them, or at least not letting me know why it isn't.

 

[stin]

Thank you for your advice, Daz.

FusionPBX changes settings perfectly, if someone says you need to change other pages to get things to save its probably some newbie without a clue who happened to think that way because cache expired or something.

Ah, people unknowingly getting things wrong - That's about right for the Internet lol

BTW, can you think of a reason that global variable names would not be evaluated on load, but rather be passed verbatim to FreeSWITCH (i.e. ext_sip_port = "$${external_sip_port}" instead of the a number?) as I had that on my last install.

Flush your cache on the SIP status page.

OK. I've flushed the cache - Do I need to restart/reboot anything now or does it take immediate effect? I checked the status afterwards, but nothing had changed, so I restarted the profile. It is still not instantiating the configured port number:

URL sip:mod_sofia@<PublicIP>:49480
BIND-URL sip:mod_sofia@<PublicIP>:49480;maddr=192.168.42.249;transport=udp

I'll reboot and report back.

What many people do not realise is that cache even survives a FreeSWITCH restart.

I found that out when configuring for video calls - I had to reboot the machine itself, not just restart the FreeSWITCH service. I almost started breaking it because it didn't do what I expected and as I couldn't find any complete documentation, I saw it as a bug.

Does FPBX not flush FS's caches on a critical config change or would that invalidate SIP sessions?

 

[stin]

No joy. Random SIP port again:

>sofia status profile internal:
[...]
RTP-IP 192.168.42.249
Ext-RTP-IP stun:stun3.l.google.com:19302
SIP-IP 192.168.42.249
Ext-SIP-IP <PublicIP>
URL sip:mod_sofia@<PublicIP>:53217
BIND-URL sip:mod_sofia@<PublicIP>:53217;maddr=192.168.42.249;transport=udp
[...]

>sofia status:
[...]
internal-ipv6 profile sip:mod_sofia@[::1]:5060 RUNNING (0)
internal profile sip:mod_sofia@<PublicIP>:53217 RUNNING (0)
[...]

I hope I am not going to have to install and re-configure it all yet again just to see if it changes anything :/

 

[Adrian Fretwell]

It looks like your "random" port could be a WAN facing port on the other side of your NAT. I notice you are using STUN for the Ext-RTP-IP, are you doing similar for your Ext-SIP-IP?

 

[stin]

Thanks for your input, Adrian.

I notice you are using STUN for the Ext-RTP-IP, are you doing similar for your Ext-SIP-IP?

Yes. In fact, the EXT_SIP_IP displays as expected, but the EXT_RTP_IP is the literal "stun:..." string:

RTP-IP 192.168.42.249
Ext-RTP-IP stun:stun3.l.google.com:19302
SIP-IP 192.168.42.249
Ext-SIP-IP <PublicIP>
URL sip:mod_sofia@<PublicIP>:42849
BIND-URL sip:mod_sofia@<PublicIP>:42849;maddr=192.168.42.249;transport=udp

Maybe the RTP variable is not evaluated for STUN 'stun:' strings?

It looks like your "random" port could be a WAN facing port on the other side of your NAT.

On the 'other side' you mean public side? FreeSWITCH's UPnP code doesn't work with my router, so it doesn't know the UPnP port/IP/NAT mode/etc.

Also, why would STUN cause FS to select a port I didn't configure? If it was the same port on every reboot I could almost understand, but a different port on every boot/reload means my endpoints have to be reconfigured each time... Doesn't make logical sense to me.

Can't see anything in the log about why the port is different to what is configured, either.

Is there any way we can diagnose how/where this is happening? @DigitalDaz

Also, I wonder if the literal variable name may be caused by an uncaught error during evaluation which then fails back to quoting the input string? idk

 

[stin]

I fear on the one hand, I can have configured ports but not know the IP; Or, I can know my IP but have random ports opened up instead...

Anyone else feel like they're urinating into a headwind?

 

[Adrian Fretwell]

From your last post I am really struggling to understand what you are doing. It may help if you share some screenshots of your complete SIP profile configuration and not just the SIP profile section of the variables page.

Do you have a static external IP address?

Describe your topology, are all your endpoits on your LAN? Or are they all external? Or is there a mixture?

 

[stin]

Hmmm... The STUN RFC5389 states that "... (STUN) ... can be used by an endpoint to determine the IP address and port allocated to it by a NAT."

So, potentially, my port is being dictated by my STUN server instead of being read from my configuration.

(Urinating into the wind implies some sort of relief.)

 

[stin]

From your last post I am really struggling to understand what you are doing. It may help if you share some screenshots of your complete SIP profile configuration and not just the SIP profile section of the variables page.

Just setting it up after (another re-) installation. I want to test calls from my external endpoints. I would prefer it if we could get a decent handle on what's going on before I start making random guesses. That's why I had to reinstall for the second time.

For what it's worth, here is my internal SIP profile as viewed in FPBX:


And my full sofia status [profile internal] readouts:

> sofia status
Name Type Data State
=================================================================================================
external-ipv6 profile sip:mod_sofia@[::1]:5080 RUNNING (0)
external profile sip:mod_sofia@192.168.42.249:5080 RUNNING (0)
external::cc2c390d-ba74-4679-b230-ad71ee21c365 gateway sip:2289188e0@[provider].co.uk REGED
external::7075695a-6343-4c6c-80aa-2f5a54c84ab0 gateway sip:2292411e0@[provider].co.uk REGED
external::746b8ca3-1644-4275-8a7a-254177155a05 gateway sip:2044554e0@[provider].co.uk REGED
external::d81e1816-ec7f-4fff-85ae-70056b74be68 gateway sip:2328411e0@[provider].co.uk REGED
external::90ba60b5-9da0-440a-a5b5-8dabe21169bc gateway sip:2124668e0@[provider].co.uk REGED
external::5722cbfd-e754-4141-9f45-02d8b6e084f8 gateway sip:1942345e0@[provider].co.uk REGED
internal profile sip:mod_sofia@<PublicIP>:42849 RUNNING (0)
=================================================================================================
3 profiles 0 aliases

** (internal-ipv6 is currently disabled) **

> sofia status profile internal
=================================================================================================
Name internal
Domain Name N/A
Auto-NAT false
DBName sofia_reg_internal
Pres Hosts
Dialplan XML
Context public
Challenge Realm auto_to
RTP-IP 192.168.42.249
Ext-RTP-IP stun:stun3.l.google.com:19302
SIP-IP 192.168.42.249
Ext-SIP-IP <PublicIP>
URL sip:mod_sofia@<PublicIP>:42849
BIND-URL sip:mod_sofia@<PublicIP>:42849;maddr=192.168.42.249;transport=udp
HOLD-MUSIC local_stream://default
OUTBOUND-PROXY N/A
CODECS IN H264,H263,H261,opus@16000h@10i,opus@16000h@20i,opus@8000h@10i,opus@8000h@20i,iLBC@30i,G7221@16000h,G7221@32000h,GSM@40i,G722,G726-16,G726-24,G726-32,G726-40,LPC,G729,G723,AMR,PCMU,PCMA
CODECS OUT H264,H263,H261,opus@16000h@10i,opus@16000h@20i,opus@8000h@10i,opus@8000h@20i,iLBC@30i,G7221@16000h,G7221@32000h,GSM@40i,G722,G726-16,G726-24,G726-32,G726-40,LPC,G729,G723,AMR,PCMU,PCMA
TEL-EVENT 101
DTMF-MODE rfc2833
CNG 13
SESSION-TO 0
MAX-DIALOG 0
NOMEDIA false
LATE-NEG false
PROXY-MEDIA false
ZRTP-PASSTHRU false
AGGRESSIVENAT true
CALLS-IN 0
FAILED-CALLS-IN 0
CALLS-OUT 0
FAILED-CALLS-OUT 0
REGISTRATIONS 0

Hope that helps.

Do you have a static external IP address?

No. It is dynamic. But it is supported by FreeSWITCH. Thankfully, it doesn't change often. I feel I am one of the many unfortunates who has fallen through the 'expansive' net of NAT support tools.

Also, FreeSWITCH's UPnP code is not that compatible and doesn't work with my particular router, possibly another issue with a poor/broken software implementation. I have pointed the authors to miniupnpc to look at their UPnP code, which DOES seem to work on my router! IMHO, when both sides implement software poorly and are more willing to blame the other's poor implementation, we get this needless, ego-induced incompatibility at the end of it all.

Describe your topology, are all your endpoits on your LAN? Or are they all external? Or is there a mixture?

A mixture. As the author of FS explained that the single 'internal' SIP profile can manage endpoints from both inside and outside the LAN via it's NAT detection. He could be overselling his own code, though :/

[Cisco E20 Video Endpoint] <----> [Sky Router w/NAT] <----> {Internet} <----> [Sky Router w/NAT & TCP/UDP ports udp/tcp5080 & udp/tcp5060 & udp16384-32768 fwd to FS] <----> [Gb LAN switch] <----> [Fusion PBX on FreeSWITCH VM w/ bridged NIC]

I have another E20 endpoint connected in to the Gb LAN switch with a private IP.

Apologies for the ASCII art network diagram.

I had everything working on-LAN, but when I deployed the endpoint, NAT showed me it's arse and I've been dealing battling it ever since. Well, not so much NAT per sé, as much as the implementation I have been left with.

I know UPnP also has it's 'idiosyncrasies'. I'm not sure if I can replace the router and keep my contract, it's on Sky Broadband in the UK... They're awful, IMHO. I have a bastardised Netgear router with a Sky logo emblazoned on it. Eurgh.

I don't suppose there are any FreeSWITCH devs hanging around who may be able to shed some light on this?

Thanks again and I hope this sheds some light on what you're thinking about

 

[Adrian Fretwell]

Still don't see where "stun:stun3.l.google.com:19302" is coming from. Maybe you have this set in the variables.

Take this one stage at a time, remove all references to stun in sip_ip, sip_ext_ip etc. and replace with IP addresses only. Restart freeswitch and see what you have then.

 

[stin]

Still don't see where "stun:stun3.l.google.com:19302" is coming from. Maybe you have this set in the variables.

Yes. The stun URL is coming from external_sip_ip and external_rtp_ip which is set in Advanced -> Variables (or vars.xml).

My logic being that every external packet needs to come in through the router's public IP.

Although, the external_rtp_ip doesn't seem to have been evaluated in the same way as external_sip_ip seems to have been.

I read in another thread that I should just set external_rtp_ip to "auto" as "it sorts itself out"?? :/ Hard to tell some guesses from actual knowledge until you've tried yourself, though. It didn't work, btw.

Take this one stage at a time, remove all references to stun in sip_ip, sip_ext_ip etc. and replace with IP addresses only. Restart freeswitch and see what you have then.

I have no static IP to put in. I used to use 'auto-nat' until I found out FS UPnP can't talk to my router.

I will put my current public IP in instead and report back with the results. Do you reckon I should do the same with the RTP IP variables? Set my current ones??

 

[stin]

After setting external_sip... and external_rtp_ip to my public IP then flushing the cache and reloading the profile, the port number was still a new random 5-digit port number.

But, after another cache flush and profile restart, the port number seems to have now settled back on 5060.

Now, when I used stun, it did choose 5060 one time, but never again.

After a few more restarts, it has settled on 5060.

What next?

 

[stin]

I just read this: "ATTENTION: AS OF 2012Q4, 'ext–' prefixed params cited above when populated with to-be-resolved DNS strings -- e.g. name="ext–sip–ip" value="stun:stun.freeswitch.org" or name="ext‑rtp–ip" value="host:mypublicIP.dyndns.org" -- are resolved to IP addresses once only at FS load time and const thereafter. FS is blind to (unaware of) any subsequent changes in your environment's IP address. Thus, these ext– vars may become functionally incompatible with the environment's current IP addresses with unspecified results in call flow at the network layer. FS restart is required for FS to capture the now-current, working IP address(es)."

So STUN isn't actually a viable option after all. Oh well.

I seem to encounter issues earlier and earlier each time I install and deploy FS/FPBX...

The first time I deployed it (~8 ya) I had a trunk established and encrypted communications, off-site endpoints, the lot. Then, recently, the deployment I did had literal variable names being passed to my SIP UAs instead of the values they represented. And now, NAT kills the idea stone dead. I am not confident that I will be able to get this working...

Maybe I'm 'getting too old' and tired to keep up the 'good fight' of troubleshooting the latest generation of bugs, but software seems to fall over in a strong breeze nowadays :/ lol

idk

Looks like I'll need to chang my ISP, to get a new router, to get UPnP working, to fix the issues in FreeSWITCH.

 

[Adrian Fretwell]

What next?

Try registering an endpoint...

Try one on the LAN first, then if that works, you say you have forwarded ports, so then try an external endpoint.

sngrep is your friend for watching SIP message exchanges whilst diagnosing connectivity issues.

Using "stun:..." in the external_sip_ip etc. is not a great solution because it is only evaluated at FreeSwitch start up time. If your external IP changes then you have to restart FreeSwitch. There is no good solution to FreeSwitch behind NAT with a dynamic IP address when you want to register external endpoints.

 

[stin]

Try registering an endpoint...

Try one on the LAN first, then if that works, you say you have forwarded ports, so then try an external endpoint.

I now have an active registration from the off-LAN endpoint.

sngrep is your friend for watching SIP message exchanges whilst diagnosing connectivity issues.

I've never heard of it - is it a grep variant? If it's one of the best tools for this area, it probably needs pinning/a sticky post on the forum index as an appropriate troubleshooting tool. I have noticed that there isn't a 'recommended troubleshooting tools' post :/ I just use fs_cli to trace SIP packets, but get confused between tracelevel, loglevel and console log level lol - So many different loggy levels lol

Using "stun:..." in the external_sip_ip etc. is not a great solution because it is only evaluated at FreeSwitch start up time. If your external IP changes then you have to restart FreeSwitch. There is no good solution to FreeSwitch behind NAT with a dynamic IP address when you want to register external endpoints.

Aye. Seen, above.

I just read this: "ATTENTION: AS OF 2012Q4, 'ext–' prefixed params cited above when populated with to-be-resolved DNS strings -- e.g. name="ext–sip–ip" value="stun:stun.freeswitch.org" or name="ext‑rtp–ip" value="host:mypublicIP.dyndns.org" -- are resolved to IP addresses once only at FS load time and const thereafter. FS is blind to (unaware of) any subsequent changes in your environment's IP address. Thus, these ext– vars may become functionally incompatible with the environment's current IP addresses with unspecified results in call flow at the network layer. FS restart is required for FS to capture the now-current, working IP address(es)."

So, in conclusion:
1. STUN is not a viable solution for a site-based FreeSWITCH install behind a dynamic IP. At least it seems to mess with port assignments. If you have a static IP you can just put that in. So, STUN seems most useful to mobile endpoints which move (eg) from LAN to WLAN to LAN;

2. UPnP seems to be the ONLY solution for this deployment scenario. However, FreeSWITCH's UPnP code is, at best, 'unfinished';

3. FreeSWITCH needs to finish developing the UPnP code to improve compatibility with more routers;

______

I think I'm getting a bit tired from constantly fixing technical problems. I used to thrive on troubleshooting and coding when I was younger and had more time, but now I just want things to work, you know?

IMHO, UPnP just needs fixing in FreeSWITCH. I would say I'd have few to no issues with my deployment and confidently assume that a good deal of other FreeSWITCH users would be much happier, too.

I'll have to come back to this tomorrow after I've slept and eaten properly lol

I feel the problem is NOT with my efforts, but the FreeSWITCH codebase, specifically the UPnP code which is, at best, 'unfinished'. I hope the FS devs can take this on board - I have e-mailed them about this (and the lack of proper documentation.)

Maybe it's just that FreeSWITCH isn't 100% ready for widespread use, yet. It's up to the FreeSWITCH devs how far they want to move it forward, at the end of the day.

I wonder if I could just write a script which injects the changed IP into the configs and reload the SIP profiles on-the-fly without killing existing calls.

Many thanks for your thoughts today, gentlemen... I really do appreciate taking the time to read my posts and respond.