7 Sep
2009
7 Sep
'09
6:37 p.m.
Hello All,
While testing DTMF facilities of OpenBSС I've discovered a couple of
bugs.
The first bug is generic to GSM TS 04.08, minor and is connected with
gsm0408_cc_msg_names variable
(gsm_04_08_utils.c). I've found that message names order is wrong: in
original source it is enumerated as
...
"unknown 0x3b",
"STATUS",
"unknown 0x3c"
"NOTIFY"
...
while it should be
...
"unknown 0x3b"
"unknown 0x3c"
"STATUS"
"NOTIFY"
...
thus faling to identify GSM 04.08 STATUS messages.
The second problem is connected with DTMF message sequence. According
to the GSM TS 04.08, DTMF
message flow is the following:
MS -----> START_DTMF
MNCC_START_DTMF_IND ----> MNCC
MNCC_START_DTMF_RSP <---- MNCC
MS <---- START_DTMF_ACK
MS ----> STOP_DTMF
MNCC_STOP_DTMF_IND ----> MNCC
MNCC_STOP_DTMF_RSP <---- MNCC
MS <---- STOP_DTMF_ACK
This is correct, but some mobile equipment (for example, my iPhone and
Nokia 6150) do not reply with
STOP_DTMF message; instead of this, they reply with STATUS message
(type 0x3D). This type of messages is
not processed within OpenBSC. Message is left unhandled in this state
and further DTMF transactions
become impossible because MNCC does not receive DTMF_STOP.
GSM standard says that STATUS message reports about some errors
occurred during transaction, but I
did not explore the message still, though, I can do that if it is
interesting for developers. I have no ideas why
some of my mobile phones behave wrong, while others work correctly.
I still don't know how to deal with STATUS messages properly, so I've
simply added processing entry to the
datastatelist[] variable in gsm_04_08.c which describes a call to
gsm48_cc_rx_stop_dtmf when received a
STATUS message.
It is incorrect, I know, but, however, temporary helps to process DTMF
messages with MS equipment which
have wrong DTMF sequence flow. Now it looks like this:
MS -----> START_DTMF
MNCC_START_DTMF_IND ----> MNCC
MNCC_START_DTMF_RSP <---- MNCC
MS <---- START_DTMF_ACK
MS ----> STATUS
MNCC_STOP_DTMF_IND ----> MNCC
MNCC_STOP_DTMF_RSP <---- MNCC
MS <---- STOP_DTMF_ACK
Sergey.
12 Sep
12 Sep
11:31 a.m.
On Mon, Sep 07, 2009 at 08:37:31PM +0400, Sergey V. Efimoff wrote:
Hello All,
While testing DTMF facilities of OpenBSС I've discovered a couple of
bugs.
Dear Sergey, thanks for your feedback. Please note though that OpenBSC doesn't
really have any DTMF facilities as such, apart from a couple of stubs that were
added to later actually add DTMF support.
The first bug is generic to GSM TS 04.08, minor and is
connected
with gsm0408_cc_msg_names variable
(gsm_04_08_utils.c). I've found that message names order is wrong:
in original source it is enumerated as
...
"unknown 0x3b",
"STATUS",
"unknown 0x3c"
"NOTIFY"
...
while it should be
...
"unknown 0x3b"
"unknown 0x3c"
"STATUS"
"NOTIFY"
...
thus faling to identify GSM 04.08 STATUS messages.
thanks. It would be great if you could send us a patch (diff -u), as
this is how we typically receive bugfixes or other contributions to our
source code. This way only one person has to implement the fix, and we
can simply apply the patch to our repository.
The second problem is connected with DTMF message
sequence.
According to the GSM TS 04.08, DTMF
message flow is the following:
MS -----> START_DTMF
MNCC_START_DTMF_IND ----> MNCC
MNCC_START_DTMF_RSP <---- MNCC
MS <---- START_DTMF_ACK
MS ----> STOP_DTMF
MNCC_STOP_DTMF_IND ----> MNCC
MNCC_STOP_DTMF_RSP <---- MNCC
MS <---- STOP_DTMF_ACK
This is correct, but some mobile equipment (for example, my iPhone
and Nokia 6150) do not reply with
STOP_DTMF message; instead of this, they reply with STATUS message
(type 0x3D). This type of messages is
not processed within OpenBSC. Message is left unhandled in this
state and further DTMF transactions
become impossible because MNCC does not receive DTMF_STOP.
This sounds _really_ weird. It might well be that we are sending something
wrong to the phone, and the phone thus sends us some generic error (as part of
the STATUS)
GSM standard says that STATUS message reports about
some errors
occurred during transaction, but I did not explore the message still, though,
I can do that if it is interesting for developers. I have no ideas why
some of my mobile phones behave wrong, while others work correctly.
I really think there is something wrong that we are doing in the message
syntax or state transitions. Some phones are more tolerant to this than others.
It would be interesting to see a protocol trace of such a phone with a "real"
network. Of course that is hard to obtain unless you happen to work at an
operator or have a demo/testing network with real operator equipment.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5352
days inactive
5357
days old
1 comments
2 participants
participants (2)
-
Harald Welte -
Sergey V. Efimoff