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
Caught by ut_media_encoder:
READ of size 8 at 0x602000029818 thread T0
#0 0x5649e914d6e0 in jami::MediaEncoder::send(AVPacket&, int) media/media_encoder.cpp:504
#1 0x5649e914d05c in jami::MediaEncoder::encode(AVFrame*, int) media/media_encoder.cpp:480
#2 0x5649e8cac119 in jami::test::MediaEncoderTest::testMultiStream() media/test_media_encoder.cpp:183
outputCtx_->nb_streams can be different from encoders.size(), and if
not checked can lead to a crash
Change-Id: I3c0217ec3e1d50950bf46989e0dd6797fee8972e
This allows us to build with webrtc-audio-processing distro packages
currently available across supported Debian releases.
Change-Id: I25584a0564ceb78e8eefec78e5e903356c37ddab
This fix ut_media_encoder
Also avoid crash when outputCtx_ is nullptr and the format is unrecognised.
Change-Id: I6df5a2e229e0313ea2b3c34b37f9f2900058c75f
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
