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
These tests are timing sensitive which makes them unstable under certain
conditions. Remove them from the automated build system.
closes#1309
Change-Id: I432445bce337bbf4d4b80417e532a910b516b8ee
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
Richard Fuchs
Donat Zenichev