Re: Public TURN servers. Why Jami?
Сергей Петров writes: > I have found lists of public STUN servers ( > https://gist.github.com/mondain/b0ec1cf5f60ae726202e and > https://gist.github.com/sagivo/3a4b2f2c7ac6e1b5267c2f1f59ac6c6b), but only > a few TURN's. It seems a bit strange. With STUN, you basically send a small number of packets at call setup to find out your public address. With TURN, the server forwards media packets, which is a lot more traffic. So it makes sense that people would be willing to offer STUN but not TURN. What I find surprising is that clients that can be configured for STUN and TURN do not seem to record if they work or not and present that to the user. (I haven't checked jami lately, but linphone at least makes it hard to figure out, perhaps needing to turn on debug logging.)
Re: Why Jami?
Dmitry Alexandrov writes: >> Server-based SIP is still fully supported. > > Unfortunately, itʼs not easy to find not even a good manual, but just > a brief overview of it: what exactly ‘fully supported’ means. > > Itʼs pretty reasonable for an end user to expect a full-blown SIP > client to contain certain features, which are technically not parts of > the SIP proper: such as end-to-end encryption of media stream, which > means support of ZRTP. Good points. I find that the SIP app landscape is somewhat troubled, and if jami the app really did support SIP that would be great. > But Jami does not support ZRTP, does it? ZRTP is of course very important. I would expect the encryption in the jami protocol to be more or less ZRTP with authentication based on jami addresses. Another thing is that it at least earlier did not seem possible to start up jami and use it without creating a jami address, and just do SIP. It seems obvious that this should be possible if it "supports SIP". I realize there is no great cost to creating an account, but someone might not want it to be registered (either DHT or proxy) and there is cognitive load in doing unwanted things.
jami iOS version and GPL
I looked at the download page (because of a previous message) and was surprised to see an iOS link, because I had the impression Jami was GPL rather than some permissive license. I looked at the repo and sure enough GPL3. As I understand Apple's app store terms, users who receive software have to agree to not distribute it all, let alone modify it, and this is incompatible with the GPL. I looked at CONTRIBUTING, and there's no CLA (yay!) so this seems to be the usual inbound=outbound (yay again!). So there are likely many copyright holders, rather than SFL being the sole holder, and all of them would need to consent to dual licensing. So I wonder if someone could explain how this works. Do app store users who receive an ios binary have the legal right to resdistribute it? Are they prevented from doing so by technical means? Is there some proprietary dual licensing scheme happening? Thanks, Greg signature.asc Description: PGP signature
download, versions (new user experience report)
I have tried Ring/Jami long ago nad am having another iteration of trying it. I went to jami.net (on a mac, and yes I know bad FSF citiizen :-) , and saw a donwload button and got "jami-nightly.dmg".That seems to be 2.04 ( 2021060113) So I can't tell if I got a release, or an unstable/nightly build. It seems I should have gotten a release, and the file should have been labeled jami-2.04.dmg. signature.asc Description: PGP signature
Re: Jami Questions - Queen's Universtiy
Nathan Zhao <17...@queensu.ca> writes: > My name is Nathan and I am in a course that is currently studying your > program. I was wondering how you guys use concurrency to speed up your > program? Which sections benefit the most from currency multi > threading? If you are a student, the intent is probably for you to read the code and figure this out yourself. signature.asc Description: PGP signature
