Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

the conflict becomes apparent at msc_mgcp_call_assignment(), which is called for the new incoming call while the first call is still busy:
(see packet no. 149 in attached pcap)

        if (conn->rtp.mgcp_ctx) {
                LOGP(DMGCP, LOGL_ERROR, "(subscriber:%s) double assignment detected, dropping...\n",
                     vlr_subscr_name(trans->vsub));
                return -EINVAL;
        }

Per RAN connection, only one mgcp_ctx is available.
But if we are being called while another call is ongoing, there must be

• more than one mgcp_ctx,
  OR
• creating the mgcp_ctx must be postponed until the first call is terminated.

Later on, packet no. 228, the previous mgcp_ctx has been discarded and hence is NULL,
so completing the second call fails.

Goals:

• If the call assignment fails in this way, it should be dismantled and released. Currently it goes on silently.
• Successfully assign the second call.

With trivial code changes, I can manage to switch to the second call; that's on osmo-{bsc,msc} branches neels/call_during_call.
That's already a nice improvement, but uncovers an unclean teardown issue (if a transaction is gone during MGCP operation, the MGCP response tries to access the freed transaction).

Not working on master nor the patch branches is rejecting the second incoming call: the already ongoing call loses voice.

It's not urgent per se, but for example the POC at congress tries to call back after token activation, which falls on its face.

And also in general for everyone using osmo-msc and osmo-bsc, the user experience for a call during an ongoing call is currently dismal.
I would like to reach some non-dismal state of it for congress.

Ok! I've managed to fix both cases with fairly trivial code changes.

• The osmo-bsc must not attempt to re-use an existing lchan for Assignment Command, because re-routing RTP for that is currently not implemented.
  https://gerrit.osmocom.org/c/osmo-bsc/+/12401

• The MSC must not free MGCP/RTP-routing for an ongoing call when releasing a CC trans that has nothing to do with the ongoing call.
  https://gerrit.osmocom.org/c/osmo-msc/+/12397

• The MSC must postpone Assignment for a second incoming call until the first call has ended.
  https://gerrit.osmocom.org/c/osmo-msc/+/12400

After this:

• An incoming call can be rejected. The original call continues. (fixed)
• An incoming call can be taken while dropping the original call. (fixed)
• When taking an incoming call and putting the original call on "hold", a friendly message says that it is not possible,
  and the choice of receiving or rejecting the new call can still be made after that message, in a clean fashion.

I currently haven't tested yet what happens if there is three peers trying to talk to the same number, running out of lab phones (not really, just not bothering now).
Possibly we should be taking over the call indicated by the CC TIO, the current patch version takes on whichever waiting call it finds first.
This is fine if one call comes in on an ongoing call, and this is already a huge improvement to what we had before.

The patches currently fail to build because I'm already using LOGPFSMSL introduced in https://gerrit.osmocom.org/c/libosmocore/+/12386.
But they build and work fine.

this was resolved, but should be re-tested with new osmo-msc...
(Ideally with a ttcn3 test, but we don't verify the voice streaming in ttcn3 at all yet, so that would be rather difficult to introduce)