Bug #1601
Problems connecting with Jitsi
| Status: | Feedback | Start date: | 07/17/2013 | |
|---|---|---|---|---|
| Priority: | High | Due date: | 09/19/2013 | |
| Assignee: | ex1st | % Done: | 0% | |
| Category: | - | Spent time: | - | |
| Target version: | - | |||
| Component: |
Description
The issue I am seeing from multiple users via Twitter (people mentioning OStel or OStel.co in their tweets, or @guardianproject help requests), is that in the last 24-48 hours, there has been an increase in people having problems registering to OStel.co with Jitsi on Mac or Windows.
I myself have replicated this issue on Windows 7 with Jitsi 2.2, though on Ubuntu 13 with Jitsi 2.2 I did NOT have the problem. It worked fine.
On Windows, there was a problem with connecting to the server, NOT authenticating. In the Jitsi logs it showed a problem in connecting to the OStel port 5060 for setting up Via Headers.
When I switched from using my home wifi with Comcast Xfinity, to using my Tmobile wifi hotspot (from my phone), i WAS able to connect. And so, I don't believe this is a bug in our service, or software, but there is some issue somewhere, perhaps in Comcast? that caused this problem.
We should work to deduce to help our users be happier and more successful and securing their voice and video conversations.
History
#1 Updated by lee over 4 years ago
- Status changed from New to Feedback
This is not a bug in Jitsi, it's a design issue of their setup wizard and some quirks of the SIP protocol. It's a known problem. I'll explain.
SIP requires a service listen on UDP port 5060 to be considered a SIP service. Kamailio observes this requirement. So I'm in a pickle. I can
1) Leave everything as it is
2) Use iptables to block incoming connections from 0.0.0.0/0 to port 5060
If I choose 1, we are now faced with a client problem. By default Jitsi provides a SIP setup wizard which is a form of reduced complexity. When the user adds their account information to this form, Jitsi chooses UDP port 5060 by default. The option to use encrypted signalling is not even offered. But for some reason, there are many users with clients that are attempting to use encrypted signalling over the unencrypted port. This will fail, by design. It's like the difference between HTTP and HTTPS.
If I choose option 2, Now Jitsi will fail to register after users enter information into the default SIP setup wizard. So the initial response is similar but this time it's the server explicitly blocking traffic.
Unfortunately, SIP doesn't have the concept of a "protocol redirect" such that requests to one port are redirected to another...
or does it..?
#2 Updated by n8fr8 over 4 years ago
- Assignee changed from lee to ex1st
Here is my support email response template, and what we should add to the FAQ:
There has been some change with Jitsi on Windows that is causing a problem.
Here is the solution:
1) Enable Accounts>Edit>Connection>Proxy Options>Preferred transport>TLS.
2) Make sure proxy is ostel.co and port is 5061
Let us know how that goes.
#3 Updated by lee over 4 years ago
I'm gonna open up a new issue that might solve this by replying with a 302 redirect to the client.
#4 Updated by jamesbeebop over 4 years ago
n8fr8 wrote:
Here is my support email response template, and what we should add to the FAQ:
There has been some change with Jitsi on Windows that is causing a problem.
Here is the solution:
1) Enable Accounts>Edit>Connection>Proxy Options>Preferred transport>TLS.
2) Make sure proxy is ostel.co and port is 5061
Let us know how that goes.
I created an account at ostel.co today, and experienced this problem adding the account to Jitsi (this recommendation to set the proxy explicitly fixed the problem). I'm on Linux Mint 14 using Jitsi 2.2.4603.9615.
#5 Updated by ex1st over 4 years ago
Updated the code on git. Now waiting to take it live.
#6 Updated by ex1st over 4 years ago
- Due date set to 09/19/2013
Lee got a new computer and doesn't have the Ruby stuff installed to test local. Should get old computer back on the 18th and will push updates.