MGCP permits for the CallAgent to send a wildcarded endpoint name,
at which point the MGW itself must allocate an endpoint name and
return it as SpecificEndpointId parameter in the CRCX response.
Change-Id: I704bbe4e11b27e83a6ae6a71aa6a715dc8301f34
We shouldn't "pass" f_establish_fully() in the assignment case
as long as the old RF channel hasn't been released via RSL.
Change-Id: If7c7c8c4826feba47f8a0395c291157a0e48cd9d
This adds code for the rather intricated and nested transactions
happening on RSL, BSSAP, MGCP and RSL-IPA. We use explicit
invocation of altsteps to simplify the main function f_establish_fully.
Change-Id: I5f830b010ea1b466ae74fa810df86638a74a3b8b
It's quite cumbersome if the user of the BSSMAP_Emulation (the ConnHdlr)
will have to manually decode the DTAP in every BSSAP/DTAP message he
receives (and encode on the transmit side). Let's introduce a new
optional mode in which the DTAP messages are already decoded for
more convenient matching inside the ConnHdlr.
Change-Id: I35cd4ea78aca0ce7c7d745e082d7289882c11e81
Don't expect the ASSIGNMENT to fail in case of unsupported A5/4,
but expect a CIPHERING MODE REJECT.
Change-Id: I15024f61e67795b7e5ce72e1b641db6ca92ff76d
For some weird reason the link_id is *not* the second IE in
RSL_MT_ENCR_CMD, while it is in all other RSL RLL or DCHAN messages.
Change-Id: Iea93aa8dba74d25c74a257d011ba43308ee375e4
In all RSL messages the link identifier is usually the second IE.
However, as the only known exception, the RSL Encryption Command has it
as third IE.
Fixes the following error message:
Dynamic test case error: Using non-selected field link_id in a value of
union type @RSL_Types.RSL_IE_Body
Change-Id: I2bbb83b5394d0b693a47d286beed5c699ab6e8ae
Let's verify the operation of the CIPHERING MODE COMMAND as issued
by MSC, performed by BSC and implemented by simulated BTS/MS.
Change-Id: Ibc06bd2177c63837a794a0ca1f54ebef17499e78
Using the MSC_ConnHdlr component, we can now handle the BSSAP (MSC)
and RSL (BTS) side of a single radio channel.
Change-Id: I00dcf1e4eaa7f133788cc01fbbcd4148a0258ef4
So far, BSSMAP_Emulation used the SCCPasp_SP_PORT directly, explicitly
calling BSSAP encode/decode functions while processing the primitives.
Let's clean this up and use the BSSAP_CodecPort which has meanwhile
been developed as a dual-faced port that can be stacked between SCCPasp
and the user to avoid any manual encode/decode function calls.
Change-Id: Icded789d18f3469f74e16f552df2c7ac44ac4294
Harald Welte
Daniel Willmann