Fix the bug that dectmngr fails to start at the first attempt
Wait for the target up and running before starting dectmngr. Otherwise HELLO_REPLY
cannot be received and dectmngr exits and is started again by procd.
Wait for the target up and running before starting dectmngr. Otherwise HELLO_REPLY
cannot be received and dectmngr exits and is started again by procd.
- /etc/init.d/dectmngr: set model id from hw.board.dect_model_id if the value in the database
is valid. Otherwise set to 30.3B.06
- Add a config option: ENABLE_LINE_SETTINGS_EXTENSION in the package
To enable logging of communication between Host and DECT CMBS target the
following steps needs to be run:
$uci set dectmngr.general.log_dect_cmbs='1'
$uci commit
$/etc/init.d/dectmngr restart
Signed-off-by: Grzegorz Sluja <grzegorz.sluja@iopsys.eu>
To enable logging of communication between Host and DECT CMBS target the
following steps needs to be run:
$uci set asterisk.general.log_dect_cmbs='1'
$uci commit
$/etc/init.d/dectmngr restart
Signed-off-by: Grzegorz Sluja <grzegorz.sluja@iopsys.eu>
This is a temporary workaround for https://project.iopsys.eu/issues/4141, i.e. DTMF events
can not be detected and silent egress RTP payload for incoming calls.
The latest working version is SMARTHUB3-GFAST-IOPSYS-6.1.0ALPHA0-210112_0249. The problem
starts with SMARTHUB3-GFAST-IOPSYS-6.1.0ALPHA0-210113_0331. Note that this was just a test
result on one SmartHub3 device. It may vary on other devices.
Between these two nightly build versions, there were some dectmngr changes. Simply stopping
dectmngr process by "service dect stop" may cause the bug disappears. Copy dectmngr from the
second firmware to the first one, then the problem happens too.
So it seems that changes in dectmngr causes the FXS issues. Further investigation in dectmngr
will be undertaken.
