Recent content by Adrian Fretwell

It doesn't really mater, I would upgrade and then do this immediately after.

@manikanta when you come back, either PM me or start a new thread rather than adding to this one.

@manikanta I'm sorry, I don't have time for calls. I freely help people when time allows, but I do need to work at the day job.

No $$ variables are fine. I just meant that I can't tell what they are set to. You probably set some of them in Switch Variables and FreeSWITCH uses defaults for the rest. I don't think there is a problem with your SIP profile. Someone hacking a customer phone is far more likely. We had that...

I'm sorry but I do not understand what you are trying to do or how you are trying to do it. I read your point 1 above and I don't even understand that! By default FreeSWITCH uses an SQLite database for internal storage including registrations, why do you need to keep a record of them? You can...

The first thing I noticed is that $${internal_auth_calls is missing a closing bracket. There is not much we can tell from a SIP profile alone, for example we don't know the actual value in the $$ variables. Can you be more specific about what happened? Did they use a password? I assume it...

If I'm understanding your question correctly, bridging outbound using TLS is fairly straight forward. You can pass all the required parameters in the bridge statement: <action application="bridge" data="{rtp_secure_media=true}sofia/internal/$1@server.b.com:5061;transport=tls"/> In the above...

As of the following commit today, the checking of allowed IP addresses has moved away from simple string comparisons to use the python ipaddress module. https://github.com/djangopbx/djangopbx/commit/5eb6649337baefa8c6d4e6a51e750eda4719e004 This is a breaking change because single IP addresses...

If I'm reading this tread correctly, the only things you haven't changed out are the handsets? I have seen faulty network switches intermittently send RTP streams to the wrong MAC addresses, but I doubt this is happening in your case because the base unit only has one MAC address.

It's a long while since I looked at Fusion, but I'm pretty sure it is hard coded into the code that creates the statement to bridge all the destinations. It's a channel variable called group_confirm_file that is normally set to "ivr/ivr-accept_reject.wav" This may have changed in the later versions?

Correct me if I'm wrong. rport helps in the correction of bad headers caused by NAT, but freeswitch will still report the endpoint as UDP-NAT. If the end point itself is aware of NAT and does not send any headers containing RFC1918 addresses then freeswitch will report the endpoint as UDP.

If you mean "How do you make your endpoint NAT aware" You can configure STUN, ICE or TRUN, if you endpoint device supports one of those protocols.

I'm sure you are getting confused somewhere. Moving FreeSWITCH DB from SQLLite into PostgreSql, has nothing to do with registering extensions and it is not specific to DjangoPBX. In fact for someone new to FreeSWITCH and/or DjangoPBX I would recommend leaving the FreeSWITCH DB in SQLite.

Happy to help, but you need to be more specific. To say "encountered issues with Linphone connectivity" is like me saying to you "My car engine won't start, what could be wrong?" Try to get a packet capture of the connection attempt, sngrep is a good tool. Is there anything in the Freeswitch...

Absolutely true and exactly what we find in production. I completely understand why people ask the question, but there aren't any good answers and what works for one person may not work for someone else. I'm not going to get into it here, there are may other threads that discuss this. You can...