Attached is a patch that creates a temporary 'originate_signal_bond' variable during originate, that is then used to look up the bleg in the aleg by the 3pcc proxy bypass code - as suggested in comments on FS-3848.

This patch also modifies the queue_indication vs pass_indication in sofia_handle_sip_r_invite (sofia.c around line 4905) that was last changed in FS-3421 in order to fix t38 negotiation. I have tried to separate out the t38 case from the reinvite case so as to use queue_indication for the t38 message that apparently needs it, and pass_indication for the reinvite respond message that appears to need that in order to be processed.

Without this, on a bypass_mode reinvite (non-3pcc, but immediately following a bypass_mode 3pcc proxy invite...) the reinvited leg sends a 100 Trying reponse and then sits there whilst the other leg goes through the whole reinvite-200ok-ack sequence - it seems to never see the message to send its 200OK, even though logs indicate that a SWITCH_MESSAGE_INDICATE_RESPOND was indeed sent to it.

This non-handling of the queued respond message on a reinvite may be a symptom of a more subtle problem - I think the reason it isn't handled is because either the leg being signalled is in a state whereby it isn't reading its message queue, or because the other leg changes state immediately after the message is sent in such a way as to cause the unresponsive leg to flush its message queue before it can handle the message, but I haven't had time to get to the bottom of why this should be. Maybe something isn't being set/cleared/changed in the call state properly at the end of the previous invite round?