Re: merge conflicts in osmo-msc

Hi Sylvain, in this particular patch I ended up not having the patience to understand enough details right now to carry out the rebase. I think likewise you might need a moment to understand the new osmo-msc code. So I guess we should discuss what should happen in prose and I hopefully can help you translate into code. But right now I'm reluctant to get distracted at all, so now I actually start my neels/ho branch with a revert of the osmo-msc 'Allow different channel types to be requested as silent calls' patch -- the intention is not to undo your work, but instead to not lose my focus on inter-MSC handover until we can figure it out. I realize I should have raised these issues on gerrit before merging, but for obvious reasons I'm also currently avoiding hours of gerrit review that I would normally do... Sorry about that; let's see how we can resolve. I suspect there is a more trivial solution than deferring; after all, getting into the COMMUNICATING state should happen by event dispatch and should be possible any number of times, in particular fired whenever a valid transaction gets started (on neels/ho by sending the event MSC_A_EV_TRANSACTION_ACCEPTED to msc_a). There is no onenter action, so I'm quite sure the COMMUNICATING state is not a reason to defer anything. If entering COMMUNICATING more than once triggers bugs, then we should guard that events get triggered only on first entering the COMMUNICATING state -- but I don't see anything being triggered at all anyway. The sole purpose of the COMMUNICATING state is to remove the FSM timeout. On the neels/ho branch, you will now find MSC_A_ST_COMMUNICATING in msc_a.c, not in ran_conn.c. ~N