Possible leak if someone were to try and add extra headers to a channel that had either an inbound info on that session or the session were to be deflected. I don't see a way that these extra headers could be added outside of a C module subscribing to the session states, but just to make sure I'm adding these so that just like other extra header locations it's cleaned up.

Alice meet rabit hole. There is a leak here on every invite that comes back from a status 180 when the other side is not FS, but you have presence enabled. Thanks to Coverity scan for location this condition. This 'might' not have been leaking if sofia was automatically freeing this when the sofia object was destroyed, but all other locations where sip_header_as_string where called they were all followed by a su_free, so I assume not.

If the mod_sofia global presense hash is null, then make sure to free the matches variable before going to done.

When message events were added, the debug field name was overlooked. This would have only been hit when debug level was above 'DEBUG1' and at that point it would have incorrectly chosen debug display names.

This was writing a null one space to the right, outside of the malloc'd buffer. On further review this uses apr_vsnprintf which always returns null terminated.

Since there isn't neutral ground, on the rtmp state callback we actually have to force the write lock of the session, but we only need a try lock on removing the session from the rsession->session_hash. This removes a deadlock caused when we had to enforce with locks that the rsession couldn't be destroyed if the FS session was in the middle of a hangup.

Seems having a read lock still prevents a write lock to be taken, even if the thread that is trying to get the write lock currently has the read lock.

Fixes -Wl,-z,now / -Wl,-z,defs errors about undefined symbols.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>