The correct fix is to use gcc-4.7 or newer.  If the compiler borked
this, one should trust nothing else it produces.

Revert "FS-6524,FS-6494: the compiler for rpi seems to be strangely
mis-optimizing this if/else block. Yes, its already set to this value,
but without the else block, it 'magically' hits the if blocks above,
unless you sleep, print a log, or add the else"

This reverts commit 1ca1d637.

Introduced in commit e6ac87f5.

FS-6524,FS-6494: the compiler for rpi seems to be strangely mis-optimizing this if/else block. Yes, its already set to this value, but without the else block, it 'magically' hits the if blocks above, unless you sleep, print a log, or add the else

Release session R/W Lock

add heartbeat_fire_on_set variable to fire heartbeat instantly when its first enabled (legacy behavior)

We received the reply and signaled the condition
earlier then started to wait for it

We were using the libopus directory itself rather than a file within
it as a makefile target.  This is a bad idea as make will see the
target as updated whenever files are created in or removed from the
directory.  Since running configure creates and removes files, the
target will always appear dirty.

The effect was that when mod_opus was enabled in FS make would always
cause libopus to be reconfigured.

We'll target instead the configure file in libopus as that's the first
thing we need anyway.

sofia_glue_get_url_from_contact to strdup the value so before
overwriting the value signal to sofia that we have finished with the
raw header.

sip_header_as_string returns new memory alloc'd on the nua_handle's memory pool. This memory would not be freed until
the handle was destroyed. Since there is no usage of the call-info header after it is added to the event as a header value,
we should make sure to both su_free the sofia returned string, but also more cleanly create the event header value to reduce a strdup.

CID:1210789 Make return value of a function available from the another calling function.  Also add a small status check.

CID: 1214223-1214230 If sent an invalid registration authentication header with multiple params of the same name, then only use the first of the params instead of leaking memory