... 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
1872 /* first add those mentioned in the order list,
1873 * but only, if they were previously generated/added to the sdes_out */
>>> CID 1530346: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "NULL" inside this statement: "l = (cpq_order ? cpq_order-...".
1874 for (GList *l = cpq_order ? cpq_order->head : NULL; l; l = l->next)
Change-Id: I58f84ba82d215a9eb6cbd97548e8e9e8a954bdc6
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 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
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
`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
Support multiple tone frequencies for DTMF-security=tone to enable
audibly distinguishing multiple consecutive DTMF events from one
another.
Change-Id: I6fa33a5768aae198220d0b0cc4c53308c5661a52
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
Legacy protocols don't set sp->num_ports. Use a sensible default for
this case.
Probably a regression from 2d2d7665b
Change-Id: Idcbc477a68b6db70a91a5d082736ac642c50ab15
This makes it possible to have different media silencing options for
different outputs. Functionally this commit alone is a no-op.
Change-Id: I967c3e07ea4645bb49ccb76db12d51ded2d72f06
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
If an offer is going to a side that is already known to support
rtcp-mux, don't try to offer a fallback RTCP port. Do this by pretending
that rtcp-mux=require is set, which leads to the correct behaviour. This
is needed because the RTCP fallback port might already be closed, so
trying to include it in the offer would require opening a new set of
ports, which is undesirable.
closes#1494
Change-Id: I550bec08379c799cb7dd090a70d090ae47462467
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
When doing the initial answer, the packet_stream endpoint port isn't
filled in yet. Use the stream_params port instead to test for rejected
streams.
closes#1499
Change-Id: I8f315d95521f874fb8c5e6222263d017800b5fc9
When ports are closed early (while the call is still running), we must
first update a slave rtpengine with this new information (that these
ports are now closed) before actually releasing the ports ourselves. Not
doing so leads to a race condition where the master instance re-uses a
port that was just closed before the slave instance knows about the port
being closed.
We implement this using a thread-local list to keep track of ports that
were released while processing a control message, and process this list
to actually close the ports only after Redis has been updated.
Additional calls to the function to close the ports are placed in
strategic locations to make sure this is triggered in every code path.
closes#1495
Change-Id: I803f4594f30ca315da0b84c6e76893f54ca3a7c9
This eliminates a spurious false warning log message for rejected
streams that use a dummy payload type
Change-Id: Id628cafb8d7c4ea576cd01ff35f5dd9cd2151280
Since we're creating a dummy sfd to hold the SRTCP context when we don't
have an actual RTCP port, we must make sure to remember and re-use this
dummy sfd during a re-invite. Otherwise we end up creating a duplicate
dummy sfd, which is detected as a different sfd and thus triggers an ICE
restart.
Change-Id: Iadc91e163bd15a3cd5f57656b52941724c920143
There's no need to open ports on non-primary interfaces if ICE is not in
use as these ports will not be used or seen by anyone.
This mostly obsoletes the `save-interface-ports` config option, with the
exception of ICE advertised by the offerer. We currently have no option
to reject ICE from the offerer during the offer phase, so ports would
always be opened on that side.
Relevant to #1164 and 001abe5
Change-Id: I43df70bc0ec49b81f63aec97c776e48617b2acfd
This enables the same behaviour towards the offerer when rtcp-mux=demux
or =accept is used, as we have towards the answerer when
rtcp-mux=require is used.
Change-Id: I56a1cea84efce0c2db1b58c500629d0e54d582f4
Special handling for codec lists that were received as part of an
answer: If the list includes a codec that was not offered, ignore that
codec. This prevents transcoders from being set up that were not
requested.
This brought to light some tests that were actually broken.
Change-Id: Iac71056ec5e10b5de5567917974f2c4e0261eb0c
Richard Fuchs
Donat Zenichev