Hello,
For some years, I have been trying to set up RTC between machines, with varying degrees of succes. Unfortunately, so far it never really worked; at best it worked a bit. Daniel Pocock recently wrote on a Debian list that he was willing to help people with this, so I asked him. He suggested me (among other things) to subscribe here, so I did.
About me: I'm a member of the Debian project (a "DD"), and I try to run only free software on my computers. I was born and raised in the Netherlands, and am currently a graduate student in the USA. For this reason, my interest in RTC got a new push.
What I want seems simple to me: - I want to have audio and video contact with a select group of friends. - I have full control over all computers. They all run Debian GNU/Linux and I can install anything I need. - I want all communication to be encrypted. - I want no communication to be routed through third party servers (such as Google), apart from the ones which make up the direct connection between the hosts, of course.
This would all work without problems (I think), except for: - All computers in the Netherlands are behind masquerading firewalls over which I have no control.
That shouldn't be a big problem; there's STUN and TURN and lots of people have that problem, so it is certainly solved by now. Or is it?
Here are some things I have tried in various combinations, with an explanation of the result:
Ekiga (SIP): video just won't work. Audio used to work most of the time when I was in the Netherlands, but doesn't work nowadays.
Empathy (XMPP): Using my own jabber server (jabberd14), I have good results for text messages and until recently I had good results with audio. Video is totally broken, which seems to be a gstreamer issue: when the other user switches their video on, my camera is activated. Images from long ago are interleaved with current images; sometimes with images from slightly less long ago, or with the standard "no signal" still image. The other way (from the masqueraed hosts) video used to work sometimes. Calling only worked one way; the other way I could call, but they couldn't pick it up. Despite all the problems, this is by far the best result I've had, where we actually had audio contact and even some limited video contact. Unfortunately, with a recent system update I have been unable to have any contact other than text messages using Empathy.
Empathy (SIP): SIP connections just don't work with masquerading, it seems. I've set up an asterisk server, which works as long as no masqueraded hosts are using it. The masqueraded hosts can call the server, get automated answers, but cannot be connected to other users (which doesn't make much sense to me, because asterisk would pass on all the traffic, so I don't see the difference between an automated answer generated by asterisk itself and a real person answering). Anyway, it didn't work well. Also, Asterisk seems to have very limited support for video, but I didn't really get around to trying it out.
Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on its own. When started from a terminal, it spews a lot of warnings and errors, but it does seem to work. Then again, it crashes at random times. It seems I need to disable several settings to make sure it doesn't contact Google; I really don't like that. As for how it works: so far it doesn't really (or at least not with the masquerated hosts), but perhaps I have to try harder.
As I wrote above, I tried setting up several servers to make things work. My experience so far:
jabberd14: It takes some trouble to configure it, but it's pretty straightforward. When it's set up, it works. It supports encrypted messaging, which is good. I'm not sure if the audio and video calls are encrypted as well; I'm guessing they might not be. It would be good if clients would warn about this (if my guess is right).
ejabberd: I just tried setting this up, as Daniel wrote he had been using it for years. I find it very hard to set up, and there is virtually no documentation. It has ejabberdctl, but I had to learn about its existence from a web search on how to set the system up. This really should be a lot less painful. Anyway, I got a local client connected to it now, but I'm trying to connect the other client through a local turn server (see below), which doesn't work; I think the problem is with the turn server, not with ejabberd. I tried not using the turn server, at which point jitsi crashed and I gave up for now. I'll try again later.
asterisk: This seems to work well for what it is intended for: audio only. Also, I found it disappointing that the conference room plugin (to make a conference call with multiple users) depends on the dahdi plugin, which cannot be loaded if you don't have the hardware in your computer. Anyway, as I wrote above asterisk also mysteriously failed to work when used from a masqueraded host. Asterisk's documentation is very complete, but targeted at people who want to run a telephone network with hundreds of users, many of which have physical SIP phones and want to call other PSTN lines. This makes it a bit hard to read sometimes.
resiprocate-turn-server: Daniel wrote I might need this, which makes sense; after all, TURN is supposed to solve all problems related to masquerading. But this one is impossible to set up, it seems. I installed the package; it didn't ask any questions, so I hoped it would just work. It didn't. I looked at the man page (which I found by looking at the list of files installed by the package...), but that only gave a link to the project's web page, which has surprisingly little information. The only information about the turn server is that there is a config file. That's still useful, because the man page didn't mention it, but really I'd like a "how to use this program" recipe. Or what I really want is that debconf asks me a few questions on install, and I don't have to touch anything; it just works. Anyway, after changing some settings in the config file and restarting it, it still doesn't work. I don't know why not.
Finally, some good news: after all the failures with XMPP and SIP, I looked at something entirely different: mumble. It's written to allow communication during multiplayer games, and works fine. But it doesn't support video, doesn't do echo cancellation, and you can't "call" anyone; you must have arranged to meet through some other channel. So certainly not the ideal solution, but it's currently the only way I can get working audio communication.
I suppose this story sounds like a lot of misery. But there is hope: I really want it to work, and I want it to work for others as well. So if you can help me to make it work, I'll try to document things, and send patches to Debian packages (and upstream, if applicable) to make things better.
But before I can do that, it has to work for me. So please advise me on how to get there.
Thanks, Bas
On 21 Sep 2013 02:22, "Bas Wijnen" wijnen@debian.org wrote:
Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on its own.
Well, I am afraid there's no changing this, so if you have an aversion to the language, you would simply need to use something else.
--sent from my mobile
On 21/09/13 02:15, Bas Wijnen wrote:
Hello,
For some years, I have been trying to set up RTC between machines, with varying degrees of succes. Unfortunately, so far it never really worked; at best it worked a bit. Daniel Pocock recently wrote on a Debian list that he was willing to help people with this, so I asked him. He suggested me (among other things) to subscribe here, so I did.
About me: I'm a member of the Debian project (a "DD"), and I try to run only free software on my computers. I was born and raised in the Netherlands, and am currently a graduate student in the USA. For this reason, my interest in RTC got a new push.
What I want seems simple to me:
- I want to have audio and video contact with a select group of friends.
- I have full control over all computers. They all run Debian GNU/Linux and I can install anything I need.
- I want all communication to be encrypted.
- I want no communication to be routed through third party servers (such as Google), apart from the ones which make up the direct connection between the hosts, of course.
This would all work without problems (I think), except for:
- All computers in the Netherlands are behind masquerading firewalls over which I have no control.
That shouldn't be a big problem; there's STUN and TURN and lots of people have that problem, so it is certainly solved by now. Or is it?
Here are some things I have tried in various combinations, with an explanation of the result:
Ekiga (SIP): video just won't work. Audio used to work most of the time when I was in the Netherlands, but doesn't work nowadays.
Empathy (XMPP): Using my own jabber server (jabberd14), I have good results for text messages and until recently I had good results with audio. Video is totally broken, which seems to be a gstreamer issue: when the other user switches their video on, my camera is activated. Images from long ago are interleaved with current images; sometimes with images from slightly less long ago, or with the standard "no signal" still image. The other way (from the masqueraed hosts) video used to work sometimes. Calling only worked one way; the other way I could call, but they couldn't pick it up. Despite all the problems, this is by far the best result I've had, where we actually had audio contact and even some limited video contact. Unfortunately, with a recent system update I have been unable to have any contact other than text messages using Empathy.
Video worked fine in squeeze, I even built Debian Live CDs and gave them to several people who I communicate with regularly and it was all fine.
Since upgrading to wheezy, I can't communicate reliably with Empathy. This is a big no-no for any communications product, once people lose faith in it, it is very hard to recover
Empathy is also hard coded to use Google's TURN server, it doesn't use the free software TURN servers packaged in Debian. Upstream has not given feedback on their priority for resolving this issue. The resolution simply requires adding some extra config fields in the setup form so you can choose your own TURN server.
Empathy (SIP): SIP connections just don't work with masquerading, it seems. I've set up an asterisk server, which works as long as no masqueraded hosts are using it. The masqueraded hosts can call the server, get automated answers, but cannot be connected to other users (which doesn't make much sense to me, because asterisk would pass on all the traffic, so I don't see the difference between an automated answer generated by asterisk itself and a real person answering). Anyway, it didn't work well. Also, Asterisk seems to have very limited support for video, but I didn't really get around to trying it out.
I don't know if they support ICE with SIP
Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on its own. When started from a terminal, it spews a lot of warnings and errors,
Java can also be a good thing, as it means users on Linux, Mac and Windows all get the same code and it is easier for the developers to make sure that every release is interoperable across all platforms.
For communications software, interoperability is crucial and Java helps with that.
but it does seem to work. Then again, it crashes at random times. It seems I need to disable several settings to make sure it doesn't contact Google; I
Can you raise a bug against the package listing those things you had to disable?
really don't like that. As for how it works: so far it doesn't really (or at least not with the masquerated hosts), but perhaps I have to try harder.
Did you put in the TURN server settings?
As I wrote above, I tried setting up several servers to make things work. My experience so far:
jabberd14: It takes some trouble to configure it, but it's pretty straightforward. When it's set up, it works. It supports encrypted messaging, which is good. I'm not sure if the audio and video calls are encrypted as well; I'm guessing they might not be. It would be good if clients would warn about this (if my guess is right).
ejabberd: I just tried setting this up, as Daniel wrote he had been using it for years. I find it very hard to set up, and there is virtually no documentation. It has ejabberdctl, but I had to learn about its existence from a web search on how to set the system up. This really should be a lot less painful. Anyway, I got a local client connected to it now, but I'm trying to connect the other client through a local turn server (see below), which doesn't work; I think the problem is with the turn server, not with ejabberd. I tried not using the turn server, at which point jitsi crashed and I gave up for now. I'll try again later.
Make sure ejabberd works well for chat first
Make sure you have the SRV records, e.g. for pocock.com.au:
_xmpp-client._tcp IN SRV 5 0 5222 jabber.trendhosting.net. _xmpp-server._tcp IN SRV 5 0 5269 jabber.trendhosting.net.
From Debian, you can use CaCert.org certificates and the clients will
trust them.
Multi-domain and IPv6 are slightly tricky, let me know if you need examples to make them work. I also have it linked to LDAP.
asterisk: This seems to work well for what it is intended for: audio only. Also, I found it disappointing that the conference room plugin (to make a conference call with multiple users) depends on the dahdi plugin, which cannot be loaded if you don't have the hardware in your computer. Anyway, as I wrote above asterisk also mysteriously failed to work when used from a masqueraded host. Asterisk's documentation is very complete, but targeted at people who want to run a telephone network with hundreds of users, many of which have physical SIP phones and want to call other PSTN lines. This makes it a bit hard to read sometimes.
Skip Asterisk for now, it is overkill, and as you point out, no video.
It is very good for building a business phone system though
resiprocate-turn-server: Daniel wrote I might need this, which makes sense; after all, TURN is supposed to solve all problems related to masquerading. But this one is impossible to set up, it seems. I installed the package; it didn't ask any questions, so I hoped it would just work. It didn't. I looked at the man page (which I found by looking at the list of files installed by the package...), but that only gave a link to the project's web page, which has surprisingly little information. The only information about the turn server is that there is a config file. That's still useful, because the man page didn't mention it, but really I'd like a "how to use this program" recipe. Or what I really want is that debconf asks me a few questions on install, and I don't have to touch anything; it just works. Anyway, after changing some settings in the config file and restarting it, it still doesn't work. I don't know why not.
The config files are fully commented with instructions, but that was only done after the wheezy freeze began.
The release team have so far not approved further uploads http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717420
but upstream and the package maintainer (myself) are quite happy to upload those changes when authorised to do so.
You can view the commented version of the file here:
https://github.com/resiprocate/resiprocate/blob/master/reTurn/reTurnServer.c...
Note that trunk has slightly changed, the version in wheezy does not recognise the option "UserDatabaseFile = users.txt" and you need to keep using a single set of credentials for all users, by specifying something like this in reTurnServer.config:
LongTermAuthUsername = test LongTermAuthPassword = password
Finally, some good news: after all the failures with XMPP and SIP, I looked at something entirely different: mumble. It's written to allow communication during multiplayer games, and works fine. But it doesn't support video, doesn't do echo cancellation, and you can't "call" anyone; you must have arranged to meet through some other channel. So certainly not the ideal solution, but it's currently the only way I can get working audio communication.
I suppose this story sounds like a lot of misery. But there is hope: I really want it to work, and I want it to work for others as well. So if you can help me to make it work, I'll try to document things, and send patches to Debian packages (and upstream, if applicable) to make things better.
But before I can do that, it has to work for me. So please advise me on how to get there.
I've been getting more recent versions of packages into jessie and I am very hopeful that with feedback from people like yourself we will be able to fine tune them further to "just work" and jessie will make a big impact in this space.
Please put specific comments about the problems into the bug tracker, that definitely helps us too.
Regards,
Daniel
On Sat, Sep 21, 2013 at 10:25:44AM +0300, Emil Ivov wrote:
On 21 Sep 2013 02:22, "Bas Wijnen" wijnen@debian.org wrote:
Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on its own.
Well, I am afraid there's no changing this, so if you have an aversion to the language, you would simply need to use something else.
I didn't mean to suggest it should be changed. I was just getting frustrated that nothing worked, and a program which throws errors before it even started isn't helping. ;-)
I'm guessing that it's tested using a different java than I have (I'm just guessing it doesn't throw these errors when the developers run it). And that matters more than it should.
Also:
On Sat, Sep 21, 2013 at 09:44:30AM +0200, Daniel Pocock wrote:
Java can also be a good thing, as it means users on Linux, Mac and Windows all get the same code and it is easier for the developers to make sure that every release is interoperable across all platforms.
For communications software, interoperability is crucial and Java helps with that.
Which is entirely true. But it would be good if it would indeed work on all platforms. Random crashes are extremely frustrating, especially after trying so many things for so long, to achieve something which really should be simple.
I mean, what is the big problem? I have two computers I control. I can connect() from one to the other and have a working network connection. I have working audio and video hardware on both sides. How hard can it be to set up a link to make us see and hear each other?
Since upgrading to wheezy, I can't communicate reliably with Empathy. This is a big no-no for any communications product, once people lose faith in it, it is very hard to recover
In their favor, there aren't any working alternatives. Which isn't a good thing, of course.
Empathy is also hard coded to use Google's TURN server, it doesn't use the free software TURN servers packaged in Debian.
I consider that a very serious problem. Google is not exactly known for being good with privacy.
Empathy (SIP): SIP connections just don't work with masquerading, it seems. I've set up an asterisk server, which works as long as no masqueraded hosts are using it. The masqueraded hosts can call the server, get automated answers, but cannot be connected to other users (which doesn't make much sense to me, because asterisk would pass on all the traffic, so I don't see the difference between an automated answer generated by asterisk itself and a real person answering). Anyway, it didn't work well. Also, Asterisk seems to have very limited support for video, but I didn't really get around to trying it out.
I don't know if they support ICE with SIP
Asterisk does; it just ignores the reported return address and uses getpeername() instead. And it works, too; it's used when making a call to an auto-responder, and that works.
but it does seem to work. Then again, it crashes at random times. It seems I need to disable several settings to make sure it doesn't contact Google; I
Can you raise a bug against the package listing those things you had to disable?
Sure, but perhaps I should first ask if I am right. In my XMPP account settings, "Enable Google Contacts search" was on. I originally also disabled "Use Google's Jingle" and "Use JingleNodes", but now I see it again, I suppose that's just technology designed by Google, not actually contacting their servers. Or is it?
really don't like that. As for how it works: so far it doesn't really (or at least not with the masquerated hosts), but perhaps I have to try harder.
Did you put in the TURN server settings?
I did, but on localhost it doesn't care (it works, even if the password is wrong; of course on localhost I don't need the TURN server anyway, but I had expected an error nonetheless) and from the masqueraded host it says the password is wrong even though it isn't.
Make sure ejabberd works well for chat first
Make sure you have the SRV records, e.g. for pocock.com.au:
_xmpp-client._tcp IN SRV 5 0 5222 jabber.trendhosting.net. _xmpp-server._tcp IN SRV 5 0 5269 jabber.trendhosting.net.
Wait, what? Do I need to change my DNS records just to start a one-on-one video call with a computer that can already contact me? I can do it; I happen to have control over my DNS, but I really wouldn't expect to need it.
From Debian, you can use CaCert.org certificates and the clients will trust them.
Yes, I'm using those already. Unfortunately Ubuntu, Mac and Windows aren't accepting them. :-(
Multi-domain and IPv6 are slightly tricky, let me know if you need examples to make them work. I also have it linked to LDAP.
No, I don't need anything complex, thanks.
Skip Asterisk for now, it is overkill, and as you point out, no video.
It is very good for building a business phone system though
Yes, it looks like it, and it works well so far, except for NAT traversal. And its documentation is fantastic (except that its focus is not where I needed it).
The config files are fully commented with instructions, but that was only done after the wheezy freeze began.
The release team have so far not approved further uploads http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717420
but upstream and the package maintainer (myself) are quite happy to upload those changes when authorised to do so.
While I understand your reasoning, the usual way in Debian is not to change anything once it is released, except for security and really urgent things (virus definition updates; timezone changes). If you have a much better version of the package, it might be considered for the next point release, but not for stable itself. The downside of this method is that stable is always outdated (you're left with the state when it was frozen). The upside is that it means things are indeed really stable (new "fixes" often introduce new bugs as well).
Anyway, to get back on topic, all this doesn't matter for me, as I'm running the TURN server on unstable, so I have version 1.8.13-1.
I see you have uploaded 1.9.0~beta1-1 to experimental, at high urgency, with no information in the changelog why this was so urgent. Is there a big difference with 1.8.13? Why didn't you upload to unstable?
You can view the commented version of the file here:
https://github.com/resiprocate/resiprocate/blob/master/reTurn/reTurnServer.c...
The comments didn't make it to unstable, indeed. Thanks.
Note that trunk has slightly changed, the version in wheezy does not recognise the option "UserDatabaseFile = users.txt" and you need to keep using a single set of credentials for all users, by specifying something like this in reTurnServer.config:
LongTermAuthUsername = test LongTermAuthPassword = password
It seems to be the same in sid, looking at the config file?
I've been getting more recent versions of packages into jessie and I am very hopeful that with feedback from people like yourself we will be able to fine tune them further to "just work" and jessie will make a big impact in this space.
I would definitely like that. My main goal would be that two people, where at least one of them is reachable on a public IP (which may not be the IP the host thinks it has), can make an encrypted video call by: - both installing a package - one person filling in the IP (and possibly the name) of the other person and nothing more. They should not need to set up any server, and they certainly shouldn't need to edit DNS entries.
Please put specific comments about the problems into the bug tracker, that definitely helps us too.
I'll do that.
Thanks, Bas
Bas, Have you checked out WebRTC at all? If you've got some of the latest Firefox or Chrome (maybe others) builds, you can try apprtc.appspot.com to meet your immediate goal.
Derek
On Sat, 2013-09-21 at 20:54 +0200, Bas Wijnen wrote:
On Sat, Sep 21, 2013 at 10:25:44AM +0300, Emil Ivov wrote:
On 21 Sep 2013 02:22, "Bas Wijnen" wijnen@debian.org wrote:
Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on its own.
Well, I am afraid there's no changing this, so if you have an aversion to the language, you would simply need to use something else.
I didn't mean to suggest it should be changed. I was just getting frustrated that nothing worked, and a program which throws errors before it even started isn't helping. ;-)
I'm guessing that it's tested using a different java than I have (I'm just guessing it doesn't throw these errors when the developers run it). And that matters more than it should.
Also:
On Sat, Sep 21, 2013 at 09:44:30AM +0200, Daniel Pocock wrote:
Java can also be a good thing, as it means users on Linux, Mac and Windows all get the same code and it is easier for the developers to make sure that every release is interoperable across all platforms.
For communications software, interoperability is crucial and Java helps with that.
Which is entirely true. But it would be good if it would indeed work on all platforms. Random crashes are extremely frustrating, especially after trying so many things for so long, to achieve something which really should be simple.
I mean, what is the big problem? I have two computers I control. I can connect() from one to the other and have a working network connection. I have working audio and video hardware on both sides. How hard can it be to set up a link to make us see and hear each other?
Since upgrading to wheezy, I can't communicate reliably with Empathy. This is a big no-no for any communications product, once people lose faith in it, it is very hard to recover
In their favor, there aren't any working alternatives. Which isn't a good thing, of course.
Empathy is also hard coded to use Google's TURN server, it doesn't use the free software TURN servers packaged in Debian.
I consider that a very serious problem. Google is not exactly known for being good with privacy.
Empathy (SIP): SIP connections just don't work with masquerading, it seems. I've set up an asterisk server, which works as long as no masqueraded hosts are using it. The masqueraded hosts can call the server, get automated answers, but cannot be connected to other users (which doesn't make much sense to me, because asterisk would pass on all the traffic, so I don't see the difference between an automated answer generated by asterisk itself and a real person answering). Anyway, it didn't work well. Also, Asterisk seems to have very limited support for video, but I didn't really get around to trying it out.
I don't know if they support ICE with SIP
Asterisk does; it just ignores the reported return address and uses getpeername() instead. And it works, too; it's used when making a call to an auto-responder, and that works.
but it does seem to work. Then again, it crashes at random times. It seems I need to disable several settings to make sure it doesn't contact Google; I
Can you raise a bug against the package listing those things you had to disable?
Sure, but perhaps I should first ask if I am right. In my XMPP account settings, "Enable Google Contacts search" was on. I originally also disabled "Use Google's Jingle" and "Use JingleNodes", but now I see it again, I suppose that's just technology designed by Google, not actually contacting their servers. Or is it?
really don't like that. As for how it works: so far it doesn't really (or at least not with the masquerated hosts), but perhaps I have to try harder.
Did you put in the TURN server settings?
I did, but on localhost it doesn't care (it works, even if the password is wrong; of course on localhost I don't need the TURN server anyway, but I had expected an error nonetheless) and from the masqueraded host it says the password is wrong even though it isn't.
Make sure ejabberd works well for chat first
Make sure you have the SRV records, e.g. for pocock.com.au:
_xmpp-client._tcp IN SRV 5 0 5222 jabber.trendhosting.net. _xmpp-server._tcp IN SRV 5 0 5269 jabber.trendhosting.net.
Wait, what? Do I need to change my DNS records just to start a one-on-one video call with a computer that can already contact me? I can do it; I happen to have control over my DNS, but I really wouldn't expect to need it.
From Debian, you can use CaCert.org certificates and the clients will trust them.
Yes, I'm using those already. Unfortunately Ubuntu, Mac and Windows aren't accepting them. :-(
Multi-domain and IPv6 are slightly tricky, let me know if you need examples to make them work. I also have it linked to LDAP.
No, I don't need anything complex, thanks.
Skip Asterisk for now, it is overkill, and as you point out, no video.
It is very good for building a business phone system though
Yes, it looks like it, and it works well so far, except for NAT traversal. And its documentation is fantastic (except that its focus is not where I needed it).
The config files are fully commented with instructions, but that was only done after the wheezy freeze began.
The release team have so far not approved further uploads http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717420
but upstream and the package maintainer (myself) are quite happy to upload those changes when authorised to do so.
While I understand your reasoning, the usual way in Debian is not to change anything once it is released, except for security and really urgent things (virus definition updates; timezone changes). If you have a much better version of the package, it might be considered for the next point release, but not for stable itself. The downside of this method is that stable is always outdated (you're left with the state when it was frozen). The upside is that it means things are indeed really stable (new "fixes" often introduce new bugs as well).
Anyway, to get back on topic, all this doesn't matter for me, as I'm running the TURN server on unstable, so I have version 1.8.13-1.
I see you have uploaded 1.9.0~beta1-1 to experimental, at high urgency, with no information in the changelog why this was so urgent. Is there a big difference with 1.8.13? Why didn't you upload to unstable?
You can view the commented version of the file here:
https://github.com/resiprocate/resiprocate/blob/master/reTurn/reTurnServer.c...
The comments didn't make it to unstable, indeed. Thanks.
Note that trunk has slightly changed, the version in wheezy does not recognise the option "UserDatabaseFile = users.txt" and you need to keep using a single set of credentials for all users, by specifying something like this in reTurnServer.config:
LongTermAuthUsername = test LongTermAuthPassword = password
It seems to be the same in sid, looking at the config file?
I've been getting more recent versions of packages into jessie and I am very hopeful that with feedback from people like yourself we will be able to fine tune them further to "just work" and jessie will make a big impact in this space.
I would definitely like that. My main goal would be that two people, where at least one of them is reachable on a public IP (which may not be the IP the host thinks it has), can make an encrypted video call by:
- both installing a package
- one person filling in the IP (and possibly the name) of the other person
and nothing more. They should not need to set up any server, and they certainly shouldn't need to edit DNS entries.
Please put specific comments about the problems into the bug tracker, that definitely helps us too.
I'll do that.
Thanks, Bas _______________________________________________ Free-RTC mailing list Free-RTC@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/free-rtc
On 21/09/13 21:38, Derek LaHousse wrote:
Bas, Have you checked out WebRTC at all? If you've got some of the latest Firefox or Chrome (maybe others) builds, you can try apprtc.appspot.com to meet your immediate goal.
That is supported in Debian too now
- the repro v1.9 beta in experimental acts as a WebRTC server
- SIPml5 and JsSIP are both JavaScript SIP stacks
- reTurn server for the TURN relay (all WebRTC browsers are ICE/TURN clients)
There is a 100% Debian WebRTC demo in our DebConf13 video, details here:
http://danielpocock.com/debconf13-breakthroughs-otp-webrtc-jitsi-video-bridg...
On Sat, Sep 21, 2013 at 10:38 PM, Derek LaHousse dlahouss@mtu.edu wrote:
Bas, Have you checked out WebRTC at all? If you've got some of the latest Firefox or Chrome (maybe others) builds, you can try apprtc.appspot.com to meet your immediate goal.
Except for the fact that there is no reliably end-to-end encryption there.
This is a problem with WebRTC altogether.
Emil
Derek
On Sat, 2013-09-21 at 20:54 +0200, Bas Wijnen wrote:
On Sat, Sep 21, 2013 at 10:25:44AM +0300, Emil Ivov wrote:
On 21 Sep 2013 02:22, "Bas Wijnen" wijnen@debian.org wrote:
Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on its own.
Well, I am afraid there's no changing this, so if you have an aversion to the language, you would simply need to use something else.
I didn't mean to suggest it should be changed. I was just getting frustrated that nothing worked, and a program which throws errors before it even started isn't helping. ;-)
I'm guessing that it's tested using a different java than I have (I'm just guessing it doesn't throw these errors when the developers run it). And that matters more than it should.
Also:
On Sat, Sep 21, 2013 at 09:44:30AM +0200, Daniel Pocock wrote:
Java can also be a good thing, as it means users on Linux, Mac and Windows all get the same code and it is easier for the developers to make sure that every release is interoperable across all platforms.
For communications software, interoperability is crucial and Java helps with that.
Which is entirely true. But it would be good if it would indeed work on all platforms. Random crashes are extremely frustrating, especially after trying so many things for so long, to achieve something which really should be simple.
I mean, what is the big problem? I have two computers I control. I can connect() from one to the other and have a working network connection. I have working audio and video hardware on both sides. How hard can it be to set up a link to make us see and hear each other?
Since upgrading to wheezy, I can't communicate reliably with Empathy. This is a big no-no for any communications product, once people lose faith in it, it is very hard to recover
In their favor, there aren't any working alternatives. Which isn't a good thing, of course.
Empathy is also hard coded to use Google's TURN server, it doesn't use the free software TURN servers packaged in Debian.
I consider that a very serious problem. Google is not exactly known for being good with privacy.
Empathy (SIP): SIP connections just don't work with masquerading, it seems. I've set up an asterisk server, which works as long as no masqueraded hosts are using it. The masqueraded hosts can call the server, get automated answers, but cannot be connected to other users (which doesn't make much sense to me, because asterisk would pass on all the traffic, so I don't see the difference between an automated answer generated by asterisk itself and a real person answering). Anyway, it didn't work well. Also, Asterisk seems to have very limited support for video, but I didn't really get around to trying it out.
I don't know if they support ICE with SIP
Asterisk does; it just ignores the reported return address and uses getpeername() instead. And it works, too; it's used when making a call to an auto-responder, and that works.
but it does seem to work. Then again, it crashes at random times. It seems I need to disable several settings to make sure it doesn't contact Google; I
Can you raise a bug against the package listing those things you had to disable?
Sure, but perhaps I should first ask if I am right. In my XMPP account settings, "Enable Google Contacts search" was on. I originally also disabled "Use Google's Jingle" and "Use JingleNodes", but now I see it again, I suppose that's just technology designed by Google, not actually contacting their servers. Or is it?
really don't like that. As for how it works: so far it doesn't really (or at least not with the masquerated hosts), but perhaps I have to try harder.
Did you put in the TURN server settings?
I did, but on localhost it doesn't care (it works, even if the password is wrong; of course on localhost I don't need the TURN server anyway, but I had expected an error nonetheless) and from the masqueraded host it says the password is wrong even though it isn't.
Make sure ejabberd works well for chat first
Make sure you have the SRV records, e.g. for pocock.com.au:
_xmpp-client._tcp IN SRV 5 0 5222 jabber.trendhosting.net. _xmpp-server._tcp IN SRV 5 0 5269 jabber.trendhosting.net.
Wait, what? Do I need to change my DNS records just to start a one-on-one video call with a computer that can already contact me? I can do it; I happen to have control over my DNS, but I really wouldn't expect to need it.
From Debian, you can use CaCert.org certificates and the clients will trust them.
Yes, I'm using those already. Unfortunately Ubuntu, Mac and Windows aren't accepting them. :-(
Multi-domain and IPv6 are slightly tricky, let me know if you need examples to make them work. I also have it linked to LDAP.
No, I don't need anything complex, thanks.
Skip Asterisk for now, it is overkill, and as you point out, no video.
It is very good for building a business phone system though
Yes, it looks like it, and it works well so far, except for NAT traversal. And its documentation is fantastic (except that its focus is not where I needed it).
The config files are fully commented with instructions, but that was only done after the wheezy freeze began.
The release team have so far not approved further uploads http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717420
but upstream and the package maintainer (myself) are quite happy to upload those changes when authorised to do so.
While I understand your reasoning, the usual way in Debian is not to change anything once it is released, except for security and really urgent things (virus definition updates; timezone changes). If you have a much better version of the package, it might be considered for the next point release, but not for stable itself. The downside of this method is that stable is always outdated (you're left with the state when it was frozen). The upside is that it means things are indeed really stable (new "fixes" often introduce new bugs as well).
Anyway, to get back on topic, all this doesn't matter for me, as I'm running the TURN server on unstable, so I have version 1.8.13-1.
I see you have uploaded 1.9.0~beta1-1 to experimental, at high urgency, with no information in the changelog why this was so urgent. Is there a big difference with 1.8.13? Why didn't you upload to unstable?
You can view the commented version of the file here:
https://github.com/resiprocate/resiprocate/blob/master/reTurn/reTurnServer.c...
The comments didn't make it to unstable, indeed. Thanks.
Note that trunk has slightly changed, the version in wheezy does not recognise the option "UserDatabaseFile = users.txt" and you need to keep using a single set of credentials for all users, by specifying something like this in reTurnServer.config:
LongTermAuthUsername = test LongTermAuthPassword = password
It seems to be the same in sid, looking at the config file?
I've been getting more recent versions of packages into jessie and I am very hopeful that with feedback from people like yourself we will be able to fine tune them further to "just work" and jessie will make a big impact in this space.
I would definitely like that. My main goal would be that two people, where at least one of them is reachable on a public IP (which may not be the IP the host thinks it has), can make an encrypted video call by:
- both installing a package
- one person filling in the IP (and possibly the name) of the other person
and nothing more. They should not need to set up any server, and they certainly shouldn't need to edit DNS entries.
Please put specific comments about the problems into the bug tracker, that definitely helps us too.
I'll do that.
Thanks, Bas _______________________________________________ Free-RTC mailing list Free-RTC@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/free-rtc
Free-RTC mailing list Free-RTC@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/free-rtc
On Sat, Sep 21, 2013 at 9:54 PM, Bas Wijnen wijnen@debian.org wrote:
On Sat, Sep 21, 2013 at 10:25:44AM +0300, Emil Ivov wrote:
On 21 Sep 2013 02:22, "Bas Wijnen" wijnen@debian.org wrote:
Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on its own.
Well, I am afraid there's no changing this, so if you have an aversion to the language, you would simply need to use something else.
I didn't mean to suggest it should be changed. I was just getting frustrated that nothing worked, and a program which throws errors before it even started isn't helping. ;-)
Exceptions printed by Jitsi on stderr are often mostly meant as debug output and you should really worry about them unless you know exactly what they mean.
On Sat, Sep 21, 2013 at 09:44:30AM +0200, Daniel Pocock wrote:
Java can also be a good thing, as it means users on Linux, Mac and Windows all get the same code and it is easier for the developers to make sure that every release is interoperable across all platforms.
For communications software, interoperability is crucial and Java helps with that.
Which is entirely true. But it would be good if it would indeed work on all platforms. Random crashes are extremely frustrating, especially after trying so many things for so long, to achieve something which really should be simple.
It does work for many people.
I mean, what is the big problem?
There is no one big problem. It's always about the specifics of the deployment.
I have two computers I control. I can connect() from one to the other and have a working network connection. I have working audio and video hardware on both sides. How hard can it be to set up a link to make us see and hear each other?
OK. If we had to really quote one big problem then I suppose it would be "diversity". Diversity in hardware, diversity of OSes and OS flavors, diversity of audio/video capture/render libs, diversity in devices and of course, diversity in network topologies.
Note that RTC applications are not generally written for the use case you describe: two machines with direct IP connectivity. This is simply one of the multitude of cases where RTC has to work.
I haven't seen you describing a specific problem (other than the language of the application and the fact that you find standard output to be unsettling) so it's hard for me to be any more specific on your situation.
Since upgrading to wheezy, I can't communicate reliably with Empathy. This is a big no-no for any communications product, once people lose faith in it, it is very hard to recover
In their favor, there aren't any working alternatives. Which isn't a good thing, of course.
It also isn't true.
Empathy (SIP): SIP connections just don't work with masquerading, it seems. I've set up an asterisk server, which works as long as no masqueraded hosts are using it. The masqueraded hosts can call the server, get automated answers, but cannot be connected to other users (which doesn't make much sense to me, because asterisk would pass on all the traffic, so I don't see the difference between an automated answer generated by asterisk itself and a real person answering). Anyway, it didn't work well. Also, Asterisk seems to have very limited support for video, but I didn't really get around to trying it out.
I don't know if they support ICE with SIP
Asterisk does;
No, I don't think that's true either. At least not in the way Daniel meant it. Asterisk is a Back-to-Back User Agent (B2BUA). It is meant to be an endpoint. As such it is not really meant to let endpoints talk directly to each other. Asterisk being in the middle of all communication is its default mode of operation.
As a result, using ICE to establish a direct connection between two asterisk connected clients is, as far as I know, not possible.
it just ignores the reported return address and uses getpeername() instead. And it works, too; it's used when making a call to an auto-responder, and that works.
but it does seem to work. Then again, it crashes at random times. It seems I need to disable several settings to make sure it doesn't contact Google; I
Can you raise a bug against the package listing those things you had to disable?
Sure, but perhaps I should first ask if I am right. In my XMPP account settings, "Enable Google Contacts search" was on.
This option is only used in case you actually have a Google account. It has no impact otherwise.
I originally also disabled "Use Google's Jingle"
This wouldn't hurt. Although, once again, Jitsi only uses this variant of the Jingle protocol in case it detects that you are using a Google account.
and "Use JingleNodes",
I am interested to know why you chose to do this.
Jingle Nodes is one of the technologies that Jitsi uses for NAT traversal. Disabling it only increases your chances of not being able to establish a connection.
but now I see it again, I suppose that's just technology designed by Google, not actually contacting their servers. Or is it?
really don't like that. As for how it works: so far it doesn't really (or at least not with the masquerated hosts), but perhaps I have to try harder.
Did you put in the TURN server settings?
I did, but on localhost it doesn't care
Who is it?
(it works, even if the password is wrong; of course on localhost I don't need the TURN server anyway, but I had expected an error nonetheless) and from the masqueraded host it says the password is wrong even though it isn't.
I seem to be missing a part of the thread here but, if you are using a TURN server then the client needs to be able to contact it *before* it makes a call.
Make sure ejabberd works well for chat first
Make sure you have the SRV records, e.g. for pocock.com.au:
_xmpp-client._tcp IN SRV 5 0 5222 jabber.trendhosting.net. _xmpp-server._tcp IN SRV 5 0 5269 jabber.trendhosting.net.
Wait, what? Do I need to change my DNS records just to start a one-on-one video call with a computer that can already contact me? I can do it; I happen to have control over my DNS, but I really wouldn't expect to need it.
Most of the time things would work even if you only had an A record, but yes, you do need to control your DNS.
Also, if all you need is for two IP-s to talk to each other, then you can simply take VLC and stream your microphone and webcam in each direction. That's a solution specific to your use case.
VoIP isn't.
Protocols like XMPP and SIP and their accompanying methodologies are meant to cover the Internet as a whole. To do that you need to have servers at least at the start of your conversation.
From Debian, you can use CaCert.org certificates and the clients will trust them.
Yes, I'm using those already. Unfortunately Ubuntu, Mac and Windows aren't accepting them. :-(
Multi-domain and IPv6 are slightly tricky, let me know if you need examples to make them work. I also have it linked to LDAP.
No, I don't need anything complex, thanks.
Skip Asterisk for now, it is overkill, and as you point out, no video.
It is very good for building a business phone system though
Yes, it looks like it, and it works well so far, except for NAT traversal.
It actually does handle NAT traversal quite reliably (although not in a very bandwidth efficient way due to its always-relay-everything model of operation that I mentioned above).
And its documentation is fantastic (except that its focus is not where I needed it).
The config files are fully commented with instructions, but that was only done after the wheezy freeze began.
The release team have so far not approved further uploads http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717420
but upstream and the package maintainer (myself) are quite happy to upload those changes when authorised to do so.
While I understand your reasoning, the usual way in Debian is not to change anything once it is released, except for security and really urgent things (virus definition updates; timezone changes). If you have a much better version of the package, it might be considered for the next point release, but not for stable itself. The downside of this method is that stable is always outdated (you're left with the state when it was frozen). The upside is that it means things are indeed really stable (new "fixes" often introduce new bugs as well).
Anyway, to get back on topic, all this doesn't matter for me, as I'm running the TURN server on unstable, so I have version 1.8.13-1.
I see you have uploaded 1.9.0~beta1-1 to experimental, at high urgency, with no information in the changelog why this was so urgent. Is there a big difference with 1.8.13? Why didn't you upload to unstable?
You can view the commented version of the file here:
https://github.com/resiprocate/resiprocate/blob/master/reTurn/reTurnServer.c...
The comments didn't make it to unstable, indeed. Thanks.
Note that trunk has slightly changed, the version in wheezy does not recognise the option "UserDatabaseFile = users.txt" and you need to keep using a single set of credentials for all users, by specifying something like this in reTurnServer.config:
LongTermAuthUsername = test LongTermAuthPassword = password
It seems to be the same in sid, looking at the config file?
I've been getting more recent versions of packages into jessie and I am very hopeful that with feedback from people like yourself we will be able to fine tune them further to "just work" and jessie will make a big impact in this space.
I would definitely like that. My main goal would be that two people, where at least one of them is reachable on a public IP (which may not be the IP the host thinks it has), can make an encrypted video call by:
- both installing a package
- one person filling in the IP (and possibly the name) of the other person
and nothing more. They should not need to set up any server, and they certainly shouldn't need to edit DNS entries.
You might want to download and try Openfire (although, note that it is also written in Java, which may be a problem for you). It comes with an easy to install JingleNodes plugin and, together with Jitsi, will give you what you are looking for.
You can also try using http://jit.si to get a feel for how all this works.
Cheers, Emil
Please put specific comments about the problems into the bug tracker, that definitely helps us too.
I'll do that.
Thanks, Bas _______________________________________________ Free-RTC mailing list Free-RTC@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/free-rtc
First of all, thanks for the replies. I know I sound frustrated (that's because I am :-P), but I'm very happy that you guys are trying to help me to get it working.
On Mon, Sep 23, 2013 at 02:50:47PM +0300, Emil Ivov wrote:
Exceptions printed by Jitsi on stderr are often mostly meant as debug output and you should really worry about them unless you know exactly what they mean.
That sounds sort of acceptable (although in that case they really should be switched on with a switch, not be printed by default), but this doesn't look harmless:
Auto-properties install: reference:file:sc-bundles/galagonotification.jar (org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar - java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar) org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar at org.apache.felix.framework.Felix.installBundle(Felix.java:2703) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) at org.apache.felix.main.AutoProcessor.processAutoProperties(AutoProcessor.java:296) at org.apache.felix.main.AutoProcessor.process(AutoProcessor.java:79) at org.apache.felix.main.Main.main(Main.java:292) at net.java.sip.communicator.launcher.SIPCommunicator.main(SIPCommunicator.java:153) Caused by: java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar at org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:852) at org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550) at org.apache.felix.framework.cache.BundleArchive.<init>(BundleArchive.java:153) at org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277) at org.apache.felix.framework.Felix.installBundle(Felix.java:2699) ... 5 more Auto-properties start: reference:file:sc-bundles/galagonotification.jar (org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar - java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar)
(And then there's some other stuff, which claims to be SEVERE, but probably is harmless.)
Also, the program is actually crashing when I do nothing special (for example, click on a tab in the account settings; this just happened once and is not reproducible, but it regularly crashes at random moments).
OK. If we had to really quote one big problem then I suppose it would be "diversity". Diversity in hardware, diversity of OSes and OS flavors, diversity of audio/video capture/render libs, diversity in devices and of course, diversity in network topologies.
That makes sense, but all parts seem to be working: I have video and audio hardware which works to show images on my local screen and to record audio from. I have a network which is capable of making connections between all clients and the server I want to use. Currently, I even find it acceptable if the client which is behind a NAT cannot get inbound connections.
As far as I can see, that means that all the parts are working. I cannot understand how there can be almost 10 things to choose from, and none of them manages to just combine the parts and make it work.
Note that RTC applications are not generally written for the use case you describe: two machines with direct IP connectivity. This is simply one of the multitude of cases where RTC has to work.
Sure. But it is the simplest possible case; all the other cases use all the parts I need, and possibly more. If there's a problem with the network or the audio/video hardware, nothing works. So if anything works, it should be my case.
To be more clear: this isn't what I actually want. This is what I'd be happy with by now. What I actually want is a video telephone, which I can use to call and be called, send text messages (and voice/video mail; why not), and all that with other people using a multitude of OSs. Oh, and conference calls would be nice, too. But nothing works, so I say I'm happy to start small and accept it if only Debian works, with just two computers that can directly reach each other. That really shouldn't be too much to ask, I would think.
I haven't seen you describing a specific problem (other than the language of the application and the fact that you find standard output to be unsettling) so it's hard for me to be any more specific on your situation.
Specific problems:
1. With empathy, if I try to set up an audio or video connection, it says "there was an error starting the call". It doesn't say what sort of error, or what I can do to fix it. When I run wireshark I see it doesn't even send anything out to the network. If I call myself from another machine (with another account), I get a call request, but when I try to answer it again says there was an error starting the call without any specifics.
2. With gajim, things seem to work pretty well, except that it doesn't allow me to select audio or video calls. It says I need a package for it, but when I install that it still doesn't allow me. It doesn't say why.
3. With jitsi, the buttons for audio and video call are greyed out.
4. With pidgin, making a call to jitsi results in a null pointer exception for jitsi. Being called by jitsi is now possible and works, but even though jitsi reports sound input (in its volume indicator), pidgin doesn't report receiving any sound (and I don't hear anything). The other way it works, so I do get sound from pidgin to jitsi when jitsi starts the call. However, that's audio. If I try to make a video call, I just get an audio call instead, with no explanation why.
5. Pidgin to pidgin seems to work slightly better; I am able to make a video call, and both cameras show with their LED that they are active, but I see only black rectangles, no actual video (even locally). Also, sound doesn't work at all.
If there are any other combinations you want to hear, let me know and I'll send you the results. The most depressing parts are IMO: - Pidgin sometimes hangs when trying to hang up the connection. I need to use kill -9 to close it. - Jitsi gives null pointer exceptions and crashes randomly.
Things not working isn't pleasant. But hanging and crashing is a step further; this really shouldn't happen.
Since upgrading to wheezy, I can't communicate reliably with Empathy. This is a big no-no for any communications product, once people lose faith in it, it is very hard to recover
In their favor, there aren't any working alternatives. Which isn't a good thing, of course.
It also isn't true.
Sure it isn't. But for me it is. I've been trying for _years_ (with long pauses) to get this working. I'm a programmer, I'm really good with computers, and I can't figure it out. That is very very bad.
And when I ask on an FSFE list for how to make things work, I get a recipe. That's good, but what does it include? Please install Oracle's (non-free) Java, because that's the only one that works. What? So I ask "how can I get this running on free software?" and the answer is "please install this non-free program"? I appreciate the attempt to help, I really do. But if I want to sacrifice my freedom and privacy for making this work, I'll install Skype. And I would have done so years ago.
I don't know if they support ICE with SIP
Asterisk does;
No, I don't think that's true either. At least not in the way Daniel meant it. Asterisk is a Back-to-Back User Agent (B2BUA). It is meant to be an endpoint. As such it is not really meant to let endpoints talk directly to each other. Asterisk being in the middle of all communication is its default mode of operation.
That is true. If you make a connection through asterisk, you really set up two SIP connections; one from each caller to asterisk. But on each of those connections, ICE is supported. Or perhaps I'm misunderstanding what ICE is; I understood it is more or less synonymous with "NAT-traversal" (with some protocol details on how to accomplish it).
Can you raise a bug against the package listing those things you had to disable?
Sure, but perhaps I should first ask if I am right. In my XMPP account settings, "Enable Google Contacts search" was on.
This option is only used in case you actually have a Google account. It has no impact otherwise.
Ok, that is good. It would be even better if that was clear for the user who has to choose what to do with this setting.
I originally also disabled "Use Google's Jingle"
This wouldn't hurt. Although, once again, Jitsi only uses this variant of the Jingle protocol in case it detects that you are using a Google account.
Ah, then I totally misunderstood what that option meant. First I thought it meant "Use Jingle (whatever that is), as offered by Google, sending whatever data it needs through Google's servers". I disabled it for that reason. Then after reading about Jingle, I thought it might mean "Use Jingle (which was designed by Google)" for connections. I would enable that.
But if I understand you correctly, it really means "Use Google's variation of Jingle, which only works if you're talking to Google and won't be used even if you switch this option on, unless you are actually connected to Google".
As you will have guessed, I think this option needs better help text (option name, but perhaps also some mouse-over explanation). I think a separate box with "options only applicable if you use a Google account" might be useful. It would be even better if that box would be greyed out if you're not using a Google account, but I don't know if that can be detected without connecting to the server.
and "Use JingleNodes",
I am interested to know why you chose to do this.
Because I had no idea what it means, and a few lines up it said that Jingle was this Google thing. So I thought it might help to make sure my data isn't sent to Google.
Jingle Nodes is one of the technologies that Jitsi uses for NAT traversal. Disabling it only increases your chances of not being able to establish a connection.
Is there any documentation on it? I'm especially interested in where my data ends up, and who can or cannot read it.
Did you put in the TURN server settings?
I did, but on localhost it doesn't care
Who is it?
I don't understand the question. One of my hosts has a non-masqueraded IP address, so I'm using that one to run the TURN server as well. I tried connecting to it with a client from localhost, but it seems it doesn't even try to use TURN.
I seem to be missing a part of the thread here but, if you are using a TURN server then the client needs to be able to contact it *before* it makes a call.
Yes, it says the password is wrong when trying to set the account to active. The account is set up to use the TURN server, with its password, and the XMPP server, with the user's own credentials. I'm very sure all of them were correct.
Most of the time things would work even if you only had an A record, but yes, you do need to control your DNS.
So what is the DNS entry required for? Which program looks at it, and what happens if it doesn't see the SRV record? Isn't that the same as a missing MX record, that it will just fall back to "same as A"?
Also, if all you need is for two IP-s to talk to each other, then you can simply take VLC and stream your microphone and webcam in each direction. That's a solution specific to your use case.
For this moment, that's a good idea; thank you for the suggestion.
VoIP isn't.
I know, and I eventually want "real" VoIP to work, so even though your suggestion might make my friends happy for now, I still want things to work the proper way.
Protocols like XMPP and SIP and their accompanying methodologies are meant to cover the Internet as a whole. To do that you need to have servers at least at the start of your conversation.
Oh yes, but I have a server which I control. It happens to be the same machine that hosts my side of the connection; that should make things easier, I would think. So that is not a problem. The problem is that I need to know what to install on them and how to configure it to actually make things work.
You might want to download and try Openfire (although, note that it is also written in Java, which may be a problem for you).
I understand how my previous message suggested that I dislike any program written in Java, but that is not the case. My problem with Jitsi is that it seems to not work at all with the Java version that Debian provides. According to the other reply on this list, I really need the non-free version from Oracle.
My problem with Java is that it is so easy for programmers to do that; they write in Java in an attempt to be platform-independent, which is really good, but then there are many different versions, which are not as compatible as they should be, and if the programmers don't watch out, their code only works on non-free stuff. It's nice to have a free software program, but I really want to run it on a free software system as well. With Java, that often fails. That's why I distrust anything written in Java; I have to see that it actually works on my machine before I like it. Jitsi doesn't.
It comes with an easy to install JingleNodes plugin and, together with Jitsi, will give you what you are looking for.
I'll look into it, thanks.
You can also try using http://jit.si to get a feel for how all this works.
Is that just a free XMPP server? I don't need that, I have prosody running on my own host now, and it works (for text anyway). Or is it more?
Thanks, Bas
On 29 Sep 2013 20:50, "Bas Wijnen" wijnen@debian.org wrote:
You can also try using http://jit.si to get a feel for how all this
works.
Is that just a free XMPP server?
Yes, with a Jingle Nodes relay.
I don't need that, I have prosody running on my own host now,
and according to your reports the setup dedn't seem to be working out that well.
I suggested you try jit.si to see if that gets you what you need. If it does, it would provide a working setup that you can then use as a basis for your own deployment.
Also, you might want to run with Jitsi's default config. As explained, disabling things because you believe them to be related to Google, could very well be breaking the whole thing for you.
Emil
--sent from my mobile
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 21/09/13 02:15, Bas Wijnen wrote:
Finally, some good news: after all the failures with XMPP and SIP, I looked at something entirely different: mumble...So certainly not the ideal solution, but it's currently the only way I can get working audio communication.
Same experience here.
I suppose this story sounds like a lot of misery. But there is hope: I really want it to work, and I want it to work for others as well. So if you can help me to make it work, I'll try to document things, and send patches to Debian packages (and upstream, if applicable) to make things better.
WebRTC could maybe fulfill your needs with one configuration or another. There are demo sites like http://browsermeeting.com/
But before I can do that, it has to work for me. So please advise me on how to get there.
I'm eagerly anticipating solutions that others here recommend.
Sam.
- -- Sam Tuke Campaign Manager Free Software Foundation Europe IM : samtuke@jabber.fsfe.org Latest UK Free Software news: uk.fsfe.org Is freedom important to you? Join the fellowship.fsfe.org