Hi Holger!
I'm currently reviewing changeset 2d501ea26a219176b1c556449e45ebd90d4accfb
and just noticed that you introduce a new 'int rf_locked' member to struct
gsm_bts_trx, which I believe is not needed.
We are already tracking the administrative state of all objects in the BTS
and mirror their state.
The specific state you are looking for should be in
gsm_bts_trx.nm_state.administrative
I would appreciate if you could fix this.
--
- 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)
From: Sylvain Munaut <tnt(a)246tNt.com>
If a RF channel is assigned but no response is ever heard from
the phone, we will receive a CONNECTION FAIL from the BTS,
triggering a RF release freeing the channel. Then sometime later,
T3101 will expire as well and free the channel again ...
Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com>
---
openbsc/src/chan_alloc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/openbsc/src/chan_alloc.c b/openbsc/src/chan_alloc.c
index 786e8b1..a23192a 100644
--- a/openbsc/src/chan_alloc.c
+++ b/openbsc/src/chan_alloc.c
@@ -251,6 +251,7 @@ void lchan_free(struct gsm_lchan *lchan)
/* stop the timer */
bsc_del_timer(&lchan->release_timer);
+ bsc_del_timer(&lchan->T3101);
/* clear cached measuement reports */
lchan->meas_rep_idx = 0;
--
1.6.5.1
Hi!
Just a "quick" status report about the progress I've made with the code
over the last three days, and what is now in 'master':
1) handover is not only working on a signalling level, but also fully working
with actual voice traffic
This turned out to be a major headache, since we don't [yet?] have a proper
RTP media gateway and so far decided to simply relay the RTP frames rather
than doing proper processing. In case of handover though, the RTP source
changes (different SSRC / timestamp / sequence) - plus we also get some
dropped frames and have to ensure that we don't hide that fact from the
receiver.
In order to make it work, I added a new "MNCC RTP Proxy" mode, which is
automatically selected if you
a) enable the RTP Proxy mode with "-P" on the command line, and
b) enable handover using the 'handover 1' command on the VTY
The Handover decision (handover_decision.c) is currently still based on
a single MEASUREMENT REPORT, i.e. way too volatile. This was intended
for testing, where we need as many handovers as possible.
I've meanwhile written a lot of additional code to implement proper measurement
averaging and neighbor cell selection. This is not committed yet, but
will be committed by tomorrow.
2) Support for MNCC (lcr) with RTP based BTS is in 'master'
There's no need for any old branches or patches for this anymore
3) Support for EFR frames with RTP based BTS in MNCC
4) No half-rate support at 26C3. The integration with lcr is likely
too much work, and I think we should try not to implement even more
features that have not yet received lots of testing
5) fixing tons of compiler warnings all over the code
6) fix segfault in RRLP in case of unsuccessful paging (sorry sylvain,
I fixed this independently before seeing your patch, but I actually
prefer your solution, will look at it tomorrow)
7) correct System Information Type 5 and 6 on ip.access
The two BTS types implement the RSL SACCH FILLing slightly different,
resulting in broken neighbor cell lists on ip.access systems.
Any testing of current master that you can do is very much appreciated,
let's hope we can catch more bugs before we go live at 26C3.
Regards,
Harald
--
- 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)
Hi,
I have a nanobts unit 139 with a software that somehow only accepts GSM FR
(and not EFR), unless I also send the RTP payload type IE (
RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RTP
payload type" IE, the "RTP payload type 2" has no effect I can see).
hi,
here are two patches (attached):
the lcr_rtp.fix will make the current lcr_rtp branch compile. also it
works with LCR.
the systeminfo.fix contains a pointer fix and a question why there is a
value cleared again. (don't apply it, just apply the line with the
pointer fix)
regards,
andreas