Guile is confused by agent.scm and agent. It will try to load the ELF file
instead of the Scheme script when `(use-modules (agent))`.
Change-Id: Ieead4c384f10df9ead351a6ae66b21f708e97424
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
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
The agent will be written in Guile Scheme instead of C++ in
order to give maximum flexibility to developers of scenarios.
Thus, bindings will be added for the public Jami interface.
In other words, the agent will be a client of yet another
Jami's bindings.
Change-Id: Ic2cd333007d0b1aad56c02b116ea708b56e96cc5
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
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
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
Instantiation and initialization of ICE are done in a single
stage (in the class constructor).
To initialize the ICE instance, connection information must
first be gathered asynchronously.
However, when sharing ICE media instance between subcalls,
it's better to have a valid ICE instance as soon as possible
(even if not fully initialized) to proceed with the call
initialization process, then wait for ICE initialization to start
the call.
Thus, the ICE instantiation will be performed synchronously as
soon as the parent (main) call is created, then it will be
initialized asynchronously when the connection info are ready.
Gitlab: #619
Change-Id: I9c97516238f1a690603975ec968c8c6733155d4a
With this patch, contact left is removed in one to one. So, if
a contact left, they still receive message notification and they
will generate conversation requests and retrieve the old history.
Moreover, if they remove and re-add a contact, they will receives
a confirmation for the previous conversation and retrieve the old
history.
This avoid duplicates and read-only conversation.
GitLab: https://git.jami.net/savoirfairelinux/ring-project/-/issues/1282
Change-Id: Id820482e82e23334632e76bf4920255efb45f4cb
This makes the log sending messages in the order the client will
show it and avoid to calculate linearized parent for each commit.
However, this linearized parent can change over time. In fact, if
a merge happens, the parents of the messages shown can be
modified.
Change-Id: I26372aa52de0e5f89140680a4beaf5fc7ec52163
GitLab: https://git.jami.net/savoirfairelinux/ring-project/-/issues/1282
This patches introduces two new concepts in order to reduce the code
of JamiAccount.
ChannelHandlers to manages protocols logic. The idea of this class
is to handle channels per protocol, accept and reject it.
AccountModule, to be able to separate logic between call managements
datatransfer, config and conversation but give an interface to
detect when some events should occurs.
Change-Id: I34ff07852c06d7266411f1ffb32b71a1834aba4f
GitLab: #603
Avoid adding generic srflx candidates if UPNP candidates are
available. This will reduc the size of the check list and also
increase the chance for UPNP candidates to be selected.
Change-Id: Ia1504beffe7e12063ff1c1ad0f54d65bb60496d6
Gitlab: #607
