With selected_sfd being protected by in_lock, we pretty much have to
hold at least in_lock everywhere, and end up requiring both locks in
many places. The distinction has become pointless.
Change-Id: Ic0ad976c2d68d9639b9434da7f0e6e9c0d84c185
Simply take the xmlrpc-callback address as string and don't try to parse
it out. Store it in the call object as string as well.
Obsolete `created_from_addr`. The string form `created_from` is all we
need.
Change `created_from` to `str` as well.
Change-Id: Ib67b57b1d2d474d7b033f56ef8be59f71e44641b
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
A simple mechanism to track whether a given media endpoint has been
advertised to the public. If it hasn't, then any media received on it is
considered suspicious, and source addresses are ignored for learning
purposes.
Change-Id: I76a08e3f442f263dad192ff496a5d734a9349d26
Special codec handler to support not forwarding (nor any processing
whatsoever) of particular payload types at all. Support this in the
kernel module as well.
Change-Id: If10227affa54307e1e9b448eadd0bf2bfc5774ba
Instead of explicitly triggering an update of subscribers for A and B
during an offer/answer, trigger it only for one side (A) and then
iterate through all subscribers and subsriptions and update them all.
This automatically triggers an update for B, as well as any other
existing subscriptions that might be affected. Use a monotonically
increading update iterator counter to track which medias have been
updated so we don't run into infinite recursion.
Change-Id: Ie2fba8ff9c5a011bbe932559ac06e1634029a091
0x40000000 was already used by SHARED_FLAG_END_OF_CANDIDATES. Move
MEDIA_FLAG_REORDER_FORCED to unused slot 0x00800000 instead.
Change-Id: I0aa33854f814757869c7a98ba209d9aeb94d3d91
Directly return the just-created subscription from the respective
function. Saves a hash table lookup.
Change-Id: I42d9c75ebae2cc92619e78badb8ac594397b614b
We know whether we're printing for monologues or for medias, so there's
no need to have a generic function signature.
Change-Id: I356747686adb34c19ba2ba4c77c2d0a77b85a364
When MoH is triggered with `sendrecv` flag (so that
the recipient, the one who is put on hold, sees
the sendrecv state instead of sendonly/inactive),
we have to correctly process the answer coming back
to the MoH originator.
The originator of MoH must see:
- recvonly to his sendonly
- inactive to his inactive
Hence OA model is kept correct for the originator's leg.
Additionally: accordingly correct MoH tests.
Change-Id: Ida5f074d302c419c1e57e4fd624a55bfddae5587
A call that gets created but then doesn't get initialised would have its
Redis DB left at zero. At destruction it would then try to switch to DB
zero. Fix this by using an appropriate initial value.
Closes#1905
Change-Id: I852e48c5a06b732b37d2ccd5c478de4760aacd4e
Introduce global generic memory arena variable, instead of having just
a call-specific memory arena. This makes it possible to use memory arena
outside of call contexts. Define previous call-specific functions in
terms of the generic ones.
Change-Id: Icde4f63f02dacbf8abfbaf107ea8b5bbe18d5eb8
Support inactive hold, because some
client implementations (such as Zoiper5)
are using `a=inactive` for their holds.
For us this means, either of this
puts the other side on hold:
- `sendonly: !MEDIA_ISSET(media, SEND) && MEDIA_ISSET(media, RECV)`
- `inactive: !MEDIA_ISSET(media, SEND) && !MEDIA_ISSET(media, RECV)`
Change-Id: I75562eee60220885e233fa965bf22da92850a8f4
Introduced Music on Hold functionality:
- available only for the offer/answer model,
no other scenarios (publish, subscriber etc.)
are covered with it
- it gets advertised always at the beginning of
the call (original offer/answer exchange)
- can be added for both sides: offerer/answerer
- the one who advertises its MoH capabilities
with its SDP offer or answer, can later trigger
MoH using sendonly SDP and unhold remote
party using sendrecv SDP
- MoH covers only audio type of media sessions
- there is no specific selection of media sections
to be held, thus, if one audio media puts the
call on hold, the whole call is held
- list of parameters to be given when advertising
MoH capabilities: a sound source (file, blob or db source);
sendonly/sendrecv hold; zero-connection hold;
At least an audio file source must be given
- MoH cannot be mixed with the play media functionality,
the last one triggered will override previous one
- MoH must be unheld to stop the media being sent
towards a recipient, otherwise only a termination
of monologues will stop this packets stream
Change-Id: Iefd83ced79c14dadad936348a1d529007d6e7b3b
This function connects two call legs (two monologues), possibly from
different call IDs, into a single media flow. It pays attention to media
types and automatically engages transcoding if needed. The order of
media sections of different types can be differend between the call legs
that are being connected. Subsequent reinvites will produce SDPs with
the media sections in the correct order.
Change-Id: I40c3363997de169edc553733d52acdfd9f0181ad
This function retrieves two calls from the global call hash while
avoiding deadlocks. This is needed because a "call_get(A) + call_get(B)"
would deadlock against a concurrent "call_get(B) + call_get(A)"
Unused at this point.
Change-Id: I95127ce1afa19386a847984ca26eb7d7368e6569
This function merges two distinct call objects into one. All contained
objects are moved, and the "source" call is then destroyed. Both call
IDs can then be used to refer to the same internal call objects. Call ID
aliases are kept in a list in the call object.
Change-Id: I8a37775fe0dc3e7ccfeb83e2a3b7d751601450fc
When media subscriptions are removed implicitly by
__subscribe_medias_both_ways(), we must update all RTP sink pointers of
all the streams of the affected medias. Otherwise these sinks will be
left unchanged despite the subscriptions having been removed.
Change-Id: I6d1ac3bb5cb27443c31f0f3b9ce8f47c416cd3ce
The `answer` processing empties out the list of codecs and leaves only
those that were accepted in the answer. Side effect of this is that if
another answer with a different list of codecs comes through, them the
codec-accept function is missing the original list of offered codecs and
can yield an incorrect result.
Fix this by storing a copy of the offered codecs at the end of the
`offer` processing, and then restore this list at the beginning of each
`answer` message.
Change-Id: I3c714e80689f3c5689637cc7d1eb2f203c292a15
Richard Fuchs
Michal Hajek
Donat Zenichev