This is a pretty trivial patch as all the necessary logics are
already supported by the deamon.
A client can use sendMessage with flag = 2 to add a reaction.
This only adds a "react-to" in the body of the message that the
client can interpret.
To remove a reaction, the client can use editMessage (and set the
body to "" for the id of the reaction), also there is no limit
on the content of the reaction and multiple reactions can be added
to the same message.
For non compatible clients, it will be shown as a simple text message
as it's the same type.
Change-Id: I7b13d32771109118b94ed17d0b918e66487e94bb
Initializing a ICE session will need to gather candidates. The TURN
can be long to retrieve, and fails can be really long to detect.
There is at least 3 cases of failures:
+ IPv6 badly configured, which can cause a DNS resolution timeout
of several minutes (that's why the IP was cached)
+ Empty DNS entries, causing a resolution failure
+ A TURN server un-reachable or wrongly configured (e.g. 1.1.1.1)
The idea here is to resolve the TURN and test the connection before
caching it. And use it when cached.
This avoid all resolutions steps and we're basically sure that
it was working.
Other approaches:
+ Add a new callback in pjsip to detect that the TURN is taking too long
to remove it for next calls, but I prefer to not add another patch in
pj and it's not an ideal solution
+ trickle ICE to not wait for all candidates, but this is a big changes
and will generate more DHT messages
+ Do not retransmit messages, but this is against the RFC
Change-Id: Iaec4308bca8cbbbfa4d6b1b6d7a7759b8062a67a
GitLab: #781
The new logic is there! Swarm is working since some time now, so we can
remove previous logic.
GitLab: #524
Change-Id: I5ca172e9349694d944c9561d97fe8a63d190ebf3
This avoid mobile phone to host conferences for others unless
explicitly authorized by the user.
Clients can show it via the "hostConference" conversation's preference.
Documentation: https://docs.jami.net/technical/swarm.html#call-in-swarm
GitLab: #312
Change-Id: I9bbd3e394cd1b3bcfd4a3120d9023a5ed686303d
This patch introduces the ability to start calls and extends the
usage of rendezvous points to swarm with multiple participants.
When starting a call in a swarm with multiple participats, one device
will work as the host of the conference, and the caller will
immediately start the call alone.
Other peers will receive a commit and a notification to be able
to join the active call. To join a call, users needs to call
rdv:uri/device/convId/confId to be added (if authorized) to the conf.
There are some majors differences in the process.
First, every conversation will be able to decide a default host
for conferences. This still needs some design and will be
introduced in another patch. For now, the caller is the host.
Then, because all members of the call may not be interested to join
a call, or they may want to get several calls at the same time, the
system must be able to manage more than one active calls (e.g. a
company with multiple projects can do several standups at the same
time).
Finally, in the conversation, two commits will be generated to be
able to know what active calls are available. The first is
announcing that a conference started, the second announces that
the conference stopped (the host closed the call).
However, this introduces a difficulty. The host may crash and not
commit the end of the call in time. In this case, hostedCalls are
stored in a file and the conversation is updated during the init
of the daemon.
Change-Id: I081a4920edb3773bbed884ae50f34e476ad42094
Documentation: https://docs.jami.net/technical/swarm.html#call-in-swarm
GitLab: #312
As a measure of refactorization of the code and to prepare to the
development of dhtnet, the following changes aims at seperating
jami-specific code to connectivity-specific code.
GitLab: #778
Change-Id: Iaa08100f7d61c80292f039a5aae66819cc85b0e9
If an error occurs during the execution of git_remote_fetch, there
is no need to signal any error to the client as it's not a critical
issue (no malformed conversation, mode is recognized, no unauthorized
method) and the sync will be retried later.
Change-Id: I2d875445e51aa6cd78eb2e7dbfe5efb8b2831860
It's not possible to replace the DRing namespace for jami because of conflicts
with namespaces and classes defined under the jami namespace. Thus, use libjami
as the namespace.
Script to reproduce:
rg -l DRing | sort | uniq | awk '$0 !~ /NEWS/' | xargs sed -i -e 's|DRing|libjami|g'
rg -l DRING_ | sort | uniq | xargs sed -i -e 's|DRING_|LIBJAMI_|g'
sed -i -e 's|dring|jami|g' src/jami/CMakeLists.txt
sed -i -e 's|dring|jami|g' src/jami/def.h
Change-Id: I80e8c8b58a7586527a016bbef850bab07869c473
logUntil should retrieve the commits with the commit passed.
Add a LogOptions parameter to avoid too much parameters.
Change-Id: I77a0150b135b14fe44577747d2b1a86cb2cf2509
The sinks only should be created when there is a video device
available. If no video device is available, no sinks should be
created.
Change-Id: Iec35288bf9966eb664470b2f8c1e5738f6909893
In some cases the file "contacts" was badly synced. Also, if for any
reason "contacts" is not correctly formed, we may be able to fix it.
This patch handles two cases of failures:
1. If the contact details doesn't contain any conversationId BUT
a 1:1 conversation is found with this contact, we update the
conversationId in the details.
2. If, for some reason, multiple 1:1 conversations are detected
with the same contact, we only keep the one in the details, as
it should be the correct one.
This should fix the fact that for some conversation, calls are not
written in the history (cause getOneToOneConversation() returns
nothing).
Change-Id: I5dd9fc51999540d8a4230f8fdce828a461da752a
If a new stream is requested, and the client-qt does not specifically
states that it should be not mute, then accept muted media.
GitLab: #770
Change-Id: I1d9d6bdddfb40216d1750d4246e63745773033a6
This store user's preferences per conversation into
conversation_data/<convId>/preferences
In this way, the daemon is able to sync this file across devices
and remove preferences at the same time we remove the conversation.
For now, only support "color" and "ignoreNotifications"
The preferences are synced via partial SyncMsg sent across devices.
Change-Id: I8fe74cc06733ad61d45d721e0264b1941d4cf122
+ search method was incorrect if no type provided
+ some tests were not waiting for correct signals
Change-Id: If6ba59829defb168f51c4a8e25f2054cd649b8c2
This will setup the correct environment for each tests and echo tests that are
running. Users can extend this with the TESTS_ENVIRONMENT variable.
Change-Id: I7aa0f04721251a6ea48cb4c2e7c2238f95d67267
To apply translations, first try to read if the JAMI_LANG variable is
set, if not, try to get the system language.
GitLab: #747
Change-Id: Ie458abcc07c0d0fd151172e172fe1418e5f06e7f
This gives to clients the ability to perform search for messages
with several parameters (account's id, conversation's id, author,
period, max number).
(To discuss) This patch introduces the search API, and a signal
(MessagesFound) to return a result.
GitLab: https://git.jami.net/savoirfairelinux/jami-project/-/issues/1382
Change-Id: Ibc4665449fa0da71a015d1d18d6d0d3209331d43
+ Some code were unused
+ Ask for profiles in one to one after a clone, this
allow to get the profile after adding/removing/re-adding
the contact as the peer will not know and got a cache
where they sent the avatar before.
+ Update unit-test
Change-Id: Ide1df647dbec63f343b60c1c622d1a214f4c3016
Several improvements are included with this patch:
1. confirmed is resetted when account is removed, this allow to
send a request when conversation is added back and reset the
whole matrix, avoiding duplicates
2. Banned can be due to harrasement. In this case, keeping the
conversation like the old behavior (pre-swarm) is better, to keep
proofs. Also re-adding back a contact is immediate if it was a
mistake as the conversation is kept back.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1449
Change-Id: I13da8ce9bd431b91ce7b7d455dae561358c62f10
Removing a contact was not actually closing all connections, causing
the remote contact to be able to call even if it was banned if there
was more than two channels opened.
Rewrite closeConnectionsWith as it was unused to use it to close
connections with the banned contact.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1449
Change-Id: I147f437370a553f0682b0cea060720a6c473f8a2
This is useful for the conversation_module if any channel is pending
while shutting down, as the previous fetch status was not updated.
More generally, every connectDevice() should call the associated
callback.
Add a unit test to replicate this scenario.
Change-Id: I72f2975dc15dd4bac3f55c2f899ebb1ae5a7a7f3
Now that it's been months since all clients supports swarm, we
can assume that everybody is using a version compatible with
swarm now.
So, downgrading conversations to a non swarm if a DHT message
comes is not necessary and it's just unwanted code.
Change-Id: I83b83d592ea43219cbdecb31fa8b5a71b897e487
GitLab: #312
After a re-add of an invited contact, the validation was bugguy causing
the conversation to be invalidated and erased due to malformed commits
Change-Id: Ib500ae117f0c53774cfb1eec23aa160ba2f86420
A contact can be banned from another device. In this case,
JamiAccount::removeContact is not called and the daemon only call the
dedicated callback.
So, remove the conversation requests and connections to the banned
contact (and avoid future incoming calls if connected) when the
callback is called instead in JamiAccount::removeContact() as it
will be called in a multi-device context.
Change-Id: I1ac8b441268d7bfc9bb6627fbbbc7b83e2e75052
sipTransport was only true on destroy, causing tlsInfos_ to be
always incorrect.
Moreover, if the SIPTransport is generated from a channeled socket,
we do not need to copy the peerCertificate.
Finally, update conference to use the tlsInfos_ to get the URI
instead of playing with peerNumber's
Change-Id: If8b93a4614e790e6ffbfd1bcc0aa68f6407344ce
In the contact list, receiving a confirmed request for a non-active
contact would re-add the contact. If the contact was removed then
re-added, the conversation would be badly updated & removed, instead
of replacing the conversation by the old one.
Finally, remove the replaced conversation after the clone of the
new one, to avoid making the contact disappear while cloning.
Add some tests to validate the scenarios.
Change-Id: I67a94604c5869804ed66b390aa26cca9420fbc28
+ Bump deamon version to enable multistream
+ use signal for recorder to check if file stopped
+ answerMediaChangeRequest pass isRemote for tests
Change-Id: I396b8246264cb7826350f75e74f20f05b864f384
If a conversation was previously removed, it couldn't be re-cloned
due to the fact that the sync value can come from a previously
offline device.
Like updateContact in contact_list, use created/removed to determine
if it's a re-added contact to be able to re-sync again.
Change-Id: Ibe16d2bda02cbbe41b16d8b365d9c8ef02b36140
