jami-daemon issueshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues2020-12-24T21:26:58Zhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/306jams contact synchro - retrieve and display avatar + contact first name/last ...2020-12-24T21:26:58ZGuillaume Hellerjams contact synchro - retrieve and display avatar + contact first name/last nameWhen the contact list is retrieved, only the username is displayed. vcard is exchanged after first interaction with the contact
![image](/uploads/0db02a44e73c4c580256fa1e624f63c0/image.png)
Aim is to retrieve the avatar and contact fir...When the contact list is retrieved, only the username is displayed. vcard is exchanged after first interaction with the contact
![image](/uploads/0db02a44e73c4c580256fa1e624f63c0/image.png)
Aim is to retrieve the avatar and contact first/name so info can be displayed directly when the user connects or the contact list is synchronized, without having to wait for an interaction between each contact to retrieve the vcard
even more important when we are in LDAP/AD config as we have no username
![image](/uploads/44c0ea92833eb9ac4da4008a2452eb6e/image.png)Adrien BéraudAdrien Béraudhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/305Swarm: remove conversation2021-06-12T11:37:12ZSébastien BlinSwarm: remove conversationImplement https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#remove-a-conversationImplement https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#remove-a-conversationSwarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/304Swarn: declineConversationRequest2021-05-06T19:37:30ZSébastien BlinSwarn: declineConversationRequestSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/303Swarm: (Missing RFC) Informations in the request2021-07-09T18:43:54ZSébastien BlinSwarm: (Missing RFC) Informations in the requestWhat needs to be included in the request and how?
An avatar?
A title?
A short message linked to the invite?What needs to be included in the request and how?
An avatar?
A title?
A short message linked to the invite?Adrien BéraudSébastien BlinAdrien Béraudhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/302Swarm: Get conversations requests & sync2021-06-12T11:37:24ZSébastien BlinSwarm: Get conversations requests & synccf https://review.jami.net/c/ring-daemon/+/15748 and https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/6.2.-Sync-Protocolcf https://review.jami.net/c/ring-daemon/+/15748 and https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/6.2.-Sync-ProtocolSwarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/301No relay (Turn) candidate in SDP with IOS when being connected in LTE/4G2021-02-17T16:19:15ZCyrille BéraudNo relay (Turn) candidate in SDP with IOS when being connected in LTE/4GSee attached file for log (with an Android comparison)[sdpios-andoid.log](/uploads/891e408417fd3059abed50184563f396/sdpios-andoid.log)
To reproduce:
Be connected on LTE/4G, make a call.
btw, why all the addresses are twice as candidate?See attached file for log (with an Android comparison)[sdpios-andoid.log](/uploads/891e408417fd3059abed50184563f396/sdpios-andoid.log)
To reproduce:
Be connected on LTE/4G, make a call.
btw, why all the addresses are twice as candidate?BacklogMohamed ChibaniKateryna KostiukSébastien BlinMohamed Chibanihttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/300Swarm: fix potential crash + verify libasan + sonarqube outputs2021-03-04T20:01:49ZSébastien BlinSwarm: fix potential crash + verify libasan + sonarqube outputs
+ Remove todos
+ Verify tests
+ Remove todos
+ Verify testsSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/299Swarm: remove a user from the conversation2021-04-19T13:28:58ZSébastien BlinSwarm: remove a user from the conversation+ Implement https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#remove-a-device-from-a-conversation
+ Add tests+ Implement https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#remove-a-device-from-a-conversation
+ Add testsSwarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/298Swarm: Remove a device from the conversation2022-07-13T17:35:28ZSébastien BlinSwarm: Remove a device from the conversation+ Implement https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#remove-a-device-from-a-conversation
+ Add tests+ Implement https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#remove-a-device-from-a-conversation
+ Add testsSwarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/297Swarm: implement DRT (after first version)2023-04-28T19:42:53ZSébastien BlinSwarm: implement DRT (after first version)https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#drt-name-will-change
# In progress
+ add tests for mobile DRT
+ Client: remove limit of 8 participants
+ Test in real environment
# TODO:
+ D...https://git.jami.net/savoirfairelinux/ring-project/wikis/Group-chat-feature-(design-draft)#drt-name-will-change
# In progress
+ add tests for mobile DRT
+ Client: remove limit of 8 participants
+ Test in real environment
# TODO:
+ Debug last locks
+ Cleanup code
+ Finish last tests
+ Document on docs.jami.netSwarm-chatSébastien BlinFadi ShehadehSébastien Blin2023-02-28https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/296Swarm: see for file transfers (NEEDS DESIGN)2021-06-12T11:37:07ZSébastien BlinSwarm: see for file transfers (NEEDS DESIGN)Swarm-chatSébastien BlinAdrien BéraudSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/295Swarm: add a test for sending a message to multiple participants at once2021-06-12T11:37:27ZSébastien BlinSwarm: add a test for sending a message to multiple participants at onceScenario:
Alice creates a conversation with 8 members
Then sends a messages
All devices should receives the whole conversationScenario:
Alice creates a conversation with 8 members
Then sends a messages
All devices should receives the whole conversationSwarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/294Swarm: default branch should not be "master" but "main"2021-02-19T17:12:18ZSébastien BlinSwarm: default branch should not be "master" but "main"Swarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/293Swarm: multi-device management2020-09-18T19:50:25ZSébastien BlinSwarm: multi-device managementhttps://git.jami.net/savoirfairelinux/ring-project/wikis/technical/6.2.-Sync-Protocol
Related patch: https://review.jami.net/c/ring-daemon/+/15584https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/6.2.-Sync-Protocol
Related patch: https://review.jami.net/c/ring-daemon/+/15584Swarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/292Swarm: Fix build on jenkins2020-12-23T19:37:25ZSébastien BlinSwarm: Fix build on jenkinsPatches are not building for nowPatches are not building for nowSwarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/291Swarm: redo code for gitserver2021-04-19T14:20:32ZSébastien BlinSwarm: redo code for gitserverThis commit is ugly
# TODO
+ [x] Remove ioPool and only use callbacks
+ [x] Support shutdown
+ [ ] Multiple want and improve negotiation
+ [ ] Recheck answerToWantOrder();
+ [ ] Support depth request (https://github.com/git/git/blo...This commit is ugly
# TODO
+ [x] Remove ioPool and only use callbacks
+ [x] Support shutdown
+ [ ] Multiple want and improve negotiation
+ [ ] Recheck answerToWantOrder();
+ [ ] Support depth request (https://github.com/git/git/blob/master/Documentation/technical/pack-protocol.txt#L256)Swarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/290[Maybe fixed/To check]ICE/TURN - Investigate why relay candidates are most of...2021-02-15T17:07:51ZMohamed Chibani[Maybe fixed/To check]ICE/TURN - Investigate why relay candidates are most often selectedIt has been observed in many environments when TURN relay is enabled, that the ICE negotiation will frequently result in relay candidates (TURN) being selected while server-reflexive or peer-reflexive candidates should have been selected...It has been observed in many environments when TURN relay is enabled, that the ICE negotiation will frequently result in relay candidates (TURN) being selected while server-reflexive or peer-reflexive candidates should have been selected instead. Typically, when the "connectivity checks" succeed for both relay and reflexive candidates, the reflexive candidates should be selected because of their higher priority.
Note that in the current version, the "Aggressive nomination" is used to optimize the connection time (see [RFC5245](https://tools.ietf.org/html/rfc5245#section-8.1.1.2) for more details). This may have a major impact on the selected pair. Still, we need to know if this is the only cause or if other factors are involved. We also need to know if we can improve it.Mohamed ChibaniMohamed Chibanihttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/289Android - Audio does not automatically routed to headsets when plugged2020-09-04T18:41:35ZMohamed ChibaniAndroid - Audio does not automatically routed to headsets when pluggedOn Android, if a call is started on loudspeakers, the audio is not automatically routed to the headset if it's plugged. The user has to tap on the speaker icon on the UI, to manually route the audio to the headset.On Android, if a call is started on loudspeakers, the audio is not automatically routed to the headset if it's plugged. The user has to tap on the speaker icon on the UI, to manually route the audio to the headset.https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/695Connectivity: be more resilient if a TURN server is not available2022-11-26T22:42:09ZSé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 (jami-daemon~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.https://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.Backlog