jami-daemon issueshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues2021-06-12T11:37:55Zhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/136[API ready]Swarm: support request for resending a file transfer2021-06-12T11:37:55ZSébastien Blin[API ready]Swarm: support request for resending a file transfer+ The daemon should store a link or the file in private datas to retrieve it
+ A peer in a conversation is able to re-ask for a file transfer
+ when downloaded sha3sum must be checked.+ The daemon should store a link or the file in private datas to retrieve it
+ A peer in a conversation is able to re-ask for a file transfer
+ when downloaded sha3sum must be checked.Swarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/831Add abstraction layer around conversation2024-01-19T13:25:49ZPierre NicolasAdd abstraction layer around conversationConversation are very complex partly because we keep history (git system).
Deamon should manage the data to give a simplified version to clients.
Then it will be cleaner and reduce bugs in the client conversation implementation.Conversation are very complex partly because we keep history (git system).
Deamon should manage the data to give a simplified version to clients.
Then it will be cleaner and reduce bugs in the client conversation implementation.Pierre NicolasPierre Nicolashttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/60Remove account's data securely2019-07-01T20:52:13ZVladimir StoiakinRemove account's data securelySeems like ring-daemon doesn't clear account's files before deletion from a filesystem. It can be dangerous, because allows to recover them from a hard drive. I think these files should be rewritten with zeros before deletion.Seems like ring-daemon doesn't clear account's files before deletion from a filesystem. It can be dangerous, because allows to recover them from a hard drive. I think these files should be rewritten with zeros before deletion.https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/56Enhance failure messages2022-11-26T22:44:58ZSébastien BlinEnhance failure messagesWhen a user send a message to a contact, the status of this message can change to "failed". The major problem here, is, (as discussed in https://git.ring.cx/savoirfairelinux/ring-project/issues/517) it's totally unclear for the user why ...When a user send a message to a contact, the status of this message can change to "failed". The major problem here, is, (as discussed in https://git.ring.cx/savoirfairelinux/ring-project/issues/517) it's totally unclear for the user why the message failed.
The failed status MUST be re-designed to explain what is wrong for the user.
Is it a network issue? A confirmation timeout? Because no devices is detected? etc.https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/27Add AV1 codec support to replace H.264 in the (near) future2022-11-14T21:52:31ZannaAdd AV1 codec support to replace H.264 in the (near) futureTo quote parts of the Mozilla AV1 website (https://research.mozilla.org/av1-media-codecs/):
> **What is AV1?**
>
> AV1 is a new video codec that promises to help companies and individuals transmit high-quality video over the internet e...To quote parts of the Mozilla AV1 website (https://research.mozilla.org/av1-media-codecs/):
> **What is AV1?**
>
> AV1 is a new video codec that promises to help companies and individuals transmit high-quality video over the internet efficiently, without paying royalty fees.
>
> AV1 is the first project to come out of the Alliance for Open Media (AOMedia), a consortium that promotes media codecs, formats, and technologies for the public web. Mozilla joined AOMedia in 2015 as a founding member. Mozilla sponsors open media codecs like AV1 because they have the potential to remove technical and financial barriers for people who want to create and share high-quality media experiences on the open web platform.
>
>**How is AV1 different? What will it replace or change?**
>
> The most popular video format in use today is AVC/H.264. That technology was introduced in 2003 and is owned by the Moving Picture Experts Group (MPEG).
>
> AV1 is different from AVC/H.264 because it:
>
>* Uses next-generation compression technology that is nearly twice as efficient
>* Can transmit high-quality video faster over the internet
>* Has no licensing fees; anyone can compress and decode video files without paying royalties
>* Can deliver higher-quality experiences to end users, even when bandwidth is constrained
>
> MPEG has created a successor to AVC/H.264, known as HEVC (High Efficiency Video Coding) or H.265, which has improved compression. However, uncertainty around HEVC’s licensing fees make it untenable for both web browsers and content creators.
>
> The goal of the AV1 project is to replace AVC/H.264 as the predominant video format for the web and to compete with the HEVC codec, so high-quality video can be shared freely and efficiently on the open web platform.
@pgorley What do you think?https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/603Extract conversation's code from jamiaccount2021-09-13T17:03:00ZSébastien BlinExtract conversation's code from jamiaccountJamiAccount is too big. Split this classJamiAccount is too big. Split this classSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/101Auto improve video quality2021-02-04T13:55:46ZSébastien BlinAuto improve video qualityThe algorithm is already in the daemon, but need to be improved and activated on mobile devices.The algorithm is already in the daemon, but need to be improved and activated on mobile devices.Pierre LespagnolPierre Lespagnolhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/99Audio only call, intermittent internet, makes sound not sent and/or received2021-09-26T08:02:41ZovariAudio only call, intermittent internet, makes sound not sent and/or received**Device A**<br>
Linux Mint 19.1 Cinnamon<br>
3G or 4G mobile internet<br>
Jami built on 2019-04-19 23:02:35 UTC<br>
*OR*<br>
Windows 10<br>
Wired internet
**Device B**<br>
Linux Mint 19.1 Cinnamon<br>
Wired internet<br>
Jami built on 2...**Device A**<br>
Linux Mint 19.1 Cinnamon<br>
3G or 4G mobile internet<br>
Jami built on 2019-04-19 23:02:35 UTC<br>
*OR*<br>
Windows 10<br>
Wired internet
**Device B**<br>
Linux Mint 19.1 Cinnamon<br>
Wired internet<br>
Jami built on 2019-04-19 23:02:35 UTC
1. Device A audio only call to Device B
2. During call Device B internet drops out then is restored (about 3-5 seconds with no internet)
3. Once Internet is restored on Device B, Device B can hear Device A; however, Device A can’t hear Device B.<br>
a) Does Device B resume sending audio once internet is reestablished?<br>
b) Can Device A receive audio once internet is reestablished on Device B?
Tested with intercom and non-intercom calls and sound no longer works in conversation when Internet resumes.
Should this issue remain in the GNOME client or should be moved to the daemon (or elsewhere)?
Workarounds:
* End Jami call and call again (Connecting, Searching, Calling, Accept)
* Use Skype
Can you reproduce?
Thank youhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/97replace restbed by restinio2019-09-10T18:40:32ZAdrien Béraudreplace restbed by restinio# Parts
+ OpenDHT: https://github.com/savoirfairelinux/opendht/pull/403 (merged)
+ Jami-daemon: https://review.jami.net/#/c/ring-daemon/+/11959/ (in review)
# Tasks
+ ~~[Find an alternative](https://github.com/binarytrails/ring-for-th...# Parts
+ OpenDHT: https://github.com/savoirfairelinux/opendht/pull/403 (merged)
+ Jami-daemon: https://review.jami.net/#/c/ring-daemon/+/11959/ (in review)
# Tasks
+ ~~[Find an alternative](https://github.com/binarytrails/ring-for-the-web/tree/master/Server/Cpp#libraries)~~
+ ~~Test async over a threadpool~~
+ ~~Basic methods & threading~~
+ ~~Compile OpenDHT in c++14~~
+ ~~[Add RESTinio to OpenDHT](https://github.com/binarytrails/opendht/tree/proxy_restinio)~~
+ ~~[Fix flush happening after async scope](https://github.com/Stiffstream/restinio/issues/22)~~
+ ~~Server: Get,Put,Info,Stats,Options,PutEncrypted,PutSigned,Subscribe,Filter,Listen,Push~~
+ ~~Server: Cancel disconnected listeners by [detecting a closed connection](https://github.com/Stiffstream/restinio/issues/28), Replace Thread~~
+ ~~Server: Replace Scheduler task by Asio Timer making the entire server on one io_context that is run on one thread.~~
+ ~~Make an async RESTinio client with callbacks & integrate http_parser~~
+ ~~Rewrite client side with an in-house std::async client library~~
+ ~~Adapt and test the behavior of proxy client to new async design~~
+ ~~Verify that keep alive is working~~
+ ~~Patch for [ISSUE-552](https://git.jami.net/savoirfairelinux/ring-client-android/issues/552): Configure the server to send keep alive every X min when X < 15 min)~~
+ ~~[Make the RESTful API backward compatible to non-standard HTTP methods](https://github.com/Stiffstream/restinio/issues/26)~~
+ ~~[Redirect server logging](https://github.com/savoirfairelinux/opendht/pull/403/commits/330ad8ed120d35ecaa76446fdd36796ac2fecdfb)~~
+ ~~IPV6 support: client & [server](https://github.com/Stiffstream/restinio/issues/30)~~
+ ~~Make dhtproxytests pass~~
+ ~~Add docker setup for restinio & http_parser fork for Travis-CI~~
+ ~~Benchmark the proxy server~~
+ ~~Replace Jami-daemon nameserver RESTbed by new OpenDHT Async Client~~
+ ~~Add OpenSSL to OpenDHT CMake & Autotools~~
+ ~~Implement OpenSSL in http lib (bridge GNUTLS Identity/Cert to OpenSSL in Asio)~~
+ ~~Implement HTTPS in DHTProxy (upstream is HTTP)~~
+ ~~Use HTTP or HTTPS depending on generated dht:crypto:Identity (-i)~~
+ ~~Write Docker files for OpenDHT with Travis CI~~
+ ~~Integrate to the daemon autotools build system along with contribs (fmt, http_parser, restinio, ssl)~~
+ ~~Cross-compile on Jenkins: Linux, Arm, OSx, Windows~~
# Benchmark
10'000 requests with concurrency of 20 requests
Compiled with:
```
cmake -DOPENDHT_TESTS=ON -DOPENDHT_PROXY_SERVER=ON -DOPENDHT_PROXY_CLIENT=ON -DCMAKE_INSTALL_PREFIX=/usr -DOPENDHT_PROXY_SERVER_IDENTITY=ON -DOPENDHT_DOCUMENTATION=Off -DOPENDHT_PUSH_NOTIFICATIONS=ON -DCMAKE_BUILD_TYPE=Release ../
```
**Summary**
- max_pipelined_requests: 16
- concurrent_accepts_count: 15
| REST framework | Requests per second |
| ------ | ------ |
| RESTbed (multi-threded) | 12'677 |
| RESTinio (one io_context thread) | 18'834 |
| RESTinio (io_context on thread pool) | 12'719 |
- max_pipelined_requests: 7
- concurrent_accepts_count: 6
| REST framework | Requests per second |
| ------ | ------ |
| RESTbed (multi-threded) | 12'677 |
| RESTinio (one io_context thread) | 17'472 |
| RESTinio (io_context on thread pool) | 11'800 |
**Restbed**: multi-threaded
```
Server Software:
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /
Document Length: 180 bytes
Concurrency Level: 20
Time taken for tests: 0.789 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 2870000 bytes
HTML transferred: 1800000 bytes
Requests per second: 12677.48 [#/sec] (mean)
Time per request: 1.578 [ms] (mean)
Time per request: 0.079 [ms] (mean, across all concurrent requests)
Transfer rate: 3553.16 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.2 1 3
Processing: 0 1 0.4 1 13
Waiting: 0 1 0.3 1 10
Total: 1 2 0.5 1 13
WARNING: The median and mean for the total time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 2
80% 2
90% 2
95% 2
98% 3
99% 4
100% 13 (longest request)
```
**Restinio**
- max_pipelined_requests: 16
- concurrent_accepts_count: 15
one thread for one io_context
```
Server Software: RESTinio
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /
Document Length: 172 bytes
Concurrency Level: 20
Time taken for tests: 0.531 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 3130000 bytes
HTML transferred: 1720000 bytes
Requests per second: 18833.85 [#/sec] (mean)
Time per request: 1.062 [ms] (mean)
Time per request: 0.053 [ms] (mean, across all concurrent requests)
Transfer rate: 5756.83 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 3
Processing: 0 1 0.3 1 7
Waiting: 0 1 0.3 1 6
Total: 1 1 0.4 1 8
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 2
98% 2
99% 2
100% 8 (longest request)
```
io_context on thread pool
```
Server Software: RESTinio
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /
Document Length: 172 bytes
Concurrency Level: 20
Time taken for tests: 0.786 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 3130000 bytes
HTML transferred: 1720000 bytes
Requests per second: 12718.92 [#/sec] (mean)
Time per request: 1.572 [ms] (mean)
Time per request: 0.079 [ms] (mean, across all concurrent requests)
Transfer rate: 3887.72 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.2 1 3
Processing: 0 1 0.7 1 14
Waiting: 0 1 0.6 1 14
Total: 1 2 0.8 1 15
WARNING: The median and mean for the total time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 2
90% 2
95% 3
98% 4
99% 5
100% 15 (longest request)
```
- max_pipelined_requests: 7
- concurrent_accepts_count: 6
one thread for one io_context
```
Server Software: RESTinio
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /
Document Length: 172 bytes
Concurrency Level: 20
Time taken for tests: 0.572 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 3130000 bytes
HTML transferred: 1720000 bytes
Requests per second: 17472.10 [#/sec] (mean)
Time per request: 1.145 [ms] (mean)
Time per request: 0.057 [ms] (mean, across all concurrent requests)
Transfer rate: 5340.59 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 7
Processing: 0 1 0.4 1 8
Waiting: 0 1 0.3 1 7
Total: 1 1 0.5 1 9
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 2
98% 2
99% 2
100% 9 (longest request)
```
io_context on thread pool
```
Server Software: RESTinio
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /
Document Length: 172 bytes
Concurrency Level: 20
Time taken for tests: 0.847 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 3130000 bytes
HTML transferred: 1720000 bytes
Requests per second: 11800.02 [#/sec] (mean)
Time per request: 1.695 [ms] (mean)
Time per request: 0.085 [ms] (mean, across all concurrent requests)
Transfer rate: 3606.84 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.4 1 6
Processing: 0 1 1.0 1 17
Waiting: 0 1 0.8 1 16
Total: 1 2 1.1 1 19
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 2
80% 2
90% 3
95% 4
98% 6
99% 7
100% 19 (longest request)
```Iteration 15Vsevolod IvanovVsevolod Ivanovhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/81Support video device rotation2019-03-27T14:50:53ZAdrien BéraudSupport video device rotation* Allow clients to report video capture device orientation
* Send orientation information to the peer during a call using SIP messages
* Transmit orientation information with the video stream
* Apply rotation to respect video orientation...* Allow clients to report video capture device orientation
* Send orientation information to the peer during a call using SIP messages
* Transmit orientation information with the video stream
* Apply rotation to respect video orientation at relevant places in the daemon or clientIteration 3Denys VidalDenys Vidalhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/949composingStatusChanged should be fully managed daemon side2024-03-05T13:50:09ZSébastien BlincomposingStatusChanged should be fully managed daemon sideActually, the daemon only forward the reception of the status change, but a lot of logic is implemented client side:
1. The preference to send/receive typing indicators MUST be moved in daemon (like read status)
2. The 12s timeout shoul...Actually, the daemon only forward the reception of the status change, but a lot of logic is implemented client side:
1. The preference to send/receive typing indicators MUST be moved in daemon (like read status)
2. The 12s timeout should be managed by the daemon
3. If a member of a conversation is removed while typing should be managed by the daemonSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/745Add some unit tests for plugins2022-09-09T12:56:18ZSébastien BlinAdd some unit tests for pluginsAline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/714Conversation: status erased, removed but conversation is still in contact.yaml2022-02-09T21:49:59ZMaxime CalletConversation: status erased, removed but conversation is still in contact.yamlWhile syncing conversations data from another device, some conversations are still listed in the conversation.yml file while their status is erased and removed.
The daemon should clear this conversation.
json example for a conversatio...While syncing conversations data from another device, some conversations are still listed in the conversation.yml file while their status is erased and removed.
The daemon should clear this conversation.
json example for a conversation:
```
"7e20d508e92e58928003c8a6b580e4374004ada4": {
"created": 1643907807,
"erased": 1643924392,
"id": "7e20d508e92e58928003c8a6b580e4374004ada4",
"lastDisplayed": "",
"members": [
{
"uri": "77d1acf5b271d7c73032ef010241b94fb3a32b07"
}
],
"removed": 1643924392
},
```Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/703Remove hacky underlyingIce()2022-08-24T13:58:31ZSébastien BlinRemove hacky underlyingIce()underlyingIce() is hacky. This method should not exists and the chain should be clean.
However this issue is quite complex, because the socket can be cut pretty everywhere in the chain and it should correctly close all the layer.
The m...underlyingIce() is hacky. This method should not exists and the chain should be clean.
However this issue is quite complex, because the socket can be cut pretty everywhere in the chain and it should correctly close all the layer.
The most hacky part is in TlsSocketEndpoint::ImplSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/692Support " echoCanceller: software"2022-08-15T21:08:19ZSébastien BlinSupport " echoCanceller: software"Webrtc should be enabled with echoCanceller: software in the dring.yml
For now "echoCanceller: system" is only used in pulselayer to do `bool ec = preference_.getEchoCanceller() == "system";`Webrtc should be enabled with echoCanceller: software in the dring.yml
For now "echoCanceller: system" is only used in pulselayer to do `bool ec = preference_.getEchoCanceller() == "system";`https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/689Update our code and test due to FFmpeg new release2022-08-04T11:59:59ZMehdi GhayourUpdate our code and test due to FFmpeg new releaseIt's not the priority at the moment, we'll handle it later and will consider a timeline aligned with the product.It's not the priority at the moment, we'll handle it later and will consider a timeline aligned with the product.Aline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/666Call re-invite - restart media only after successful ICE negotiation2022-01-05T18:21:56ZSébastien BlinCall re-invite - restart media only after successful ICE negotiationIf media transport uses ICE, and when a new media session is negotiated (incoming or outgoing re-invite) the current ICE session must be kept until the new ICE session is successfully negotiated, and the media is stopped and restarted us...If media transport uses ICE, and when a new media session is negotiated (incoming or outgoing re-invite) the current ICE session must be kept until the new ICE session is successfully negotiated, and the media is stopped and restarted using the new ICE session.
If the new session fails, the media transport must continue using the current ICE session.
# Scenario
+ In a call cut video
# Expected
+ the remote video should not be cut and retrieved a few secs after
# Current
During the negotiation remote video/audio is stopped and a glitch is seenMohamed ChibaniMohamed Chibanihttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/599Account preferences: add preferences to send or not displayed status2021-08-09T13:30:43ZSébastien BlinAccount preferences: add preferences to send or not displayed statusFor now clients are doing their own logic. This should be moved into the daemon. This allow us to group code from differnt clients.For now clients are doing their own logic. This should be moved into the daemon. This allow us to group code from differnt clients.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/592Swarm: move last read per participant daemon' side2021-07-28T17:15:46ZSébastien BlinSwarm: move last read per participant daemon' side+ getMembers() should return last read
+ react to messageDisplayed/setMessageDisplayed
+ Add test
+ Add method to compute how many messages between two interactions
+ Update LRC
+ Update doc+ getMembers() should return last read
+ react to messageDisplayed/setMessageDisplayed
+ Add test
+ Add method to compute how many messages between two interactions
+ Update LRC
+ Update docSwarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/579Uses long key instead sha1 for devices2021-07-30T15:06:28ZSébastien BlinUses long key instead sha1 for devicesSébastien BlinAdrien BéraudSébastien Blin