This is a new option flag, which provides the ordered list,
in which to add crypto suites into the SDP body.
Right now they're always added in the order given in the source code.
Flag usage example:
`SDES-order:AES_256_CM_HMAC_SHA;AES_256_CM_HMAC_SHA1_32;AES_192_CM_HMAC_SHA1_80;`
This means — those listed SDES crypto suites will be added
into the generated SDP body at the top of crypto suites list, in the given order.
But, each of them is added, only if it is about to be added/generated.
In other words, the `SDES-order:` flag itself doesn't add crypto suites,
it just affects the order of those suites to be added.
And the rest of non-mentioned suites, which are also to be added,
will be appended after those given, in the free manner of ordering.
Important thing to remember - it doesn't change the crypto suite tag
for the recipient, even though changing the order of them.
Additionally.
This flag does not contradict with `SDES-nonew`, `SDES-only-` and `SDES-no-` flags.
It just orders the list of crypto suites already prepared to be sent out.
Change-Id: I0fec54f9e2f3cd4913e905e8afe825712f82d1ae
A new function dedicated to SDES crypto suites comparison.
It compares the crypto suites using a name in 'str' format.
Recommended to be used in combination with:
g_queue_find_custom() or g_list_find_custom()
Change-Id: I08ff6d3304f74d29154110caa472618478ca1837
New helper func: call_ng_flags_str_q_multi()
It parses given flags delimited by a separator, and stores
each of them in the given GQueue.
By default delimiter is assumed as: ';'.
Change-Id: I1e29bf3d852868e2bc4d98b1775f70b38f61054a
This type is used as const everywhere except internally, so make it part
of the typedef for brevity.
Change-Id: Ic4afe037b392239a991d5380c6708903011da29e
A new function dedicated to SDES crypto suites policy checks
has been introduced: 'crypto_params_sdes_check_limitations()'.
Use it to decrease an amount of repeating code blocks
related to SDES checks.
Change-Id: I0ac242a63107a9f3a41f95a57e3d3675645ac18d
Add a new flag to only accept these individual crypto suites
and none of the others.
For example, `SDES-only-NULL_HMAC_SHA1_32`
would only accept the crypto suite `NULL_HMAC_SHA1_32` for
the offer being generated.
This also takes precedence over the `SDES-no-` flag(s),
if used together, so the `SDES-no` will be not taken into account.
This has two effects:
- if a given crypto suite was present in a received offer,
it will be kept, so will be present in the outgoing offer; and
- if a given crypto suite was not present in the received offer,
it will be added to it. The rest, which is not mentioned,
will be dropped/not added.
Flag name: 'SDES-only-<crypto name>'
Additionally: add another new flag 'SDES-nonew'.
It will not add any new crypto suites into the offer.
It takes precedence over the `SDES-no` and `SDES-only` flags,
if used in combination.
Change-Id: Ic4fa03957ee3d4d24b0c4f3fd003eada05f49b0b
1) Read dtxb->start while the lock is held (not strictly necessary as
the read should be atomic anyway)
2) Expect that dtxb->start can be larger than rtpe_now.tv
The latter can happen as `rtpe_now` in a timer thread is faked to be
exactly the time when the timer was supposed to run, and not the actual
current time, which means that a newly added packet can have a later
time stamp than the "now" the timer thread is using.
Change-Id: I48fd7f78af97c6d5b802e5151d69855a90f4032d
Instead of going through ffmpeg to en/decode Opus, use libopus directly,
which allows us to benefit from additional features that aren't
available when going through ffmpeg.
Change-Id: I017c276cfa9755cefe95c8da26691446b718d4c8
Some codecs (e.g. Opus) can natively encode audio with various clock
rates without producing an output that is locked to that clock rate and
without requiring resampling the input. Add an appropriate callback
function and adapt tests.
Change-Id: Id788c4d4c05e20f93cce7e910f9f265b381cbe34
This makes it possible to have codecs running at variable clock rates
that differ from their RTP clock rates.
Change-Id: Ia2f5effb82eefe8c3028573ba0a6697da28473b1
Instead of just having an integer multiplier, support a fractional
factor. This allows us to have the RTP clock rate run faster than the
audio clock rate, and not just slower by an integer factor.
Change-Id: I7681cf369c43d8424ca2d2ebeffe932595d271ec
Unmark a monologue that has been scheduled for deletion when it's
associated with another one, which happens during offer/answer.
Fixes a regression from 53dbef7e1 which removed this logic from
__monologue_unkernelize with re-adding it elsewhere.
Change-Id: I037162e91fec42631680f7767f58b172fd6e04db
Add a flag to force increasing the SDP version,
even if the SDP hasn't been changed.
And cover it with tests.
Flag name: 'force-increment-sdp-ver'
Additionally fix the name of the 'sdp-version' flag
in the 'rtpengine-ng-client' tool.
Change-Id: I466792668b0cd313b5e21b248dd14cd599333cbd
`call_get_monologue_new` is supposed to always return a full dialogue,
but an error in invocation (using a from-tag that doesn't belong to an
offer/answer) can lead to the second half being unset. Return an error
in this case.
Change-Id: I84b21ff5e5c0403fc07cae83fee206705ecff8b3
Use the new `associated_tags` table to determine which tags are
associated with which. Iterate the associations between tags in a
tree-like manner and do this at the moment the `delete` command is
received. Break up the `associated_tags` links at this time, and
determine which tags would be left dangling and mark all of these for
deletion. If no tags are left after this process, mark the entire call
for deletion.
The previous approach was cumbersome and prone to errors. Using tag
names and branch names to determine which tags are associated with which
is a pointless hurdle, and using a table of associations that is
explicitly kept for this purpose is a much cleaner approach. Also
postponing the decision about which tags to delete until the time the
deletion actually happens can lead to tags not being deleted, when they
really should be (e.g. A -> B, delete A, A -> C).
Change-Id: I03ae57d0a2117ecd721372c1a49468fc34dd630c
Keep track which tags (monologues) were created together as part of an
offer/answer exchange with a separate hash table, regardless of whether
these monologues actually have tagged names or are just nameless
branches.
Change-Id: I60aa114c8caf6ecdff4705e3399f60190d04dda6
During offer/answer, we remove existing subscriptions before
re-establishing the new set of subscriptions. But we must also remove
the subscriptions of previous subscribers in order to keep the lists of
subscriptions and subscribers correctly reciprocal.
Change-Id: I7d39fa59892159f41033ae6a40e7cb51d861b12e
Reset the iteration counter for the frequency list when codec handlers
are set up, which happens while setting a new block mode. This makes
sure that a newly set list of frequencies is iterated starting from the
top.
Change-Id: I7ab4e28a1a998c11e38e26cf5b1f17f01299d5ad
Support multiple tone frequencies for DTMF-security=tone to enable
audibly distinguishing multiple consecutive DTMF events from one
another.
Change-Id: I6fa33a5768aae198220d0b0cc4c53308c5661a52
The `dtmf_send` event might not have a matching entry while handling a
received DTMF event. Move bookkeeping of the random output event into
`dtmf_recv`.
Change-Id: I5507b0b7f5eca6e29cbcaccc905ab25249b22aa3
Usually supplemental RTP types (DTMF) are listed after the primary audio
codecs. In the case of the order being reversed, fix `single-codec` so
that it doesn't strip the actual audio codec that is listed after the
DTMF type.
Change-Id: I1b03b89e31bebf4de303b643dcf08d2ffb90ebaf
In some cases it's possible that some packets still arrive in userspace
immediately after a stream has been pushed to the kernel, for example if
some packets are already in the queue or if there is some processing
delay (e.g. writing to Redis). Allow for a short delay before counting a
stream as userspace if it has been pushed to the kernel.
Change-Id: I55a6e255868c8c2a9e93355a4aa2287f07b3748d
Based on the information gotten from Richard Fuchs
document the main objects in the code, to let the code be more
understandable for other code readers.
Mainly documented:
- call
- call_monologue
- call_subscription
- call_media
- packet_stream
- stream_fd
- sink_handler
- rtpe_callhash / rtpe_callhash_lock
Change-Id: I0cf122bea2d9c3f198b48da134a70301564ff1f9
On bookworm and later, libasan reports a false positive in combination
with pthread_cleanup_push() (see [1]). Work around this by not using the
thread cleanup handler when running the asan build, and instead use a
shorter thread sleep time.
[1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=82109
Change-Id: Ieffdc0b13f470445f1f8e1d2448c6af6d8dd68e0
Only skip forwarding unknown payload types in the kernel module if
there's reason to skip them, i.e. when we know that certain payload
types must be handled in userspace. Use an explicit flag to signal this
to the kernel module instead of implicitly doing it for anything that is
RTP.
Change-Id: I655317afe64a27252bf7b8be6c78418db2e1ccef
Legacy UDP/TCP control protocols don't provide information about RTP
payload types, therefore don't pretend that we know that this is RTP.
Setting the RTP flag without knowing the payload types has the undesired
side effect that unknown payload types (all of them) would not be
handled by the kernel module.
Change-Id: I5882f777a5912b912ec7c870f21c77aac8127600
Instead of just leaving the transport protocol unset when we know we're
not supposed to be aware of the protocol, add a special entry to
suppress the pointless warning message.
Change-Id: I228c2f1652320627f974d9d7bcb0b1345adce2be
Similar to I7fd298669a4fd69e62edc4760ffd92eff074707b but for
codec-accept. This prefers accepting codecs that match the given
definiton exactly, but also accepts compatible codecs if no exact match
is found.
Change-Id: I52a2ab6e75f7334a85a8ef059a0d6703a07e4b7f
Legacy protocols don't set sp->num_ports. Use a sensible default for
this case.
Probably a regression from 2d2d7665b
Change-Id: Idcbc477a68b6db70a91a5d082736ac642c50ab15
When adding codecs to the SDP for potential transcoding, use more
sophisticated logic to determine whether the desired codec is already
present. Previously only the raw RTP payload string was used, which
doesn't take codec-specific format options into account. The new
matching function will now also match against existing codecs with
slightly different but compatible a=fmtp options, but will not match
against those with incompatible options.
Change-Id: I7fd298669a4fd69e62edc4760ffd92eff074707b
Convenience function to get a list of all codecs that match a given
definition, including a possible exact match.
Change-Id: I2b7d49fb320ad1725b348f7d29be450e5fea925b
Make these functions return the newly created payload type object so
that it can be manipulated directly without having to do a lookup.
Change-Id: Ib035cf7d61c61d0de6d5f87dfd497d17ba28ca5f
Parse out the format parameters for a payload type object when the codec
definition is loaded. Parsing it out is done only once, and if done
early the parsed contents can be used for format checking, comparing,
matching, etc.
Change-Id: I2856e5a8d4d76e7e1e648eff4a91fc51d0ba20c2
Split up this function into two parts so that they can be used
individually. Eliminate the special 0x1 return value as this isn't used
anywhere else. Move the error reporting into
codec_make_payload_type_sup() where it belongs.
Change-Id: Id2060272d87596a3db32d8776930a98b0f226b3b
Introduce an additional function for codec matching. Different functions
match different parts of an RTP payload type object and the referenced
codecs.
Change-Id: I2e488eaa7f69a55322db748fd40c8d1195e38605
We have no use for -1/0/1 return values. Change the return type to bool
to make things more clear.
Change-Id: Iedf1d8278c6dfddddb328ce7b3b1dbae132a39b7
Donat Zenichev
Richard Fuchs
Damir Nedžibović