merge conflicts in osmo-msc

historical

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190314/e6277d71/attachment.bin>