Deadlock due to a lock inversion. In the attached back trace you can see that thread 177 is holding a lock on the transport:
This same thread then requests a lock on the dialog 0xaf3a428c:
However the dialog's (0xaf3a428c) lock is being held by thread 53 by the following:
Thread 53 is then waiting on the transport, which is held by thread 177.
This deadlock happens because the SIP transport being used is TCP and a message on a SIP dialog is being received at the same time as a message on the same SIP dialog is being sent. If the transport were UDP the deadlock won't happen.