This allows us to deallocate all held strings in one go without having
to iterate much.
Requires adjusting tests, Makefiles and dependencies.
Change-Id: Ic214f9dd2cd9609cb472301f52bb10d1918d859e
Change old code to directly return `str` objects instead of pointers to
allocated ones. Largely a no-op change but makes some code easier and
eliminates some old kludges.
Change-Id: I2be19dd24bb7ff046d86cc32a3af235283e65dd0
Use single shared function to set `opts`. Set the "block egress" flag in
that same function. This fixes "block egress" not being set when media
is played from the player cache.
Change-Id: I3266b76974b61b4034f55f335151506039530283
The cache index object contains an embedded RTP payload type, which uses
arena-allocated strings. Switch memory arena prior to calling
codec_init_payload_type(), and then switch back to call context when
done.
Change-Id: Ic2758ae9b8a8f8e721be54e6323302b1a73204f6
Introduce global generic memory arena variable, instead of having just
a call-specific memory arena. This makes it possible to use memory arena
outside of call contexts. Define previous call-specific functions in
terms of the generic ones.
Change-Id: Icde4f63f02dacbf8abfbaf107ea8b5bbe18d5eb8
If a decoder thread took over the player's coder, make sure we re-create
the AVPacket in the player's coder if needed.
Change-Id: I3fda8768766480cfb1d6d67dbb565501a294a779
`packet_sequencer_init()` initializes
`packet_sequencer_t` sequence to -1 always.
So make sure to set `uint16_t` later not to
an underflowing value, which can potentially
set the `uint16_t` object type to some insanely
big value.
Fixes:
/daemon/codec.c: 1893 in __handler_func_sequencer()
1887 if (!seq) {
1888 seq = g_slice_alloc0(sizeof(*seq));
1889 packet_sequencer_init(seq, (GDestroyNotify) __transcode_packet_free);
1890 g_hash_table_insert(ssrc_in_p->sequencers, mp->media_out, seq);
1891 }
1892
>>> CID 1616503: Integer handling issues (INTEGER_OVERFLOW)
>>> Expression "seq_ori", where "seq->seq" is known to be equal to -1, overflows the type of "seq_ori", which is type "uint16_t".
1893 uint16_t seq_ori = seq->seq;
1894 int seq_ret = packet_sequencer_insert(seq, &packet->p);
1895 if (seq_ret < 0) {
1896 // dupe
1897 int func_ret = 0;
1898 if (packet->dup_func)
** CID 1616502: (LOCK_EVASION)
/daemon/media_player.c: 487 in media_player_read_decoded_packet()
/daemon/media_player.c: 479 in media_player_read_decoded_packet()
Change-Id: Ifbd68021f17866aa9b7482b1bd42e2acf1c25dfa
Mark those SDPs which trigger processing
of music-on-hold.
Is defined by the config option:
`moh-attr-name`. If not defined then
is not used.
Will be useful for cases when it's important
for remote components to detect ongoing hold.
Change-Id: I0f2a284955dbc045b51920174f1f4fbefcb93907
Support inactive hold, because some
client implementations (such as Zoiper5)
are using `a=inactive` for their holds.
For us this means, either of this
puts the other side on hold:
- `sendonly: !MEDIA_ISSET(media, SEND) && MEDIA_ISSET(media, RECV)`
- `inactive: !MEDIA_ISSET(media, SEND) && !MEDIA_ISSET(media, RECV)`
Change-Id: I75562eee60220885e233fa965bf22da92850a8f4
Make the macro return the appropriate pointer type, and make sure the
free function takes an argument of the same type. This also eliminates
some boilerplate type-casting code.
Change-Id: I3094271fa2c53ec93b9ff9f837d461cf422e0f12
If with the sendonly SDP offer capable of MoH,
there is a flag `repeat-duration` coming at the
same time, then warn a user of rtpengine
that the configuration option is used with MoH
and it's not possible to take the flag's value.
Change-Id: Iacf3ddd85749da3ad98758e386952ab7cec5ca8d
Introduce `moh-max-repeats` configuration option,
which controls the `rtpe_config.moh_max_repeats`
used when initializing media player options
for the music-on-hold functionality.
By default is always set to 999,
if not defined otherwise.
Change-Id: I247dc532a6871934e44f9c4002313363356937fb
Make `moh-max-duration` available for both
music-on-hold functionality as well as
for the media player.
For that to work, do the following:
- keep `moh-max-duration` config option only for MoH,
if not set (so 0) by default is 1800000ms (half an hour)
- for the play media functionality introduce flag option
`repeat-duration`, by default is disabled
Policy changes:
- duration counter can be used in common with repeats
counter, but then takes a precedence over it.
Hence if first a duration is underflown, then EOF triggered.
Otherwise if the duration counter is still positive, but
repeats are negative, then do EOF based on repeats.
- the repeats counter will always count down during each
iteration, even when used together with the duration counter
For MoH to survive, the repeats counter is simple set to 999
to let the duration counter always win over repeats one
- MoH cannot take duration disabled, since otherwise
would make no sense for it. Hence always takes internally
defined value 1800000ms (half an hour) if not defined
by the configuration option
Backwards compatibility:
- is kept in regards of repeats counter
- is kept in regards of the play media functionality
Change-Id: I48ff3c17c9bed31f80c3106b275b703a9ccb4b26
Add a couple of tests for the following cases:
- use both zero-connection + mode sendrecv flags
at the same time
- answerer puts on hold (instead of offerer)
Change-Id: I5f849aa6b79a2e7e31512fbad9d2b82a6f5b0027
Sendrecv mode flag controls whether the sendrecv
state is forced to sendrecv, instead of the default
one sendonly, in the SDP body going towards recipient
(the one who will receive the MoH media).
Is declared as: moh=[mode=sendrecv]
Can be useful for corner cases, where the remote side
wants to see sendrecv state for whatever reason,
when getting MoH media and hence also remain in sendrecv
state in regards of the MoH originator.
Must be advertised once during the session origination,
nd then will affect the SDP body as soon as SDP sendonly
body is received (from the behalf of one, who advertised MoH
capabilities).
Backwards compatibility: doesn't affect non-MoH calls.
And doesn't affect offer/answer exchanges within MoH calls,
which do not put the remote side on hold.
Additionally: introduce a common function for the MoH flags
handling: `call_ml_moh_handle_flags()`, which does all
the required iterations/checks for the whole bunch of flags
at once.
Additionally: previously existing MoH tests adopted.
Additionally: new test introduced to check the SDP content,
when using mode sendrecv flag.
Remark: this flag is not mutually exclusive with
the zero-connection MoH flag.
Change-Id: I5bf6699f6890d8b927107cc143a18116efe45087
Zero-connection flag controls whether the connection
address offered in the SDP body going towards recipient
(the one who will receive the MoH media), is set
to all zeroes.
Is declared as: moh=[connection=zero]
Can be useful for older client implementations,
who want to see zeroed media when receiving sendonly
and getting put on hold.
Must be advertised once during the session origination,
and then will affect the SDP body as soon as SDP sendonly
body is received (from the behalf of one, who advertised MoH
capabilities).
SDP body recovers to the real IP addresses being inserted
into recipient's SDP, as soon as the media gets unheld.
Backwards compatibility: doesn't affect non-MoH calls.
And doesn't affect offer/answer exchanges within MoH calls,
which do not put the remote side on hold.
Additionally: previously existing MoH test adopted.
Additionally: new test introduced to check the SDP content,
when using zero-connection flag.
Change-Id: If0c38a3d294e6d5fe3886bee19ff2382e5705f9a
Move conditioning and handling of MoH
into a separate helper to make code a bit
more laconic.
No functional changes.
Change-Id: I89502bbdfe75e0b96c42ac0bde405e3ed04403fa
Add duration limit for the moh functionality.
This is required due to a possibility to get
monologues and hence packet streams stuck
forever and sending audio to recipients
which already don't exist.
A configuration option that controls that:
`moh-max-duration` - gets a value in milliseconds.
By default is set to 1800000 (half an hour).
Change-Id: Id50a0a10ce5b52b3876a3122fb16a71accec90ff
Introduced Music on Hold functionality:
- available only for the offer/answer model,
no other scenarios (publish, subscriber etc.)
are covered with it
- it gets advertised always at the beginning of
the call (original offer/answer exchange)
- can be added for both sides: offerer/answerer
- the one who advertises its MoH capabilities
with its SDP offer or answer, can later trigger
MoH using sendonly SDP and unhold remote
party using sendrecv SDP
- MoH covers only audio type of media sessions
- there is no specific selection of media sections
to be held, thus, if one audio media puts the
call on hold, the whole call is held
- list of parameters to be given when advertising
MoH capabilities: a sound source (file, blob or db source);
sendonly/sendrecv hold; zero-connection hold;
At least an audio file source must be given
- MoH cannot be mixed with the play media functionality,
the last one triggered will override previous one
- MoH must be unheld to stop the media being sent
towards a recipient, otherwise only a termination
of monologues will stop this packets stream
Change-Id: Iefd83ced79c14dadad936348a1d529007d6e7b3b
Richard Fuchs
Donat Zenichev