There's two flavours of this struct being in use, even though the
structs' signatures are the same. One contains socket_t objects, the
other contains stream_fd objects. Separate them out and be explicit
about which is which.
Change-Id: I5ef1d154cc442528149f69be2e6a02625a6c650d
Simple wrappers around glib's GHashTable functions that add type
information, instead of just using void* for everything.
Change-Id: I3e7c0f095f1f58b943ba80d1e14e763707ee1698
Stop handling redundant media subscribing in the:
- `call_get_monologue_new()`
- `call_get_dialogue()`
and leave this work only for the offer/answer model:
- `monologue_offer_answer()`
In the meanwhile the subscribe request/answer model
keeps on using directly the:
- `__add_media_subscription()`
Change-Id: I6cfaef634b8b9e5e805df25f1c6f80225648b75a
The rtpengine GitHub issue tracker is not a support forum,
so let's point user to the mailing list instead, and provide
initial bug report + feature request templates, while at it.
Change-Id: I7414b94131def5f19cdc5cc17d41684007b12bf2
Allow codec_tracker_update to reference an existing codec_store. Then
when a supplemental codec type needs to be generated, make it look up
the type in the existing codec_store and re-use the existing payload
type if present instead of creating a new one. This allows payload type
numbers to remain unchanged during a re-invite.
Change-Id: I9e5edd897515a5e3eb5033aa6bbf21c8667d6133
During an offer, we update the codecs from the given list not only on
the side of the offerer, but also on the answerer's side, in order to
perform the codec answer routine during the answer phase. While doing
this, we empty out the existing list of codecs (on both sides) and
repopulate it fresh from the given list.
This can cause problems during a reverse re-invite, when the list of
codecs on the answerer's side already contained the codecs that had been
offered before. When setting up the new re-invite offer, we want to
retain codecs (and their payload types and format parameters) that were
already in place, instead of recreating a new list from scratch.
Improve this by adding a `merge_cs` option to the populating functions,
which points back to the stream_params codec_store. Codecs that would
have been removed from the codec_store during the repopulation are then
moved back into the stream_params codec_store instead. This then allows
the functions adding new codecs to the list (offer/transcode) to
reference these codecs that were previously in place, and so they can be
added back with the same options as they had existed before, instead of
recreating them from scratch.
Change-Id: I53e7ab10e9144a308a5c36be5ebfddd73c212f06