This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Sipos,
On Sat, Dec 12, 2015 at 02:20:26PM +0100, Sipos Csaba wrote:
> GsmCallFsm(15/3802->7839/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT
> GsmCallFsm(16/7839->3802/CALL_PRESENT): event: mncc_setup_req, NULL -> CALL_PRESENT>>>
great, you have two call actors, and they both send their setup request.
> GsmCallFsm(15/3802->7839/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=15, fields=0x0020))
> [ ... ]
> GsmCallFsm(16/7839->3802/CALL_PRESENT): on_receive(mncc, mncc_msg(type=0x0111, callref=16, fields=0x0020))
Those above two lines mean msg_type=0x0111 = MNCC_REL_IND. So OsmoNITB
is sending you a release indication for both calls.
Please use the usual way for debugging / analyzing problems (like
'logging level cc' on OsmoNITB) to see what's happening. For some
reason the NIBT is releasing the calls. Could be that the subscriber
extension (phone) numbers 3802 / 7839 are not existing or cannot be
reached at this point.
> The MNCC socket is connected according to the BSC, but when I gave the
> command, nothing happens on the BSC nor the BTS side.
I'm sure plenty is happening, you just need to look at the right
logging (cc and mncc subsytems).
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)