Bug #3735
opencall arriving during another call has no voice
80%
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.
Files
Updated by neels over 5 years 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)
Updated by neels over 5 years 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.
Updated by laforge over 5 years 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)
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?
Updated by neels over 5 years 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.
Updated by neels over 5 years ago
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.
Updated by neels over 5 years 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.
Updated by neels almost 5 years 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)