OpenBSC status report / Handover

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)