aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorHarald Welte <laforge@gnumonks.org>2016-10-29 22:23:19 +0200
committerHarald Welte <laforge@gnumonks.org>2016-11-02 09:20:54 +0000
commit0c566a444b1cb479dce58df091d2ad5e32d21da0 (patch)
tree932d980086ff31e6d08571ff12aa1bd781a8db96
parent5e5d94cd1b81e3ac0cd9b4423567d56394f15fac (diff)
mncc_builtin: Properly reject DTMFlynxis/master
As per TS 23.014, a GSM MSC must implement mobile-originated DTMF generation. We gate the DTMF signalling messages to MNCC, and expect the external MNCC handler to deal with it. However, the internal MNCC handler simply ignored such singalling messages, rather than rejecting DTMF altogether. It turns out failure to respond to START DTMF will cause some phones to behave in interesting ways, particularly with modem firmware v6.01.00, see https://osmocom.org/issues/1817). In this case the phone is not able to release the call as the pending response to the START DTMF is probably keping a reference or lock of some sort. Change-Id: I336f0cd0a6396b522d228479a417fd4d606157ac
-rw-r--r--openbsc/src/libmsc/mncc_builtin.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/openbsc/src/libmsc/mncc_builtin.c b/openbsc/src/libmsc/mncc_builtin.c
index 9b25ede83..067cc92f8 100644
--- a/openbsc/src/libmsc/mncc_builtin.c
+++ b/openbsc/src/libmsc/mncc_builtin.c
@@ -386,8 +386,10 @@ int int_mncc_recv(struct gsm_network *net, struct msgb *msg)
case MNCC_FACILITY_IND:
break;
case MNCC_START_DTMF_IND:
+ rc = mncc_tx_to_cc(net, MNCC_START_DTMF_REJ, data);
break;
case MNCC_STOP_DTMF_IND:
+ rc = mncc_tx_to_cc(net, MNCC_STOP_DTMF_RSP, data);
break;
case MNCC_MODIFY_IND:
mncc_set_cause(data, GSM48_CAUSE_LOC_PRN_S_LU,