aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc/osmo_msc.c
diff options
context:
space:
mode:
authorNeels Hofmeyr <neels@hofmeyr.de>2018-12-20 02:59:32 +0100
committerNeels Hofmeyr <neels@hofmeyr.de>2018-12-21 01:59:24 +0100
commita8a0059c4fc9d881e8fff5262a92a5e407c98be0 (patch)
treea68d692d075b9888868d7758b8ccb7642f6fc2e2 /src/libmsc/osmo_msc.c
parent209ee2a699d60fa75f0c4eb886b8a85c3be7f00f (diff)
fix: incoming call during ongoing call
If a call is already busy and another call is coming in, do not try to immediately assign an lchan (before this patch, it fails because there already is an mgcp_ctx for the conn). Leave the second CC transaction waiting. When a call is hung up, as soon as the old mgcp_ctx is discarded, look for other CC transactions that are waiting. If there is one, trigger assignment, so a new mgcp_ctx is set up for the new call. This fixes the following scenario: - from A, call B. - from C, call B; B rings during ongoing call. - in B, pick up the call, choose to drop the old call. After this patch, and with osmo-bsc patch with change-id I0c00ec2c120e5008281755adcd4944a3ce4d8355 we are now able to talk to the new caller. 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 particular call indicated by the CC TI; instead, the current patch version takes on whichever waiting call it finds first. This is fine if *one* additional call comes in on an ongoing call, and this is already a huge improvement to what we had before. Related: OS#3735 Change-Id: I0ba216b737909e92080a722db26e3577726c63cb
Diffstat (limited to 'src/libmsc/osmo_msc.c')
0 files changed, 0 insertions, 0 deletions