Hi everyone, and in this particular case Sylvain,
I know I'm hogging osmo-msc.git and I don't intend to hinder everyone else's work, but I doubt that it was really necessary to merge the silent call channel types patch to master right now. I'm really overloaded with doing the inter-MSC handover work, I'm again postponing my well earned leave that I would have liked to have started two months ago, and I don't want to be burdened with also resolving everyone else's merge conflicts. You all know that pretty much everything changes in osmo-msc, even if only slightly. As a rule of thumb, if you see a 'ran_conn', 'vlr_subscr_get()', a Paging callback function or a 'gsm_trans' in a bit of code, likely there will be merge conflicts with my current branch. Most should be trivial, but they will be stones put in my way.
So please, before you merge onto master, consider doing the same work on the tip of my branch 'neels/ho' in osmo-msc, rather than on current master. That would be the ideal situation for me, because then you also test my patches.
There still is ongoing work at the tip of neels/ho, if you want a more stable point to apply modifications to, look at the commit 'add LOG_TRANS, proper context for all transactions' and rebase your changes onto that.
If you push those changes onto a private branch, I will even see them in tig and can simply incorporate them in by branch, carrying them along until we're ready to merge.
If you prefer working on master, still do me a favor: just try to rebase the patch onto neels/ho. All the conflicts that you see in such a rebase will end up on my table and stop me from going forward until I have resolved them. Consider that before you hit that "Submit" button on gerrit in the osmo-msc.git repository.
Plus, if I resolve conflicts with *your* code, likely I won't grok some minor detail and introduce bugs.
So let's work together on this. Thanks!
Working on osmo-msc.git neels/ho branch also needs various patches in other repositories; all these branches are kept up-to-date every day and all the time:
libosmocore neels/misc libosmo-sccp neels/conn_id osmo-mgw neels/endpoint_fsm osmo-msc neels/ho
Thanks again!
~N
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
-
Neels Hofmeyr