msc: CC Re-Est: allow MNCC_RTP_CREATE upon Assgmt
In f_tc_call_re_establishment_2(), after Assignment Complete, optionally
allow an MNCC_RTP_CREATE.
When Re-Establishing a call, the Assignment Complete usually affects
codec and RTP address, so an MNCC_RTP_CREATE should happen after the
Assignment Complete message.
Current osmo-msc master does not send this MNCC_RTP_CREATE. This is
unlikely to be correct (would be ok if no RTP port changes), likely
omitted due to a bug.
An upcoming patch adds the MNCC_RTP_CREATE in Call Re-Establishment to
osmo-msc.
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: I06d19947ba2e9b6696269db0e4f3d47d4b98bde6
diff --git a/msc/MSC_Tests.ttcn b/msc/MSC_Tests.ttcn
index 0372ec7..1767761 100644
--- a/msc/MSC_Tests.ttcn
+++ b/msc/MSC_Tests.ttcn
@@ -6670,6 +6670,10 @@
vc_conn.done;
}
+private altstep as_mncc_rx_rtp_create(CallParameters cpars) runs on BSC_ConnHdlr {
+ [] MNCC.receive(tr_MNCC_RTP_CREATE(cpars.mncc_callref));
+}
+
const charstring REEST_LOST_CONNECTION := "REEST_LOST_CONNECTION";
const charstring REEST_CLEARED := "REEST_CLEARED";
@@ -6734,12 +6738,15 @@
* Apparently osmo-msc currently also sends an MDCX to the CN side, just repeating the same configuration that
* is already in use. This test accepts any number of or even lack of MDCX. */
var default ack_mdcx := activate(as_mgcp_ack_all_mdcx(cpars));
+ var default optional_rtp_create := activate(as_mncc_rx_rtp_create(cpars));
BSSAP.send(ts_BSSMAP_AssignmentComplete(omit, tla, codec));
+
/* The call has been fully re-established.
* Let a bit of time pass before hanging up, for everything to settle. */
f_sleep(3.0);
+ deactivate(optional_rtp_create);
deactivate(ack_mdcx);
/* Hang up the call and clear the new, second A connection */