Sébastien Blin authored 3 years ago and Adrien Béraud committed 3 years ago

/invited was not checked for kicking member, add this directory
and cleanup the function for resolving votes too.

Documentation is updated:
https://git.jami.net/savoirfairelinux/jami-project/-/wikis/technical/\
2.3.-Swarm#remove-a-device-from-a-conversation

jami-client-qt#340

Change-Id: I18882066e3e42ced8ed656da3b1d2ed0a19929cf

In some cases, a user in the swarm can update its certificates.
However, the new certificate MUST be checked and MUST be signed
by the account.
So, this patch validates two scenarios:
+ Check that a fetch error is sent to the client whenever an invalid
certificate is detected in the original clone
+ Check that a fetch error is sent to the client whenever a
certificate is replaced during the conversation.

Change-Id: Ieb15fb6444dcf4541f00c511a9f4ba0c64617130

If a device expires, a migration will regenerate the device's
certificate. In this case, the device certificate in swarms must
be updated.
So, the idea of this patch is to verify that the current certificate
in the repository for this device is still correct. If the device or
the member got invalidated, it tries to replace the current certificate
(updated via the migration). So that the new commits will still be valid.

Change-Id: I75b19b0edbb5601a758a73a4c4a44678d77295e1
GitLab: #684

On older versions, removeConversation didn't update appdata/contacts
causing some removed conversations to be announced in contacts details.
On Android, this hide the contact from the smartlist, as it's waiting
for a removed conversation.

Change-Id: I05be12ffcd2e5fe38d84c6f972b97e082c612ac7
GitLab: #714

When a device is expired, the migration will update the certificate
chain with the previous key. So, after a migration, the device's id
must be unchanged.
However, if a device is revoked, this should trigger a re-generation
of the device with a new PrivateKey (so generates a new device).
Add related unit tests.

GitLab: #684 (this is some preparative work)
Change-Id: I7ff0cff97b7285186539cfadc6e33b620ded5b27

+ testSetMessageDisplayed and testSetMessageDisplayedPreference were
broken because the lastDisplayed behaviour was recently changed to
support syncing across devices. Update the two related tests. Also,
avoid to update the lastDisplayed on merge
+ testSyncWithoutPinnedCert was badly written causing some sporadic
failures.

Change-Id: I364818b4ececb0fa63e87441f55a7da76fe1feb6

Because swarm is a synched history compatible with multi-devices,
if a message from the swarm is read on one device it should be
synchronized with other devices as much as possible.
The idea of this patch is to add lastDisplayed sent in synched
datas to allow clients to update the read status. However, there
is several scenarios to take into account, because the history
can be partially synched across devices.

5 scenarios are supported:
+ if the last displayed sent by other devices is the same as the
current one, there is nothing to do.
+ if there is no last displayed for the current device, the remote
displayed message is used.
+ if the remote last displayed is not present in the repo, it means
that the commit will be fetched later, so cache the result
+ if the remote is already fetched, we check that the local last
displayed is before in the history to replace it
+ Finally if a message is announced from the same author, it means
that we need to update the last displayed.

If the last displayed message is updated, AccountMessageStatusChanged
is triggered for the client.

Doc: https://git.jami.net/savoirfairelinux/jami-project/-/wikis/technical/2.3.%20Swarm
Change-Id: Iedd29129d72cbeb43499471bdfd492dd4d49dcb6

Accounts can see their certificates expire. When it's the case, a
migration is needed. However, several regressions can happen, because
this behaviour can be tricky to test correctly. In this patch, a
test is added to validate that the migration is done whenever the
certificate expires.

+ OpenDHT needs to be bumped in order to be able to change the validity
period of a certificate.
+ In ArchiveAccountManager, a method is added to change the validity
of a certificate in the chain.
+ This patch also fixes a crash when a migration occurs directly on
the archive (info_ was null causing a segfault).
+ Finally, cleanup some signatures unused in JamiAccount.

GitLab: #684 (this is some preparative work)
Change-Id: I901bc67fd63ce2ab26ded64662f8333d3a0eed50

The method was bugguy, because the whole point here is to check
if the conversation contains enough informations at this point to
validate the user, not to compare with pinned certificate.
Moreover, a user can sync the history from another device, without
ever connecting to the original author, so the certificateStore
will not have the device certificate in this case, so only uses
from the repository.
A test is added to reflect this.

Change-Id: I3af5e7769174eedcb54e17181d4530593960c9c9

Mohamed Chibani authored 3 years ago and Sébastien Blin committed 3 years ago

When muting/un-muting the video, a re-invite is performed
leading to a full media renegotiation and restart,  including
ICE session if used.
With these changes, the mute/unmute video will still require
a re-invite (a new SDP to indicate the new media directions), but
the ICE session is re-used and only the video is stopped/started
accordingly.
The behavior improves the UX by avoiding unnecessary audio disruptions
and is more compliant with SIP/ICE specs (see RFC-5245 section 9.1.1.1
for example)

Gitlab: #671

Change-Id: I13caf9a965af1d76e922fe5f6b86d5332b3296d6

Change-Id: I7380645f022b1b08d2a961e191c3dd978916fe0e

Change-Id: I795e3f2f69c07349bf84c87dbcafb502dc8490f8

Add a media negotiation unit test for auto-answer mode

Gitlab: #645

Change-Id: I37f768ce48e078fbd95a2c9b28997877a4dc468d

Mohamed Chibani authored 3 years ago and Sébastien Blin committed 3 years ago

Currently, the media attribute in the SDP is always set to
'sendrecv' regardless of the mute state of the media.
In this patch, media direction will be set according to mute
state of the media.
Note that this only applies if the mute/unmute requires media
renegotiation (SIP re-invite with new SDP session). Currently,
this only the case for video media. For audio, mute/unmute is
done locally without SIP re-invite.

References:
RFC-3264
RFC-4317 (non-normative)

Gitlab: #645

Change-Id: I604331255bd25dfe732e192039a673a0980105fa

Sébastien Blin authored 3 years ago and Adrien Béraud committed 3 years ago

Change-Id: I547dfeaf1734873ac9f8db82a181769de11a2bb6

This patch fix 3 little issues:
+ "device" was always empty. Uses the transport to fill the device
field. This will be used in the next version of the protocol.
+ raiseHand was bugguy in two ways:
    + It was only usable by moderators
    + Somebody was able to change the raiseHand for other peers

Change-Id: I32bf37c5063973a5a5962dd8984c87fb05d33a3d

Because some callbacks can take a long time (accepting a SIP channel
will starts to sync profiles, ask for new channel, etc), control packets
are handled in their own thread. However, if the peer accepts a request,
it can starts to use it and send data on it. When finished, it will close
the socket and both peer will remove the channel.
In some case, the channel can be removed before
MultiplexedSocket::Impl::onAccept, causing upper layers to handle a
bad channel. In this patch, we removes the channel only when upper layers
know that the channel is accepted and ready to use. Also, onAccept()
doesn't create wrong channels (which was a bug, where isInitiator() was
in the wrong state).

GitLab: #659
Change-Id: I4f45feacc2624ce0135ace09f7e0188b56fcf81f

AcceptTrustRequest should update conversation's module to directly
return the syncing conversation. Moreover, configurationMutex_ should
be recursive to allow sync between trust and conversation's requests.

This fix ut_conversationRequest where the problem was that the
conversation's requests were updated after ContactAdded, causing
removeContact() to remove the conversation, but acceptTrustRequest
re-adds it during the operation.

Change-Id: If676dc58290f87c289a6e63eb9afa04d2cc25df5
GitLab: #659

Mohamed Chibani authored 3 years ago and Sébastien Blin committed 3 years ago

Remove obsolete code kept for backward compatibility.
Add call transfer test case

Gitlab: #470

Change-Id: I81472b8308ec402911670e8658308a184b97206c

Sébastien Blin authored 3 years ago and Adrien Béraud committed 3 years ago

This patch fixes current unitTest
+ Fix testCreateConversationWithMessagesThenAddDevice messageReceived
flag
+ Remove useless sleep in tests
+ in ut_conversation fix messageReceived flag
+ lock convInfo and convRequests to avoid invalid write operations
+ fix pending callbacks if connected via a DHT request
+ remove useless log

Change-Id: If53ecf0c064e9c1424c11a4af1e13d31294e6be9

Sébastien Blin authored 3 years ago and Adrien Béraud committed 3 years ago

The conference should be used in the tests after the first
conferenceChanged, to be sure that every calls are binded to the
conference.
Then, before adding a call to the conference, it should be CURRENT
from the host perspective, not the receiver. So, add "hostState"
to store the state of the call from the host perspective.

Change-Id: I9d27b4c0461ede05d27ea849de08c22e9fc3b249

Adrien Béraud authored 3 years ago and Sébastien Blin committed 3 years ago

This starts the work to move calls and conference per account,
cleaning up the API and start future re-factorization.

Change-Id: I2a3a2c77e9ba78b1a280bdf8dca7eeaabb72f3fd

Note: also cleanup warning for conversationRequest and fix test

Change-Id: I4b14dd5983bdde2d479093a33ee3d6343fa8ed87
GitLab: #659

