<link>http://people.skolelinux.org/pere/blog/</link>
<atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>Jami as a Zoom client, a trick for password protected rooms...</title>
+ <link>http://people.skolelinux.org/pere/blog/Jami_as_a_Zoom_client__a_trick_for_password_protected_rooms___.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Jami_as_a_Zoom_client__a_trick_for_password_protected_rooms___.html</guid>
+ <pubDate>Fri, 8 May 2020 13:30:00 +0200</pubDate>
+ <description><p>Half a year ago,
+<a href="http://people.skolelinux.org/pere/blog/Jami_Ring__finally_functioning_peer_to_peer_communication_client.html">I
+wrote</a> about <a href="https://jami.net/">the Jami communication
+client</a>, capable of peer-to-peer encrypted communication. It
+handle both messages, audio and video. It uses distributed hash
+tables instead of central infrastructure to connect its users to each
+other, which in my book is a plus. I mentioned briefly that it could
+also work as a SIP client, which came in handy when the higher
+educational sector in Norway started to promote Zoom as its video
+conferencing solution. I am reluctant to use the official Zoom client
+software, due to their <a href="https://zoom.us/terms">copyright
+license clauses</a> prohibiting users to reverse engineer (for example
+to check the security) and benchmark it, and thus prefer to connect to
+Zoom meetings with free software clients.</p>
+
+<p>Jami worked OK as a SIP client to Zoom as long as there was no
+password set on the room. The Jami daemon leak memory like crazy
+(approximately 1 GiB a minute) when I am connected to the video
+conference, so I had to restart the client every 7-10 minutes, which
+is not a great. I tried to get other SIP Linux clients to work
+without success, so I decided I would have to live with this wart
+until someone managed to fix the leak in the dring code base. But
+another problem showed up once the rooms were password protected. I
+could not get my dial tone signaling through from Jami to Zoom, and
+dial tone signaling is used to enter the password when connecting to
+Zoom. I tried a lot of different permutations with my Jami and
+Asterisk setup to try to figure out why the signaling did not get
+through, only to finally discover that the fundamental problem seem to
+be that Zoom is simply not able to receive dial tone signaling when
+connecting via SIP. There seem to be nothing wrong with the Jami and
+Asterisk end, it is simply broken in the Zoom end. I got help from a
+very skilled VoIP engineer figuring out this last part. And being a
+very skilled engineer, he was also able to locate a solution for me.
+Or to be exact, a workaround that solve my initial problem of
+connecting to password protected Zoom rooms using Jami.</p>
+
+<p>So, how do you do this, I am sure you are wondering by now. The
+trick is already
+<a href="https://support.zoom.us/hc/en-us/articles/202405539-H-323-SIP-Room-Connector-Dial-Strings#sip">documented
+from Zoom</a>, and it is to modify the SIP address to include the room
+password. What is most surprising about this is that the
+automatically generated email from Zoom with instructions on how to
+connect via SIP do not mention this. The SIP address to use normally
+consist of the room ID (a number), an @ character and the IP address
+of the Zoom SIP gateway. But Zoom understand a lot more than just the
+room ID in front of the at sign. The format is "<tt>[Meeting
+ID].[Password].[Layout].[Host Key]</tt>", and you can hear see how you
+can both enter password, control the layout (full screen, active
+presence and gallery) and specify the host key to start the meeting.
+The full SIP address entered into Jami to provide the password will
+then look like this (all using made up numbers):</p>
+
+<p><blockquote>
+<tt>sip:657837644.522827@192.168.169.170</tt>
+</blockquote></p>
+
+<p>Now if only jami would reduce its memory usage, I could even
+recommend this setup to others. :)</p>
+
+<p>As usual, if you use Bitcoin and want to show your support of my
+activities, please send Bitcoin donations to my address
+<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
+</description>
+ </item>
+
<item>
<title>GnuCOBOL, a free platform to learn and use COBOL - nice free software</title>
<link>http://people.skolelinux.org/pere/blog/GnuCOBOL__a_free_platform_to_learn_and_use_COBOL___nice_free_software.html</link>
</description>
</item>
- <item>
- <title>When terms and policy turn users away</title>
- <link>http://people.skolelinux.org/pere/blog/When_terms_and_policy_turn_users_away.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/When_terms_and_policy_turn_users_away.html</guid>
- <pubDate>Sat, 7 Dec 2019 21:15:00 +0100</pubDate>
- <description><p>When asked to accept terms of use and privacy policies that state
-it will to remove rights I otherwise had or accept unreasonable terms
-undermining my privacy, I choose away the service. I simply do not
-have the conscience to accept terms I have no indention of upholding.
-But how are the system and service providers to know how many people
-they scared away? Normally I just quietly walk away. But today, I
-tried a new approach. I sent the following email (removing the
-specifics, as I am not out to take the specific service in question)
-to the service provider I decided to not use, to at least give them
-one data point on how many users are unhappy with their terms:</p>
-
-<blockquote>
-From: Petter Reinholdtsen
-<br>Subject: When terms of use turn users away
-<br>To: [contact@some.site]
-<br>Date: Sat, 07 Dec 2019 16:30:56 +0100
-
-<p>Dear [Site Owner],</p>
-
-<p>I was eager to test the system, as it seemed like a fun and
-interesting application of [some] technology, but after reading the
-terms of use and privacy policy on &lt;URL:
-https://www.[some.site]/terms-of-use &gt; and &lt;URL:
-https://www.[some.site]/privacy-policy &gt; I want you to know that I
-decided to turn away. There were several provisions in the terms and
-policy turning me off, but the final term that convinced me was being
-asked to sign away my right to reverse engineer.</p>
-
-<p>--
-<br>Happy hacking
-<br>Petter Reinholdtsen</p>
-</blockquote>
-
-<p>I do not expect much to come out of it, but sharing it here in case
-others want to give something similar a try too. If companies
-discover their terms scare away enough people, perhaps they will be
-improved...</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff