jami-daemon issueshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues2023-01-07T14:02:03Zhttps://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/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/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 Blinhttps://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/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/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/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/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/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/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 Blin