Defined in RFC 8842. If a tls-id was previously given and a the new SDP
shows a different tls-id or none at all, we must restart DTLS.
Relevant to #1585
Change-Id: I554234dfcacbd330c7a0c6aea68f24d0449cba21
Perform accumulation of stats only once (i.e. increasing an actual
counter) and report stats based on differences to previous values,
instead of carrying multiple stats counters for each metric and
resetting each counter to zero whenever stats are reported.
`rtpe_stats` is the global master accumulator.
`_intv` variables are intermediate and local storage for values sampled
from `rtpe_stats` at regular intervals.
`_rate` and `_diff` variables hold stats calculated from `rtpe_stats`
and the respective `_intv` variable whenever the sampling and reporting
occurs.
`stats_counters_calc_diff` is used to calculate stats as differences
between `rtpe_stats` and the last sampled `_intv`
`stats_counters_calc_rate` does the same but calculates a per-second
rate, based on a microsecond duration.
Eliminate now-useless struct global_stats_ax
Change-Id: Ic4ca630161787025219b67e49b41995204d60573
... so that the publishing session gets notified about "webrtcup" and
not the session which created the room.
Change-Id: If7b308df4afa7afb19ecaca1f743f87c3c736007
This is a new option flag, which provides a possiblity
to select specific crypto suite(s) for the offerer from
the given list of crypto suites received in the offer.
This will be used later on, when processing an answer from
the recipient and generating an answer to be sent out towards offerer.
Furthermore, this is being decided not when the answer is processed,
but already when the offer is processed.
Flag usage example:
`SDES-offerer_pref:AES_256_CM_HMAC_SHA;AES_256_CM_HMAC_SHA1_32;`
Change-Id: I2b22b38347d24f27331482e18b92305fbadb2520
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
Support multiple tone frequencies for DTMF-security=tone to enable
audibly distinguishing multiple consecutive DTMF events from one
another.
Change-Id: I6fa33a5768aae198220d0b0cc4c53308c5661a52
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
Create a dedicated struct to hold certain attributes shared by both sink
handlers and media subscriptions, as a preparation to simplify handling
these attributs.
Change-Id: I866159c33ed6d6a2873d2cf68c4906ea705d253e
This makes it possible to refactor and simplify the interface functions,
as pointers and offsets can't be utilised with bit fields.
Change-Id: I70f1ac0eca7d2ccf8e8d5f5794580163f3f5b7ad
Keep a running lifetime total of all "gauge" type metrics. Also track
the square of the sums of all "gauge" type metrics in order to determine
the standard deviation.
Change-Id: I23f60774a6421636f1a913674c7d1b54a1c5f702
With multiple media subscriptions, codec handlers are called
consecutively, once for each forwarding chain, leading to DTMF events
reported multiple times. The DTMF trigger must therefore keep track of
the state in the upper media object, not in the codec handlers.
Change-Id: I9ceaf406e093f25b7c037a325a0f2a7a91954922
This makes it possible to add new streams without specifying the
direction/interface again.
Reported in #1366
Change-Id: I8f320ecbe72f123d755ba80370de9c40960eb0f0
The contents of the ->next element cannot be accessed completely lock
free as they're zeroed out during call removal. Instead grab a reference
to the linked next call before releasing the lock, and also lock the
next element before moving on. This requires a more granular locking as
not to interfere with call removal: One lock to protect the contained
call and the ->next, and another to protect the ->prev
Change-Id: I5474ea3f88e3276f93ba62a952b3be13c0c182e9
This fixes a race condition: Peer sends updated SDP with new address,
but an older RTP packet from the old address is received afterwards.
Thsi triggers learning of this old address is the "correct" endpoint.
Afterwards the peer stops sending RTP until a packet to the new endpoint
is received there, which never happens because the new endpoint has been
discarded in favour of the "learned" old one.
closes#817
Change-Id: I508f465a669f03e35ddcc6e770d5e7859e57569f
Complete overhaul of the codec handling code:
*) obsolete flags `asymmetric codecs`, `symmetric codecs`, `reorder
codecs`
*) support proper codec offer/answer
*) split codec manipulation (strip/offer/accept/etc) into separate
functions for clarity and better code maintenance
*) fully update codec handlers in both directions after an answer
*) explicit allocation and handling of codecs and payload types in a
codec_store object
*) improve codec matchup logic during answer
*) more explicit handling of supplemental codecs (CN/DTMF)
*) remove now obsolete hacks for handling certain use cases
Change-Id: I996705ba8fe339524c2f70e6bb0fd854f9a1f4fb
This solves problems when the same SSRC is looped through the same call
multiple times in different mono/dialogues, with different parameters.
Change-Id: I1d033cb1f012574d82b5bcbfffe11eb5f983cfd8
If we receive an SDP with a DTLS fingerprint, by default we adopt the
hash function used for that fingerprint in subsequent communication with
that peer. However, if the SDP is an answer, and we previously used a
different hash function in the offer towards that peer, then a later
re-invite offer would be sent with a different fingerprint, causing an
unexpected DTLS restart. Instead, make sure we don't change fingerprints
if one was already sent.
Change-Id: I603bb86ce2d7121556c161749ed08128dd0b63b2
Whether a bit-field is signed or unsigned is implementation specific, so
we should be explicit about this.
Change-Id: I744df3d24bc08e95fa816ba4135f19cd3a5dcb17
Warned-by: lgtm
The previous approach causes problems during re-invites with updated
port (or address) information. The UA might delay actually using the new
endpoint until after the answer is seen, in which case rtpengine would
erroneously immediately latch on to the old endpoint. We need to
reinstate the endpoint learning delay in all cases, and make sure
previously learned endpoints are forgotten whenever a new signal is
seen.
Change-Id: If42ed13c43710616c02cdf018b36a4543d7f6bfe
Initially created branches don't have a tag associated with them, so
they don't appear in `other_tags`. We need to keep track of which
branches were created from a single from-tag through their via-branch
values so we know when all branches have been deleted.
closes#1037
Change-Id: I4c6ce602b99a9104de98098cd06ca399eb28e1b2
Useful when someone needs to:
- completely drop early media, but stop dropping after call is answered.
- completely drop initial invite media, but stop dropping after re-invite
The hash table cannot be used for storage any more as entries can be
removed on demand (64e56d7) but can be cached in packet->handler at the
same time.
Possibly fixes#915
Change-Id: Ic74703b1a57294bfd704b6cddcd666d6063f510a
Adds a new option ptime-reverse to complement setting of ptime towards
the offerer. This and ptime setting are now ignored in answers.
Change-Id: Icbc04f191cbc194b75b72a97832fcaba58feb10e
We should offer all crypto suites that we support. If passing through
SDES, we should amend the list of crypto suites with all additional ones
that we support that weren't included in the received offer.
closes#577
Change-Id: I9b6c16e8eadecf01cdbc8043bd8361e0f683e456
Richard Fuchs
Donat Zenichev
John Burke
Stefan Mititelu
Guillem Jover
balajeesv
Stefan Mititelu