Search results

Hi @gflow I wanted to give others time to respond before jumping in, but as no one has... The DjangoPBX software is still at the Alpha stage of testing, so I imagine it would only be a few brave individuals that will have deployed into production. I have a couple of instances in production...

Default command line sngrep with no switches should provide the detail you require.

Sounds like the ACK following the 200 OK is going missing. See if you can get a packet capture of a call to prove this. sngrep is a very useful tool.

I believe the database structure only allows for a user to be allocated to one domain. There is a one to many relationship between Domains and Users. One Domain can have many users but a User can have only one Domain.

Having said the above, I notice that there is a line in the installer that changes the Nginx user: sed -i "s/www-data/django-pbx/g" /etc/nginx/nginx.conf I looked at a couple of working test installs done last week and they all have www-data as the Nginx user in the nginx.conf file. I ran...

Probably need to did into this a little deeper. There should be no problem with Nginx running as the www-data user. uWSGI creates the socket with user django-pbx and group www-data so there should be no permissions issue. As @jcre says we need to confirm the operating system, and if it is a...

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