Depending on the type of failure in the MSC, MGW or BSC, we may expect
MNCC_REL_CNF in any state.
Closes: SYS#4832
Change-Id: I0d65da82fbcc48c8967a65b917ea14121bd941f3
rtp_bridge=True triggers the automatic transmission of a MNCC_RTP_CREATE
when that call goes into ACTIVE state. We don't want this in the
case of mncc_mt_loadgen, as we perform this at a much sooner point in
time.
Change-Id: I8816ccb8c7dce2958496c81a95f1a91bc33e772b
Using hard-coded paths in shebang is a bad idea, because on different
systems Python interpreter can be installed in different places. See:
https://mail.python.org/pipermail/tutor/2007-June/054816.html
Change-Id: Ib729ece0c95254dc2b235f90eb731681df955bd1
Verified this error by GSMTAP using mncc-python interface OsmocomBB to network
Proposed Changes:
In case of MO call (_onmncc_setup_req) caller needs to provide bearer_cap speech version
Added mncc.bearer_cap in mncc_sock.py based on codecs = GSM48.AllCodecs
Added new field mncc.MNCC_F_BEARER_CAP in mncc.MNCC_SETUP_REQ, when call is initiated (MO) from MS -> network
Change-Id: If77851b86111d62d82221a886ed2391179080cca
The user can submit a list of permitted codecs for a GsmCallFsm or
GsmCallConnector. This list is ordered by priority (highest first),
and the first matching codec is chosen.
TODO: Proper error handling in case no matching codec is found
In the classic MNCC_BRIDGE mode we ask the MSC to bridge the two
traffic channels itself. This works for E1 as well as for RTP
BTSs', and even accross mixed E1 and RTP environments.