Search results

I've done a few packet traces before and I reckon I can read them well enough. I have recently scanned some info on SDP and SIP, I drew out some ladder diagrams to better help me see the conversation and relevant SDP media descriptors to check ports. It threw me for a second when I saw my...

Thank you very much for your input, Adrian. It is very much appreciated. Apologies for the length of my posts, but I tend to think having too much information is better than not enough. Also, I haven't had anyone who I can talk with about technical stuff for a few years, which won't help much...

Hello, I am having some strange times with FREESwitch and FusionPBX. Originally, I had a remote phone which I was trying to get working over NAT as my internal ones worked fine (I have since found out - not from the horse's mouth - that there is a good chance I have a SIP ALG enabled on my...

I presume the number of possible causes is too large to go into? :/

What are they? Do you have a link, please?

Having the issue, too. Does anyone else have any knowledge about this? (Rant: I have found that digging for detailed explanatory information for troubleshooting FreeSWITCH is, frankly, fruitless and, IMHO, I do think that the FreeSWITCH project needs to allocate resources to work towards...

Thank you Adrian. I know. I shouldn't read-up on stuff when I'm tired. Aye. I think I'd already decided that STUN is not an option. No STUN. Bad STUN. Sit! Stay! The endpoints are registered via dynamic domain name. As far as I can tell, a DNS query happens prior to registration, so as long...

I would tend to disagree with that, too. IMHO, occasionally, the documentation inspires more questions than it answers. Such as "What is the 'lan' ACL for? Why shouldn't I put phone and public IPs in there? And what would that mean to FreeSWITCH? What is the 'domain' field for? Why would...

<thought> Hmmmm... I could try putting my FS server into my DMZ, then I should only need STUN to work as the random ports chosen by the STUN server would be in the DMZ. I could also try a different STUN server. Still can't explain why ext_rtp_ip is not evaluating the stun:... URL when it...

I now have an active registration from the off-LAN endpoint. 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...

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

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

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

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

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

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? :(

Thanks for your input, Adrian. 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...

Maybe the pertinent thing to do is to re-enable this by default for 'superadmins', but not for 'admins'. Maybe even encourage, after installation, the creation of an 'admin' account under the superadmin account which can't delete or create domains, only administer settings within it's...

Oh, dear! Fantastic idea. I just double-checked the setting, as I was going to get a screenshot for you, but the setting "delete_domain" was not ticked. I will tick it now to see what happens. So, the original posted advice I had initially read stated that the setting to enable was...

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