jami-daemon issueshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues2019-03-27T14:51:56Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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