hi harald,
>Of course this will mean that we need to develop the RTP-to-MNCC
integration, since nanoBTS voice channels arrive on RTP. I am willing
to look into this, but I presume you also have a big interest in that
(and maybe more time?).
i am interested having RTP audio available to MNCC interface as well.
the audio stream (frames) should be equal for BS11 and nanoBTS, so both
streams work for MNCC interface without different handling on the
application side. for this i would like to cross-convert the frame
coding of BS11 to the actual gsm format inside OpenBSC instead of just
forwarding the TRAU frame format. if the TRAU frame is converted inside
OpenBSC, calls from BS11 to nanoBTS would also be possible.
>Since I now own more nanoBTS, I could send you one for 1-2 months of
development of that code. Are you interested in this?
yes, i am. this way it is easier to run some tests.
regards,
andreas
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.
hi,
i just uploaded a new version of linux-call-router at
www.linux-call-router.de. this version is equal to the current git.
it has fixes, one is about conference creation and release. calls can
now be forwarded by joining conference during ringing state: "*3#" and
you may hang up, the party on hold will get transfered to the ringing
phone.
the major reason for a release is that OpenBSC main branch can be
compiled with LCR, without any patch.
hope you enjoy,
andreas
hi,
to connect multiple BS11 to one single E1 interface via cascade, a
special patch was required. now it is part of the mISDN GIT. (socket
branch)
use these module options:
modprobe hfcmulti dmask=0x00000042 bmask=0x0000003c,0x00000780
debug=0x40000
the dmask will give a dchannel mask for the first E1 interface. multiple
masks can be given for multiple E1 interfaces.
the dmask will have bit set for each dchanne. in the example we have two
bits set: slot 1 and slot 6.
the bmask will give a bchannel mask for each given dchannel bit:
for dchannel on slot 1 we use slot 2,3,4,5 for bchannel
for dchannel on slot 6 we use slot 7,8,9,10 for bchannel
the debug option displays initialization of E1 card on dmesg.
misdn_info:
Port 1 'hfc-e1.2-1': TE/NT-mode PRI E1 (for phone lines & E1
devices)
4 B-channels: 2-5
--------
Port 2 'hfc-e1.2-2': TE/NT-mode PRI E1 (for phone lines & E1
devices)
4 B-channels: 7-10
regards,
andreas
