jami-daemon issueshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues2021-07-28T17:15:46Zhttps://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/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/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/579Uses long key instead sha1 for devices2021-07-30T15:06:28ZSébastien BlinUses long key instead sha1 for devicesSébastien BlinAdrien BéraudSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/114Remove MTU phase from tls_session (unused code)2021-08-03T13:32:54ZSébastien BlinRemove MTU phase from tls_session (unused code)This code is deactivated since a long time. Could be removed.
However, the MTU can be retrieven via pjsip (or should be)This code is deactivated since a long time. Could be removed.
However, the MTU can be retrieven via pjsip (or should be)Sébastien BlinSébastien Blinhttps://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/228File transfer: multiple improvements2020-06-29T15:07:19ZSébastien BlinFile transfer: multiple improvements+ [ ] Remove eventloop from PeerConnection
+ [ ] Fix potential resources deadlocks
+ [ ] Fix mutex usage
+ [ ] Channeled File Transfer to avoid ICE negotiation when possible.+ [ ] Remove eventloop from PeerConnection
+ [ ] Fix potential resources deadlocks
+ [ ] Fix mutex usage
+ [ ] Channeled File Transfer to avoid ICE negotiation when possible.Iteration 18Sébastien BlinSébastien Blinhttps://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/28"Blob" class split for increased clarity2022-11-14T21:52:31ZJami Bot"Blob" class split for increased clarityIssue generated from Tuleap's migration script.
**Originally submitted by: Macony Gautradis (teamlog8430)**
The Account class is showing the first signs of becoming a monolithic "Blob" antipattern. Our solution is to split the "Blob" cl...Issue generated from Tuleap's migration script.
**Originally submitted by: Macony Gautradis (teamlog8430)**
The Account class is showing the first signs of becoming a monolithic "Blob" antipattern. Our solution is to split the "Blob" class into multiple separate subclasses, by issues, used to ease maintenance and upgrades of the code by separating relevant and linked methods into more descriptive subclasses. This initial work splits some functions of Account into the CodecContainer subclass.
The other modifications were made throughout the project to reflect the changes to Account. The makefile was updated to automake using our new class.
Here is a more thorough list of changes:
CHANGED FILES:
(all in daemon/)
MAJOR CHANGES:
src/account.h
src/account.cpp
description: Removed ALL codec-related functions, added CodecContainer class to
replace said functions,
added std::shared\_ptr<CodecContainer> codecContainer\_; and
std::shared\_ptr<CodecContainer> getCodecContainer(); definitions
Removed \#include "media\_codec.h" because it makes no sense to have
it here anymore
src/codeccontainer.h
src/codeccontainer.cpp
description: Created these two files and moved all codec-related code in
account.h/account.cpp to these respective files, creating
the CodecContainer class
in the process
Migrated code was cleaned up a bit - references to getSystemCodecContainer()
changed to already existing member systemCodecContainer\_
MINOR CHANGES:
src/Makefile.am
description: Updated automake makefile to compile the new codeccontainer.\* files
src/client/configurationmanager.cpp
description: Updated references to codec-calling functions
src/media/video/video\_sender.cpp
description: Added \#include "media\_codec.h" that was implicitly included in account.h
but removed due to codec separation
src/sip/sipaccount.cpp
description: Updated references to codec-calling functions
src/sip/sipcall.cpp
description: Updated references to codec-calling functions
src/sip/sipvoiplink.cpp
description: Updated references to codec-calling functions
src/ringdht/ringaccount.cpp
description: Updated references to codec-calling functions
\* Was only tested on Mint
[RingChanges.zip](/uploads/035972cc8864c9cbc735f2829d219685/RingChanges.zip)https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/37Ability to stream audio files2022-11-14T21:52:32ZPhilippe GorleyAbility to stream audio filesWhen streaming files during a call, only the video is streamed, not the audio.When streaming files during a call, only the video is streamed, not the audio.Philippe GorleyPhilippe Gorleyhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/38Ability to change audio source mid call2022-11-14T21:52:32ZPhilippe GorleyAbility to change audio source mid callIt would be nice to be able to switch audio managers and devices mid call, like with video (screengrab, different cameras, etc).
SIP renegotiation should be avoided.It would be nice to be able to switch audio managers and devices mid call, like with video (screengrab, different cameras, etc).
SIP renegotiation should be avoided.Philippe GorleyPhilippe Gorleyhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/42Add ringing timeout2022-11-14T21:52:32ZHugo LefeuvreAdd ringing timeoutCurrently there is no timeout for emitted calls. If a peer is connected but doesn't answer a call, then this call will ring 'forever', at least until the user manually aborts it or peer becomes unreachable.
We should implement such a ti...Currently there is no timeout for emitted calls. If a peer is connected but doesn't answer a call, then this call will ring 'forever', at least until the user manually aborts it or peer becomes unreachable.
We should implement such a timeout.Next major releaseHugo LefeuvreHugo Lefeuvrehttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/43[i18n] Enable “default” to be translatable2022-11-14T21:52:32Zovari[i18n] Enable “default” to be translatableSettings → Media → “Default” strings indicated in green in the image below<br>
![image](/uploads/e100b4f938323a9aa8194ec946fa72b3/image.png)
Please enable the “default” strings to be translatable.
For Hungarian (magyar) the string coul...Settings → Media → “Default” strings indicated in green in the image below<br>
![image](/uploads/e100b4f938323a9aa8194ec946fa72b3/image.png)
Please enable the “default” strings to be translatable.
For Hungarian (magyar) the string could be translated to "alapbeállítás"
Thank youhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/46Correctly handle emission of BUSY_HERE 4862022-11-14T21:52:32ZHugo LefeuvreCorrectly handle emission of BUSY_HERE 486Since 9a12c78a, the daemon has a timeout system which emits a 486 (BUSY_HERE) answer after a preferences-defined timeout if user didn't take the call.
However this 486 signal is currently handled by the daemon like a 600 (BUSY_EVERYWHER...Since 9a12c78a, the daemon has a timeout system which emits a 486 (BUSY_HERE) answer after a preferences-defined timeout if user didn't take the call.
However this 486 signal is currently handled by the daemon like a 600 (BUSY_EVERYWHERE) signal, that is if one device sends 486 then the call will end for all devices. A correct behavior would be to wait for all devices to hang up (486 but not necessarily) before exiting the call.
## Example
Bob calls Alice. Alice has three devices:
* (D1) her smartphone. This device has a timeout of 0 because she is in a meeting and doesn't want to receive calls.
* (D2) her laptop. The laptop has a timeout of 20s.
* (D3) her desktop. The desktop has a timeout of 1mn.
**Currently:**
The call ends directly because D1 sends 486 (BUSY_HERE) right away.
**Should be:**
The call does not ring on D1, rings 20s on D2 and 1mn on D3. After 1mn Bob's call enters PEER_BUSY status.Hugo LefeuvreHugo Lefeuvrehttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/55No signal for hardware decoding activated/deactivated2019-01-22T16:30:40ZSébastien BlinNo signal for hardware decoding activated/deactivatedAll is in the title. We can't know when the "hardware decoding" is changed when two clients are running.All is in the title. We can't know when the "hardware decoding" is changed when two clients are running.Philippe GorleyPhilippe Gorleyhttps://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/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/72Which layer owns the auto-answer flag???? Daemon or lrc?2020-12-24T21:25:55ZSébastien BlinWhich layer owns the auto-answer flag???? Daemon or lrc?For now, the auto-answer flag is in the account's config. The `--auto-answer` flag is also available for `dring`. Nice.
So, we can conclude that the code for auto answering a call is in the daemon. But it's not the case for the clients....For now, the auto-answer flag is in the account's config. The `--auto-answer` flag is also available for `dring`. Nice.
So, we can conclude that the code for auto answering a call is in the daemon. But it's not the case for the clients. We should re-implement this flag into the client part.
I think it's bad. We should implement this feature only once, and the flag should be managed by the layer which implems this behavior.
Also, in the future, I think we want to improve this flag by contact and by account.https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/74Use DTLS1.3 instead DTLS1.22019-05-27T14:00:32ZSébastien BlinUse DTLS1.3 instead DTLS1.2Will be possible after the bump to gnutls 3.6.5 (https://git.ring.cx/savoirfairelinux/ring-daemon/issues/73)Will be possible after the bump to gnutls 3.6.5 (https://git.ring.cx/savoirfairelinux/ring-daemon/issues/73)https://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/82Messages: don't fail imediately if peer is not online2019-03-27T14:51:56ZAdrien BéraudMessages: don't fail imediately if peer is not onlineIf peer is not online when trying to send a message, retry when the peer goes online, up to a few weeks.
Allow users to cancel a pending sending message.If peer is not online when trying to send a message, retry when the peer goes online, up to a few weeks.
Allow users to cancel a pending sending message.Iteration 3Adrien BéraudAdrien Béraudhttps://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/87UPnP enable ipv6 and bump contrib2021-05-26T13:41:57ZSébastien BlinUPnP enable ipv6 and bump contribAll is in the title, currently upnp doesn't work with IPv6. Try to bump the contrib and re-enable ipv6 support.All is in the title, currently upnp doesn't work with IPv6. Try to bump the contrib and re-enable ipv6 support.https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/85DataTransferInterface remove transfer id from map_ when the transfer is finished2020-10-01T15:35:23ZSébastien BlinDataTransferInterface remove transfer id from map_ when the transfer is finishedIn `data_transfer.cpp`, `map_` is never cleaned. This should not be the case.In `data_transfer.cpp`, `map_` is never cleaned. This should not be the case.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/88ring-daemon file transfer not at full theoretical thoughput2020-06-19T17:47:39ZSébastien Blinring-daemon file transfer not at full theoretical thoughputNeed to understand why, should not be limitedNeed to understand why, should not be limitedSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/161Remove currentCall and holding management in daemon2019-10-07T18:40:08ZSébastien BlinRemove currentCall and holding management in daemonIteration 17 (Video conferences stabilization)Andreas TraczykAndreas Traczykhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/159Clean logs from jams + split account2019-10-07T17:43:14ZSébastien BlinClean logs from jams + split accountIteration 16 (POC prep)https://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/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/86ICE over TCP - support UPnP2019-05-08T20:50:44ZSébastien BlinICE over TCP - support UPnPIteration 6Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/115Socket_pair: Buffer should be resizable2019-05-24T14:44:18ZSébastien BlinSocket_pair: Buffer should be resizableFor now, SRTPProtoContext have the attribute `encryptbuf` limited to `RTP_MAX_PACKET_LENGTH = 2048;`. This is good for UDP, but not TCP compliant.For now, SRTPProtoContext have the attribute `encryptbuf` limited to `RTP_MAX_PACKET_LENGTH = 2048;`. This is good for UDP, but not TCP compliant.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/116ICE: Lot of unneeded buffers2021-08-19T18:15:16ZSébastien BlinICE: Lot of unneeded buffersThe ICE negotiation uses a lot of different buffers. A lot of copy can be replaced by `std::move`
Also lot of unnecessary `comp_id-1`.The ICE negotiation uses a lot of different buffers. A lot of copy can be replaced by `std::move`
Also lot of unnecessary `comp_id-1`.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/119Resend failed files when peer is online2020-12-24T21:22:33ZSébastien BlinResend failed files when peer is onlineLike messagesLike messagesSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/142file transfer: partial file remains on pc after cancel2020-10-08T17:51:44ZPhilippe Gorleyfile transfer: partial file remains on pc after cancelCancelling a file transfer (on the receiving side) should remove the partial file.Cancelling a file transfer (on the receiving side) should remove the partial file.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/145API: add playMedia/pause/stop2021-02-04T13:55:59ZSébastien BlinAPI: add playMedia/pause/stopTo play ringtones without breaking calls from the client and recorded messages.To play ringtones without breaking calls from the client and recorded messages.Pierre LespagnolPierre Lespagnolhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/242Video encoding - Dynamically change the resolution of the encoded frames2022-01-18T22:20:21ZMohamed ChibaniVideo encoding - Dynamically change the resolution of the encoded framesBacklogMohamed ChibaniMohamed Chibanihttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/176Contact not added indirectly2020-03-15T12:12:15ZovariContact not added indirectly1. Accept contact request using Android smartphone
2. Turn on GNU/Linux computer #1 and open Jami Gnome → contact is added
3. Turn off Wi-Fi and turn off Mobile data on Android smartphone
4. Turn on GNU/Linux computer #2 and open Jami Gn...1. Accept contact request using Android smartphone
2. Turn on GNU/Linux computer #1 and open Jami Gnome → contact is added
3. Turn off Wi-Fi and turn off Mobile data on Android smartphone
4. Turn on GNU/Linux computer #2 and open Jami Gnome → `contact is not added (this is a bug)`
5. Turn on Mobile data on Android smartphone → contact is now added to GNU/Linux computer #2 with Jami Gnome
The contact was online when all these steps were done; however, step 4 should also work if the added contact was offline. What do you think?
@sblin is this a bug with the Gnome client or otherwise?
Are you able to reproduce and fix?
Thank you
Android smartphone<br>
Nokia 1 Plus<br>
Android 9 Pie<br>
Jami Live Free or Die - 20191031-01
GNU/Linux computer #1<br>
Linux Mint 19.2 Cinnamon 64-bit<br>
Jami built on 2019-11-09 02:50:12 UTC
GNU/Linux computer #2<br>
Linux Mint 19.2 Cinnamon 64-bit<br>
Jami built on 2019-11-09 02:50:12 UTChttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/187TLSSession + ICETransport make the API async2020-11-10T21:44:34ZSébastien BlinTLSSession + ICETransport make the API asyncReplace all waitxxx in the API by something asyncReplace all waitxxx in the API by something asynchttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/190Redo TLSSession (again, in space)2020-03-11T14:18:27ZSébastien BlinRedo TLSSession (again, in space)Since https://review.jami.net/c/ring-daemon/+/8392 TlsSession is a bit better. However, the class takes a `SocketType& transport_;` and this makes the class hard to use!
There is no reason to not have a unique_ptr for the transport_. On...Since https://review.jami.net/c/ring-daemon/+/8392 TlsSession is a bit better. However, the class takes a `SocketType& transport_;` and this makes the class hard to use!
There is no reason to not have a unique_ptr for the transport_. Only that session should be able to use the transport.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/478Sip call refusal & hangup status code incorrect2021-03-29T12:47:09ZMing Rui ZhangSip call refusal & hangup status code incorrectMing Rui ZhangMing Rui Zhanghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/237Use acceleration for recording2023-12-27T18:07:03ZPierre LespagnolUse acceleration for recordinghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/248Stuck in Connecting/Searching: timeout duration2020-07-02T20:06:29ZSébastien BlinStuck in Connecting/Searching: timeout durationRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
Actually ICE_NEGOTIATION_TIMEOUT is 60 seconds. This is pretty long and the user will close the window before thisRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
Actually ICE_NEGOTIATION_TIMEOUT is 60 seconds. This is pretty long and the user will close the window before thisIteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/255Do not test libcuda on non compatible hardware2020-12-18T19:58:07ZJürgen LütersDo not test libcuda on non compatible hardwareHi all.
During a video connection between jami android and jami-gnome the file /var/log/user.log gets flooded with messages:
Jul 2 13:08:23 nuc dring: -- Init encoding for cuda with device 1.
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: ...Hi all.
During a video connection between jami android and jami-gnome the file /var/log/user.log gets flooded with messages:
Jul 2 13:08:23 nuc dring: -- Init encoding for cuda with device 1.
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Cannot load libcuda.so.1
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Could not dynamically load CUDA
Jul 2 13:08:23 nuc dring: -- Init encoding for cuda with device 2.
Jul 2 13:08:23 nuc dring: Failed to set preset 'veryfast'
Jul 2 13:08:23 nuc dring: Failed to set tune 'zerolatency'
Jul 2 13:08:23 nuc dring: -- Starting encoding init for vaapi with default device.
Jul 2 13:08:23 nuc dring: Using hardware encoding for h264 with vaapi.
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: Output #0, rtp, to 'rtp://80.134.238.234:63854':
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: Metadata:
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: encoder : Lavf58.29.100
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: Stream #0:0: Video: h264 (Constrained Baseline), vaapi_vld, 320x240, q=
Jul 2 13:08:24 nuc cx.ring.Ring[4352]: [sdp @ 0x7fdc6c000900] max delay reached. need to consume packet
Jul 2 13:08:24 nuc cx.ring.Ring[4352]: [sdp @ 0x7fdc6c000900] RTP: missed 1 packets
Jul 2 13:08:25 nuc dring: Restarting video sender
Jul 2 13:08:25 nuc dring: -- Starting encoding init for cuda with default device.
Jul 2 13:08:25 nuc dring: -- Init encoding for cuda with device 0.
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74040400] Cannot load libcuda.so.1
cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74040400] Could not dynamically load CUDA
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Cannot load libcuda.so.1
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Could not dynamically load CUDA
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc744d0a00] Cannot load libcuda.so.1
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc744d0a00] Could not dynamically load CUDA
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74003a40] Cannot load libcuda.so.1
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74003a40] Could not dynamically load CUDA
Andoid jami 20200623-01
Jami Gnome 2020-06-30 20:45:35 UTC (debian/Gnu Linux Testing )
If i am not totally mistaken cuda is for nvidia devices only. But there is none nvidia graphic card.
Shouldn't it be suffice to scan the hardware once ?
My Hardware according to lspci
00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics 655 (rev 01)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30)
00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30)
00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)
00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller #1 (rev 30)
00:17.0 SATA controller: Intel Corporation Cannon Point-LP SATA Controller [AHCI Mode] (rev 30)
00:1c.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #1 (rev f0)
00:1c.4 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #5 (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #9 (rev f0)
00:1d.6 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #15 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Cannon Point-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30)
00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (6) I219-V (rev 30)
02:00.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
03:00.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
03:01.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
03:02.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
04:00.0 System peripheral: Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] (rev 02)
05:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:03.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
07:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10)
09:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10)
0b:00.0 USB controller: Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] (rev 02)
6c:00.0 USB controller: Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] (rev 02)
6e:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/246Stuck in Searching/Connecting: Improve logs2020-07-07T17:49:52ZSébastien BlinStuck in Searching/Connecting: Improve logsEverything is in the title. The negotiation of a call can be quite complex to understand and logs should be understandable, moreover if the call fails.
Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227Everything is in the title. The negotiation of a call can be quite complex to understand and logs should be understandable, moreover if the call fails.
Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227Iteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/260A client should be able to answer a call multiple times without weird results2020-12-18T19:26:47ZSébastien BlinA client should be able to answer a call multiple times without weird results# Reproduce steps
+ Launch 2 clients with auto answer (client-gnome + python) for example or (daemon with --auto-answer + client gnome)
+ Receive a call
+ Both clients are answering => Video not ok sometimes, or no hangup available, etc...# Reproduce steps
+ Launch 2 clients with auto answer (client-gnome + python) for example or (daemon with --auto-answer + client gnome)
+ Receive a call
+ Both clients are answering => Video not ok sometimes, or no hangup available, etc
# Expected result
+ The daemon should ignore answer request if already answered, video should work and hangup toohttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/288Connectivity: be more resilient if a TURN server is not available2021-12-29T21:18:42ZSébastien BlinConnectivity: be more resilient if a TURN server is not available# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Curre...# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Current result
+ The client try to connect to the TURN server for each ICE and result with a timeout of several seconds (~20 on linux) for each ICE negotiations making the call just unusable
# Why?
When making a call, the first step is to gather all candidates and send this message through the DHT (or direct p2p connection if available). But to gather the TURN candidate, pjsip needs to connect to it and ask for a new session. For TCP connections, the connect() will take a lot of time to timeout (depending on /proc/sys/net/ipv4/tcp_syn_retries), for UDP I didn't dig enough to fully understand what pjsip is waiting, but I think it's something related to that candidate allocation.
# Solutions
Several solutions can be created:
1. (pjsip specific) A new timer for TURN candidate creation can be created inside pjsip, to be able to ignore TURN candidates if it's taking too long. Because Jami is a real time communication app, if the allocation is taking more than 3 seconds, this means that we are taking too much time and it's not acceptable.
2. (system + pjsip specific) Manually set the connection timeout on the sockets. For TCP, we need to do a setsockopt on TCP_SYNCNT. 2 SYN retries is acceptable imho (that's about 3 seconds. First packet + 1 retry). A solution need to be created for platforms not supporting this op. For UDP as I didn't dig enough, I don't really know what's really blocking so this will need further investigation
3. (best solution imho) Support the RFC for Trickle ICE. I don't really like 1 or 2 because sometimes TURN can work and we will ignore that fact if it's taking too long. Trickle ICE will allow us to send candidates as soon as it's gathered. This means we will be able to send separately host candidates, UPnP, relays like TURN. This is clearly the solution that will take the more time to implement, but the best solution imho.
Note for 3: the drawback I see is that, because we will send candidates separately, this will generate multiple values on the DHT instead of one. Which is a bit bad.Backloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/313Support for https://tools.ietf.org/html/rfc43172021-05-13T18:34:56ZSébastien BlinSupport for https://tools.ietf.org/html/rfc4317To allow us to switch between audio only/video onlyTo allow us to switch between audio only/video onlyhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/322Conference: moderators should be able to hangup a participant2020-12-10T16:57:26ZSébastien BlinConference: moderators should be able to hangup a participantAll is in the titleAll is in the titlehttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/329Video-conference: Make moderators able to hang up a call2021-01-06T14:55:46ZSébastien BlinVideo-conference: Make moderators able to hang up a callA moderator is only able to change the layout currently, only the host can hang up calls. This needs some change:
+ Add a hangupParticipant API for the daemon which takes the URI of the participant to hang
+ If it's the host, just ha...A moderator is only able to change the layout currently, only the host can hang up calls. This needs some change:
+ Add a hangupParticipant API for the daemon which takes the URI of the participant to hang
+ If it's the host, just hang up the call
+ If not, send to the host of the call a confOrder (https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/6.1.-Conference-Protocol) to ask the host to hang up the call for this participant
+ Clients should show hangup if they are moderatorIteration 25Pierre LespagnolPierre Lespagnolhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/331Video-conference: avoid grid in grid when multiple host2021-08-17T20:11:51ZSébastien BlinVideo-conference: avoid grid in grid when multiple host# Scenario
+ A host a conference with B & C
+ C adds D to the conference
# Expected
We should get a conference of 4 participants with 2 masters
# Current
C mix (A,B,C) and D in a new grid and A sends an ugly grid to other peers.
Th...# Scenario
+ A host a conference with B & C
+ C adds D to the conference
# Expected
We should get a conference of 4 participants with 2 masters
# Current
C mix (A,B,C) and D in a new grid and A sends an ugly grid to other peers.
The [Conference protocol](https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/6.1.-Conference-Protocol) should handle these infos with the video mixer to be able to create a good grid of 4 participants.https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/333TlsSession: use setOnRecv_ for reliable transport2022-07-11T17:46:31ZSébastien BlinTlsSession: use setOnRecv_ for reliable transportlike we do for unreliable transportslike we do for unreliable transportsLaterSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/365Ice: group code for IceSocketTransport & IceSocket & IceSocketEndpoint2021-05-04T21:57:59ZSébastien BlinIce: group code for IceSocketTransport & IceSocket & IceSocketEndpointSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/394Plugin System: add "always"preference2021-02-01T19:51:38ZAline Gondim SantosPlugin System: add "always"preferenceAdd a preference that will automatically toggle a plug-in at call/conversation startAdd a preference that will automatically toggle a plug-in at call/conversation startIteration 27Aline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/396Plugin System: automatic toggling improvements2021-02-18T16:50:14ZAline Gondim SantosPlugin System: automatic toggling improvementsPersist chathandler status for each conversation where it was (de)activated.
Improve automatic toggling management for calls and chats.
Add installation path preference to jami.
Fix unloading plugin crash while at least one of it's ha...Persist chathandler status for each conversation where it was (de)activated.
Improve automatic toggling management for calls and chats.
Add installation path preference to jami.
Fix unloading plugin crash while at least one of it's handler is active.Aline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/395Plugin System: split "always"preference by handler2021-02-18T17:10:49ZAline Gondim SantosPlugin System: split "always"preference by handlerA plug-in can have more than one handler. So instead of automatically toggling all, we split "always" preference for each handler available.A plug-in can have more than one handler. So instead of automatically toggling all, we split "always" preference for each handler available.Aline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/385code smell: some cleanup is necessary in alsalayer2021-07-09T20:55:58ZSébastien Blincode smell: some cleanup is necessary in alsalayerIn src/media/audio/alsa/alsalayer.*
+ std::vector<AudioSample> playbackIBuff_; and captureIBuff_; are unused
+ status_ = AudioLayer::Status::Started; is locked but is atomic so shouldn't be necessaryIn src/media/audio/alsa/alsalayer.*
+ std::vector<AudioSample> playbackIBuff_; and captureIBuff_; are unused
+ status_ = AudioLayer::Status::Started; is locked but is atomic so shouldn't be necessaryhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/386After swarm v1: remove p2p.cpp and related files, lot of clean can be done2022-11-26T22:44:00ZSébastien BlinAfter swarm v1: remove p2p.cpp and related files, lot of clean can be donehttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/392redo daemon initialization2023-09-29T09:59:02ZSébastien Blinredo daemon initializationTODO
Manager iterate over accounts
-> if enabled, load structures and emit to the client that account is loaded
-> Then try to connect
-> Once connected sync & start put/listenTODO
Manager iterate over accounts
-> if enabled, load structures and emit to the client that account is loaded
-> Then try to connect
-> Once connected sync & start put/listenhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/397Plugin System: allow non standard installation2021-02-18T16:49:41ZAline Gondim SantosPlugin System: allow non standard installationAdd jami preference to allow finding plug-in installation folder outside the standard path.Add jami preference to allow finding plug-in installation folder outside the standard path.Aline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/390audio: use Opus PLC and FEC2021-02-03T16:29:41ZAdrien Béraudaudio: use Opus PLC and FECAudio glitches are noticed in case of packet drop. Use Opus PLC and FEC to improve audio qualityAudio glitches are noticed in case of packet drop. Use Opus PLC and FEC to improve audio qualityIteration 27Pierre LespagnolPierre Lespagnol2021-04-01https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/418Plugins: reload after pref change2021-03-02T22:45:22ZAline Gondim SantosPlugins: reload after pref changeRemove from clients the need to reload Plugins after changing preference.Remove from clients the need to reload Plugins after changing preference.Aline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/506plugins: set handlers activation order2021-04-01T12:53:01ZAline Gondim Santosplugins: set handlers activation orderUser should be able to change the order each handler is called from the observable notify.User should be able to change the order each handler is called from the observable notify.BacklogAline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/517Remove hacky underlyingIce()2021-12-29T18:52:33ZSé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::ImplBackloghttps://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/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/534storeActiveIp should be done before each ICE connection2021-05-04T13:12:57ZSébastien BlinstoreActiveIp should be done before each ICE connectionBEcause the public address can change from the ISP without any connectivity ChangeBEcause the public address can change from the ISP without any connectivity ChangeSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/543JamiAccount - Placing calls through DHT: Remove obsolete code2021-05-25T14:07:06ZMohamed ChibaniJamiAccount - Placing calls through DHT: Remove obsolete codePlacing calls through DHT is no more supported. All related code must be removed.\
See https://review.jami.net/c/ring-daemon/+/15663
ICE/UDP component created in JamiAccount must be removed.\
Support for ICE message packaging "version 1...Placing calls through DHT is no more supported. All related code must be removed.\
See https://review.jami.net/c/ring-daemon/+/15663
ICE/UDP component created in JamiAccount must be removed.\
Support for ICE message packaging "version 1" must be dropped as well (see IceTransport::packIceMsg(uint8_t version)).Mohamed ChibaniMohamed Chibanihttps://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/578Agent: Determine a way to send logs (with agent + callee ideally)2022-08-26T23:56:47ZSébastien BlinAgent: Determine a way to send logs (with agent + callee ideally)+ Retrieve logs
+ How does the team get the logs?
+ How to identify both sides?+ Retrieve logs
+ How does the team get the logs?
+ How to identify both sides?Olivier DionOlivier Dionhttps://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/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/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/752Windows: offer full fps range for video camera2022-12-23T20:29:35ZSébastien BlinWindows: offer full fps range for video cameraEg from https://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/747
```
$ ffmpeg -f dshow -list_options true -i video="ManyCam Virtual Webcam"
[dshow @ 000001F46BD265C0] DirectShow video device options (from video devices)
[dsho...Eg from https://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/747
```
$ ffmpeg -f dshow -list_options true -i video="ManyCam Virtual Webcam"
[dshow @ 000001F46BD265C0] DirectShow video device options (from video devices)
[dshow @ 000001F46BD265C0] Pin "Capture" (alternative pin name "0")
[dshow @ 000001F46BD265C0] pixel_format=yuyv422 min s=1920x1080 fps=0.015625 max s=1920x1080 fps=60.0002
[dshow @ 000001F46BD265C0] pixel_format=yuyv422 min s=1600x1200 fps=0.015625 max s=1600x1200 fps=60.0002
```
Jami only displays 60fps (max fps). However with some modification we can offer the range 1,5,10,15...60
I think it's not important as anyway the virtual camera will probably be encoded to 60fps by the original app anyway, and codec will already do optimize, so the data reduction will be minor.https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/754Better handling of SyncMsg2022-08-18T19:21:16ZSébastien BlinBetter handling of SyncMsgin the daemon, SyncMsg can be big, for now it's limited to UINT16_MAX bytes, but ideally we want this to be generic.
`SyncModule::Impl::syncInfos` we should write juste enough data in SyncMsg to get the limit and split in multiple messa...in the daemon, SyncMsg can be big, for now it's limited to UINT16_MAX bytes, but ideally we want this to be generic.
`SyncModule::Impl::syncInfos` we should write juste enough data in SyncMsg to get the limit and split in multiple messages if necessaryhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/794[Design needed]Public swarm discovery2023-11-30T04:15:58ZSébastien Blin[Design needed]Public swarm discovery+ Some ideas https://www.rfc-editor.org/rfc/rfc7033
+ Announce public known conversations to contact
+ Change nameserver to get public invite+ Some ideas https://www.rfc-editor.org/rfc/rfc7033
+ Announce public known conversations to contact
+ Change nameserver to get public invite2023-12-31https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/795Call in large groups - multi-host?2023-01-07T14:02:03ZSébastien BlinCall in large groups - multi-host?If we remove the limit for swarm, creating a call may have issue for the hosts as they will be able to receive and host thousands of calls.If we remove the limit for swarm, creating a call may have issue for the hosts as they will be able to receive and host thousands of calls.2023-12-31https://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/895windows: UT: make and run unit tests in windows2023-11-17T16:34:28ZAline Gondim Santoswindows: UT: make and run unit tests in windowshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/930POC: new linking account mechanism2024-03-28T00:05:08ZSébastien BlinPOC: new linking account mechanism# Goal
Do not use the DHT to transfer the account archive while linking a new device, but rather use a p2p link between the new and old device
# TODO
+ Define architecture
+ POC (client)
+ add docs to docs.jami.net
+ Finalize daemon c...# Goal
Do not use the DHT to transfer the account archive while linking a new device, but rather use a p2p link between the new and old device
# TODO
+ Define architecture
+ POC (client)
+ add docs to docs.jami.net
+ Finalize daemon code
+ Ping design & clients to implement the featureKessler DuPont-TeevinAdrien BéraudKessler DuPont-Teevin2024-01-31https://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 Blin