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
Richard Fuchs
Stefan Mititelu
Guillem Jover
balajeesv
Stefan Mititelu