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:
parent
2c6c74ea5c
commit
2f0ea7681c
|
@ -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;
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue