msc_a: send MNCC_RTP_CONNECT in call waiting scenarios

In normal operation, when a call is established, TCH is assigned
where none existed previously, and when this assignment succeeds,
gsm48_tch_rtp_create() is called to communicate RTP stream info
to the external call agent via MNCC_RTP_CREATE message.  However,
in a call waiting scenario, TCH already exists from call 1 and
there is no new channel assignment to be made for call 2 - instead
the same TCH is expected to be reused as the user switches between
calls.

The problem, however, is that because no new channel assignment is
made, the external MNCC agent never receives an MNCC_RTP_CREATE for
call 2 - and without RTP stream info that call cannot be connected,
and thus call 2 establishment fails.

The present patch is a hack that makes call waiting work in basic
usage testing: in the already-detected case of "Another call
is already ongoing" in msc_a_try_call_assignment(), simply call
gsm48_tch_rtp_create() and hope that a successful channel assignment
has already been made, and that the existing TCH is good enough for
the new call which could have different bearer capabilities and thus
different TCH requirements.

Related: OS#5699
Change-Id: Ibb62cb3c154b99769b2dfe708f73c20e8b632f5d
This commit is contained in:
Mychaela N. Falconia 2022-11-03 07:17:10 +00:00
parent 2c6c74ea5c
commit 2f0ea7681c
1 changed files with 2 additions and 0 deletions

View File

@ -1797,6 +1797,8 @@ int msc_a_try_call_assignment(struct gsm_trans *cc_trans)
if (msc_a->cc.active_trans) {
LOG_MSC_A(msc_a, LOGL_INFO, "Another call is already ongoing, not assigning yet\n");
/* a hack to make call waiting work */
gsm48_tch_rtp_create(cc_trans);
return 0;
}