No need for a recursive mutex.
Remove unused GMainLoop variable.
Let's stop trying to take locks in destructors.  It's a bad pattern and it implies some other threading problem that needs to be resolved.  The only thing it'll result in is deadlocks.
Remove the queue packet call in the destructor; that call was doing nothing previously because the state had been set to FINISHED, and no packet is queued in that state.

Change the code so we set running_ to false and ICE_FINISHED, and then signal the condition.  In getPacket(), have code that checks the state and returns appropriately.  This allows the Dtls thread to bail.
Few more changes:

1. In NiceConnection, remove agentMutex_; I don't see a good reason to protect this object in the NiceConnection.
2. remove spurrious NiceConnection->start() call; no longer does any work.
3. Remove spurrious queue item call in WebRtcConnection.cpp; setting the "bail" variables and firing the condition object works just as well.
Fix deadlock with SdesTransport, clean up locking

WebRtcConnection would deadlock writing to a SdesTransport because it would hold receiveVideoMutex_ while calling into Transport->write(); on SdesTransport, however, it would ultimately call back into WebRtcConnection::queueData, which attempts to hold receiveVideoMutex_.  This causes a deadlock since boost::mutex isn't recursive.

Change this so we don't hold receiveVideoMutex_ when calling into transport->write(); receiveVideoMutex_ now locks only around the queue in WebRtcConnection and does not hold the lock when calling into child classes.
Merge pull request #190 from jnoring/lock_improvements

Lock improvements