If the account is incorrectly registered (i.e. the common case
is that the DHT socket is not correctly initialized),
setRegistrationState(RegistrationState::ERROR_GENERIC) will be
called and the dht will not be usable.
Calling doUnregister will cause the daemon to block on
dht_->shutdown(). Because the account is not ready to be used,
doUnregister() should do nothing if any error happened during the
registration.
Also, removes 2 unused states.
Change-Id: I0393786afea8c13506c7c87caf265b09182ea0ae
When processing an incoming or outgoing re-invite, the ice media
session and its associated RTP sessions are kept until the
new ice media session is successfully negotiated.
Gitlab: #666
Change-Id: I608d241d82b346b2c190ada046eed86dd86a7178
GOOPS is Guile Object Oriented Programming System.
It's easier to extend and break less the scenarios using GOOPS. e.g., a
scenario published on Gitlab should work two weeks later. This is not the case
right now and the goal of using GOOPS is to offer a stable API for the agent,
while keeping it flexible.
Change-Id: If6a038b6d8c371f8e74849749770f1dec8559b91
callbacks, such as transaction_request_cb uses the sipTransportBroker
object. So, sipTransportBroker MUST be destroyed after that every
callbacks are called, so after the destruction of endpt_
Change-Id: I795e02544abf9188db4971d7465ac537b1a568d9
GitLab: #681
if videoRtp is not initialized, the information is dropped. So,
it should be stored to avoid any drop of informations.
Note: in the future the container should change, because rotation
is currently applied to all video streams.
Change-Id: I036ffe7b6a248a3d8d7defeff1be78e008447fbd
GitLab: #678
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
getVideoInput is called in two different place:
+ openVideoInput from the client
+ VideoRtpSession::startSender() from the daemon
Nothing is blocking both sides to do it at the same time.
In this case, two VideoInputs can be created, causing the second
one to fail because the device is busy (used by the first one)
and causing weird results (i.e. sometimes the video is not shown).
Change-Id: I23e34a95efe4972fbe111c19f0f0989f5e8ae8a9
Sometimes, buffer with incorrect capacity were injected into
the audio, causing the daemon to crash.
Before the stream's split, stopStream was flushing the buffers.
In this patch, stopStream will correctly re-init the buffers and
avoid to inject incorrect buffer into the audio.
Also, remove unused value in buf_manager.h and clean some warnings
for log.
Finally, modify engineServiceRing to avoid many push operations
and make it similar to engineServicePlay
Change-Id: I589cea814452d3dbf5172af6369e448dcd9d5c72
GitLab: #676
Because media encoder flush() involves encoding we should change
initialized flag after calling flush(), otherwise, it could lead to
new stream initializing.
https://git.jami.net/savoirfairelinux/jami-client-macos/-/issues/299
Change-Id: I88d5648a6f252bd78776f505f891f09a4e5b12e1
Using JAMI_TIMESTAMP_FMT, developers can now format the log's timestamp
according to their needs and taste. The formatting is the same as strftime(3).
Change-Id: Ibea56852b2efc37f66aeeeda857e307130099720
Decouple the creation and the initialization of media coding
sessions to ease the re-initialization of encoding session
(when resolution changes for instance).
Gitlab: https://git.jami.net/savoirfairelinux/jami-project/-/issues/1294
Change-Id: Id5927d4aeb29bc9d4fe806bde6dc9bd28a0e6fe2
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
