The test number 1142:
"SDP attr manipulations - add a= line for media audio, two times"
used to fail on the buster builds, because of the hash tables
implementation we had in the `command_values` of the `struct sdp_command`.
It didn't necessarily keep the same order, as was used to add values.
Now as the SDP manipulations structures is re-designed, we can re-add it.
Change-Id: Icc7d030894d45c9d62e91669915eafb348d05d97
The test number 1142:
"SDP attr manipulations - add a= line for media audio, two times"
fails on the buster builds, because of the hash tables implementation
used in the `command_values` of the `struct sdp_command`.
It doesn't necessarily keep the same order, as was used to add values.
Temporarily removing it, until the `struct sdp_command` is re-designed.
Change-Id: I077771c00c5dc8907e42d7757540e3ffa2063af6
Don't change to a new port for sendonly streams as this causes problems
with NAT. A device receiving a sendonly SDP with a new port won't send
any RTP to the new port, leading to a closed (non existent) NAT mapping.
Change-Id: I2ea2163eb9f1203226bd781b53f421c790a86f0a
New section of option flags has been introduced for SDP body
attributes manipulations.
Three levels of the SDP session are concerned:
- session level (global one)
- media level - audio
- media level - video
Three different actions are supported for now:
- add
- remove
The value of the command has a wildcard matching approach.
Other attributes apart `a=` can not be edited by this functionality.
So such headers as: `c=`, `s=`, `o=` cannot be touched.
Change-Id: I939d4582839096b2399f7ded865e91ff6eb960a4
(cherry picked from commit 3f06c18793)
Only parse out a codec type if the codec is given with any parameters
set (and not just by name). Parsing out a codec type when just its name
is given leads to a codec type with default parameters set (such as the
number of channels) which can lead to a stricter matching than desired.
When a codec is given just by name we want to match all codecs of that
type, not just the ones with the same parameters as the default ones.
Change-Id: I583bf4045dbd55291d8dc596310730024853d386
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
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
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
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
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
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
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
The order between receiving the STUN success and the triggered check is
not guaranteed, therefore resolve possible race condition by expecting
the two packets in either order.
Change-Id: Ibef9907cd4116bc5f3b7d17d936007c8efcabd3b
The codec answer routine resets the codec storage and so also resets the
clock rate tracker for "touched" codecs. This leads to all codecs seen
as "not touched" in the answer routine, which in turn leads to
supplemental codecs present in the answer SDP that should not be there.
Use the "for transcoding" flag for previously present codecs to retain
the "touched" status across the codec answer routine.
Change-Id: Idc4624606f7f10d7983e22ddf856432b07421157
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
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
Explicitly copy SDP up to the format list before printing it out. This
preserves broken input SDP.
closes#1461
Change-Id: I839a200f159f25854c86add244571a948e2c90cf
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
Supplemental codecs such as DTMF use static timestamps while the event
is ongoing, leading to a TS jump when the RTP flow changes back to
audio. The sequencer needs to be aware of this so it doesn't mistakenly
see the next audio packet as overdue and starts to process it
prematurely.
Change-Id: I2faea9aceec21fc04920f6c3c94141725383379f
Richard Fuchs
Donat Zenichev