For source files generated from the "strhash" helper script, output line
and file number information into the generated .c source to help gdb and
other tools correspond the compiled code with the correct source code.
Change-Id: Ieddc86ab59b41ab26942e8a7d3c24e7800e9936f
The option flags used when calling the rtpengine_offer()
have been re-ordered in the ascent manner according to alphabet.
Additionally three sub-sections have been created, to make
the sorting of flags simpler:
- Optionally included flags
- Optionally included replace-flags
- Optionally included codec manipulations
All subsection are also ordered inside.
Change-Id: I67663827eb710564f0314d1f6919d428206e1cef
Don't wait forever for a response from the daemon. Prevents tests
getting stuck in case of broken code.
Change-Id: I83dde4c2d626928fdfb0486e7fb4780e239c83e9
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
We're already determining the destination media section in
media_player_play_init() (looking for audio media), so it makes sense to
determine the payload type there as well.
Change-Id: I33d4a15005c2146864f74663fe8de2893454345b
Split out the logic to determine the destination payload type into a
separate functions. This makes it possible to supply a different, or
pre-determined, payload type instead.
Change-Id: I9b67b29cafc0c6ce4e18eede64dea3d1973f8b63
It makes more sense to set up the codec handler from the init function
rather than from the function reading the media packet.
Change-Id: I0bea3d0fc0669a54f93b2598251df69274950365
If the expected buffer to hold a packet was determined incorrectly, log
a warning instead of throwing an assertion.
closes#1591
Change-Id: I4169378a27b27fed51e453e6d2da8014259c659e
Prevent a wrongly advertised (too small) a=ptime from producing too
small buffers to hold encoded packets by flagging codecs with a fixed or
minimum frame size as such.
This is relevant to libavcodec only as the code determines the expected
frame size from the clock rate and the ptime.
closes#1591
Change-Id: I9f5c56d45f2aad56951b19d846ddbfa4b7bd7e7d
Provide the targets for the two /bin/ components.
Adapt .install debhelper files.
Adapt iptables module install location to use the environment variable.
Change-Id: I963feba5f60f53773e497121d8947e7b4997d687
… if it does not exist. Likewise in iptables-extension/Makefile .
daemon/rtpengine.pod: spell what MOS means
MAX_SESSIONS in config file does not work, it must be max-sessions.
https://github.com/sipwise/rtpengine/pull/1589
Older versions of glib handle the trailing padding in base64
differently, resulting in the final character of the encoded string
coming out different.
Change-Id: I2bc1057de15f5e0bddb3de4df6cef7c4fcf7ebcc
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
We have to cover more cases with tests, such as:
- SDES re-ordered crypto suites, but one suite from the 'SDES-order:'
flag was not in the offer
- SDES re-ordered crypto suites, but one suite from the 'SDES-order:'
flag was not in the offer and the recipient selected it
Change-Id: I1051c01d45c4b494f768692f85d1e0c41a0ea2d2
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
Richard Fuchs
Donat Zenichev
Lasse Bang Mikkelsen
Stefan Mititelu
Sipwise Jenkins Builder
Дилян Палаузов
Denial