Protect selected_sfd with in_lock.
Protect RTCP sending with in_lock and out_lock as appropriate.
Has the odd side effect of RTCP reports expected in tests to be sent one
packet later than before.
Closes#1966
Probably fixes#1927
Change-Id: I225b43dff8e8fbb938d3be6aad50249997615d77
If dummy definition with no tag, algo etc.
just ignore it, otherwise not excluded
and is dangling in outgoing SDP.
Also add according test.
Change-Id: Ib7c981ee66b1ce8cb363a9cc181231c68baa69cd
RFC says that annex B is the default in the absence of the annexb=no
format string. Consider the alias "G729a" as annex A.
Closes#1951
Change-Id: I9a8483ee5520bf4688601123f1ebec4f1f480642
With reuse-codecs, we still need to place the codec from the SDP into
our prefs list, even if it's already present, as the format options may
have changed. Update one affected test case.
Closes#1921
Change-Id: I688c57a8c45ec4c3bf159fe2193a0e00bbceeda2
This seems to be an acceptable and reliable way to detect RTCP
multiplexed with RTP, even if `a=rtcp-mux` wasn't advertised in the SDP.
Take the opportunity to clean up __streams_set_sinks() a bit by giving
the variables better names.
Change-Id: I0cdc5e4a544641591fc2aabca12fb11bab3453f7
Use the correct media object (the source media) to obtain media-level i=
lines from. Adapt OSRTP output function to do the same.
Change-Id: I9ba4db286cf9d822b8986a7da2cb4f4aa1c69646
Support the recvfrom() function. This requires also returning to address
(not just the port) from the tester's rcv() function to be useful, which
in turn requires updating a bunch of tests.
Change-Id: I3c0bcab9b744f2c234662399199abc538876c4fa
The codec `strip` option used to remove codecs not only from the
destination (offer to) monologue, but also from the source (offered by)
monologue. Change this to only affect codecs on the destination
(offering to) side. This fixes a problem of not being able to have
different `strip` options set for different branches.
As a side effect, this breaks existing use cases of using `strip` to
ignore codecs on the source monologue side. This functionality is
restored by adding `codec-ignore` in the following commit.
Change-Id: I022748fffc29caa3a8c96f514b2021f152e43686
Add a couple of tests for the following cases:
- use both zero-connection + mode sendrecv flags
at the same time
- answerer puts on hold (instead of offerer)
Change-Id: I5f849aa6b79a2e7e31512fbad9d2b82a6f5b0027
Sendrecv mode flag controls whether the sendrecv
state is forced to sendrecv, instead of the default
one sendonly, in the SDP body going towards recipient
(the one who will receive the MoH media).
Is declared as: moh=[mode=sendrecv]
Can be useful for corner cases, where the remote side
wants to see sendrecv state for whatever reason,
when getting MoH media and hence also remain in sendrecv
state in regards of the MoH originator.
Must be advertised once during the session origination,
nd then will affect the SDP body as soon as SDP sendonly
body is received (from the behalf of one, who advertised MoH
capabilities).
Backwards compatibility: doesn't affect non-MoH calls.
And doesn't affect offer/answer exchanges within MoH calls,
which do not put the remote side on hold.
Additionally: introduce a common function for the MoH flags
handling: `call_ml_moh_handle_flags()`, which does all
the required iterations/checks for the whole bunch of flags
at once.
Additionally: previously existing MoH tests adopted.
Additionally: new test introduced to check the SDP content,
when using mode sendrecv flag.
Remark: this flag is not mutually exclusive with
the zero-connection MoH flag.
Change-Id: I5bf6699f6890d8b927107cc143a18116efe45087
Richard Fuchs
Donat Zenichev