This patch fix several problems:
+ participants_ must be protected and not iterated while accessed
+ getVideoMixer() do not generate a video mixer, this is only
managed at one place.
+ Remove setConfId, enter/exitConf are here for this and this
is causing the videoMixer to not be destroyed in time, because
exitConference() was called after setConfId(""). This was causing
crashes because the videoMixer will update for the last participant
with the error: "The call is not bound to any conference"

GitLab: #660
Change-Id: Ic60bc7377b0315f7e2906ab03a7653381436180c

removeContact("SELF") MUST NOT remove all swarm.

Change-Id: I421a235fd2beb2fc33276fd58aa1413454b40233
GitLab: #665

Sébastien Blin authored 3 years ago and Adrien Béraud committed 3 years ago

If a contact is added, the first device will erase the trust request,
but the second device will update the contact but not the trust
request. Causing, the removeContact to generate a new request for
the previously created conversation.

Change-Id: I2f0a48b3c6b6b18ed6218e7a08c61de2beb08d3d
GitLab: #664

When a call is held, the media direction in the SDP
for an active media must be set to sendonly.
Also add unit test for simple hold/resume operations

Gitlab: #644

Change-Id: Ib41434c55f9be1a6d34a7d51c9127af89081c8e8

Aline Gondim Santos authored 3 years ago and Sébastien Blin committed 3 years ago

GitLab: jami-project#855
Change-Id: I425a4b0049f1ade8c8eeeb93fc79f8d36bd25585

wait for contactAdded before actually removing it.

Change-Id: I29a6a2220a2e77ca023abdccab44c1f6a65bd5e5

Adrien Béraud authored 3 years ago and Sébastien Blin committed 3 years ago

Change-Id: I40171f3c5872bd5bf5719fd22a6a2af20ce6263f

Change-Id: Idbe771a647bf16b45d88755d684623895e5a8e82

Sébastien Blin authored 3 years ago and Adrien Béraud committed 3 years ago

This work follow the JamiAccount split started before. This moves
the ConnectionManager's callbacks code related to data transfer into
transfer_channel_handler and improves syncing by sending contact's
avatars (where a swarm is present) to new devices.

Note: for now, contact's avatar are managed by the client. So, this
code will only transmit avatars if the profile is found. For now,
the only path tested is the one used by jami-libclient. To be able
to fully sync all avatars, the avatar management should be moved in
the daemon with future work.

Finally, in syncHistory a test is added to validate the behavior.

Doc: https://git.jami.net/savoirfairelinux/ring-project/-/wikis/technical/3.8-Sync-profiles

GitLab: https://git.jami.net/savoirfairelinux/ring-project/-/issues/1282
Change-Id: Ic98da34aabf1be070a57dcac55bba0a00c555445

If a conversation is not cloned, when detecting a new presence,
needsSyncingWith MUST return true if one conversation needs to be
cloned. Else, it will result in an infinite syncing.

Change-Id: I3a9bcab9f8a845161ceac7d75d8842f8b338ed57

Mohamed Chibani authored 3 years ago and Adrien Béraud committed 3 years ago

Changing the media source of a media stream (video in particular)
must trigger a reinvite.
Since currently we do not support changing video properties (resolution
in particular) in the same media session, any changes in the video
properties must trigger a re-invite to restart the media locally and on
the remote peer.

Gitlab: #653

Change-Id: Ibd6192135d272908963cfbc585bec95c66881a28

acceptTrustRequest will set the conversation as ready.
removeConversation should be done after

Change-Id: I966cc2142d00bda880d63f11c52c36faceb11aa7

After removing and re-adding a contact, the second conversation
will be deleted and the first conv will be recloned. However,
some text messages can be present. In this case, we can re-add
them.

Change-Id: I7cafcf76b5d36769ea939729a2fbf6730853cafb

cancel a file from the user should removes the file from the
waiting map to avoid to relaunch the download on the next sync.

Change-Id: I0696364d0131c8dde563b97b8b965e99d1f5686a

Sébastien Blin authored 3 years ago and Adrien Béraud committed 3 years ago

For now, the daemon doesn't handle the profile of the account nor
the compression. However, it does handle sendTrustRequest, which uses
the DHT to transmit requests. DHT values must be small, else it will
not be sent. So, this patch cache the compressed payload generated
by the client and removes it as soon as the confirmation is received.
This allow the daemon to retry to send request with the payload sent
originally.

Change-Id: I3fac542c6a53febdb7f1d0c516ec2d9ff5b317be

Change-Id: I14df750d459a0771f4e60923a1ecf3bfb938a78b

This is only to avoid to return weird states from the daemon to the
client. But if a conversation is added through addContact,
removeContact should be called to removes it. However, if
removeConversation() is called, the conversationId in contact's
details MUST be updated.
Same for acceptConversationRequest, this should removes related
trust requests

Change-Id: I4b273075862cdcdffc7f13c1b5e581a2eebc411d