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
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
SIP specification does not mandate the use of 'Allow'
header and which message must contain this header.
So, the 'Allow' header may be present in some SIP
messages (e.g. INVITE) but not in subsequent messages
(e.g. ACK), thus the current list of methods (if any)
will be updated only if the new list is not empty.
Gitlab: #572
Change-Id: If10c73dd116ebd2bbcec413d377caf524aca8897
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
SIP MESSAGE method is an extention to SIP methods and might not be
supported by all User Agents (UA).
In this change, the MESSAGE method is only used if it's present in
the list of allowed methods (Allow header).
Since the Allow header is not mandatory, if the Allow header is not
present we assume that the MESSAGE method is not supported.
Gitlab: #572
Change-Id: I85d35fa0f9be108b34a538b8c732f1530ad68bd6
Set vector size of remote addresses to component count
when initializing the ICE instance.
Gitlab: #573
Change-Id: Iff02142dfb36326e6baa239900ced9452ab3bb8e
This starts the work to move calls and conference per account,
cleaning up the API and start future re-factorization.
Change-Id: I2a3a2c77e9ba78b1a280bdf8dca7eeaabb72f3fd
deadlock could happen with:
* handleEvents -> pj_lock -> on_data_sent -> iceMutex_
* send() -> iceMutex_ -> pj_ice_strans_sendto2 -> pj_lock
This was fixed by:
* Not setting on_data_sent callback for UDP
* Using a different mutex than iceMutex_ to wait for data send
Change-Id: Ic50698ac9dfe37574f145baa718fff8b74cc99be
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
For sharing location android uses sendTextMessage("swarm:xxx", payloads)
In this case, sendInstantMessage should be used, like composing status
or read.
sendInstantMessage will iterate over the members of the swarm and
send the message.
https://git.jami.net/savoirfairelinux/jami-client-android/-/issues/1024
Change-Id: Ia825ae6a32715e865fa952cfa850550723c9222d
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
As libwrap is used by default, HAVE_SHM should only be true
if directrenderer is not used to avoid useless work
Change-Id: I9f819a7c06c667ccf08066f70104dcd3667f8546
Handle media change request in conference, specifically when adding
video to a an audio only call.
Gitlab: #638
Change-Id: I0eb892eb941d2a62b6046c7b2ac9d128f4bcbd12
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
