Project

General

Profile

Bug #3735

call arriving during another call has no voice

Added by neels 12 months ago. Updated 6 months ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/16/2018
Due date:
% Done:

80%

Resolution:

Description

during testing for 35c3 POC reports:

  • be on a voice call.
  • second call comes in and knocks.
  • hang up the first call and answer the second call.

Now the second call has no voice.

History

#1 Updated by neels 12 months ago

  • Subject changed from call during call breaks first call, second call has no audio to call arriving during another call has no voice
  • Description updated (diff)

#2 Updated by neels 12 months ago

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.

#3 Updated by laforge 12 months ago

disclaimer: I don't know the current code off my head

On Tue, Dec 18, 2018 at 01:13:42AM +0000, neels [REDMINE] wrote:

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.

I doubt that either of the two resembles how GSM is specified. There can be up to 7
concurrent call control state machines on top of one MM/RR connection.

AFAIR, what we need is:

  • context for the RAN/MS/UE side RTP connection (once)
  • context for the CN side RTP connection (one for each call, up to 7 per subscriber)
when a new call comes in, we signal this to the user, and the user cann then use call-related
supplementary services to switch between the calls, for example
  • put the first call on hold
  • talk to the second call
  • put the sceond call back on hold, talk to the first call, ...

I'm not saying we need this now, but this is what we should aim for if we make any changes
to data structures or architecture.

Until we support any of the above, the second call should probably simply be rejected
cleanly?

#4 Updated by neels 12 months ago

  • Status changed from New to In Progress

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.

#5 Updated by neels 12 months ago

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

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.

#6 Updated by neels 12 months ago

  • % Done changed from 0 to 90

#7 Updated by neels 12 months ago

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.

#8 Updated by neels 6 months ago

  • % Done changed from 90 to 80

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)

#9 Updated by neels 6 months ago

  • Status changed from In Progress to Stalled

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)