OpenBSC

openbsc@lists.osmocom.org

4317 discussions

[PATCH] Possible BS11 fixes..
by Holger Freyther 21 Dec '09

21 Dec '09

Hi Harlad, does this make sense to you? openbsc/src/abis_nm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index bb7248b..dce1c35 100644 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -653,13 +653,13 @@ objclass2nmstate(struct gsm_bts *bts, u_int8_t obj_class, nm_state = &bts->bs11.cclk.nm_state; break; case BS11_OBJ_BBSIG: - if (obj_inst->ts_nr > bts->num_trx) + if (obj_inst->trx_nr >= bts->num_trx) return NULL; trx = gsm_bts_trx_num(bts, obj_inst->trx_nr); nm_state = &trx->bs11.bbsig.nm_state; break; case BS11_OBJ_PA: - if (obj_inst->ts_nr > bts->num_trx) + if (obj_inst->trx_nr >= bts->num_trx) return NULL; trx = gsm_bts_trx_num(bts, obj_inst->trx_nr); nm_state = &trx->bs11.pa.nm_state; -- 1.6.3.3

2 2

Disabling RF for a TRX / Tracking abis NM state
by Harald Welte 21 Dec '09

21 Dec '09

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)

2 5

fix on trau frame check
by Andreas.Eversberg 20 Dec '09

20 Dec '09

minor fix for master branch. (self explaining) LCR works with the main branch also.

2 1

[PATCH 1/3] chan_alloc: Delete T3101 on lchan_free as well
by Sylvain Munaut 20 Dec '09

20 Dec '09

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

2 5

[PATCH 1/2] [signal] Differentiate paging success from expiration in SS_PAGING
by Sylvain Munaut 20 Dec '09

20 Dec '09

From: Sylvain Munaut <tnt(a)246tNt.com> This is useful information to know and actually fixes a segfault in rllp.c where lchan is accessed even tough it could be NULL in case of failure. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- openbsc/include/openbsc/signal.h | 3 ++- openbsc/src/gsm_04_08_utils.c | 2 +- openbsc/src/paging.c | 2 +- openbsc/src/rrlp.c | 4 +++- 4 files changed, 7 insertions(+), 4 deletions(-) diff --git a/openbsc/include/openbsc/signal.h b/openbsc/include/openbsc/signal.h index 8c815f8..3680d56 100644 --- a/openbsc/include/openbsc/signal.h +++ b/openbsc/include/openbsc/signal.h @@ -45,7 +45,8 @@ enum signal_subsystems { /* SS_PAGING signals */ enum signal_paging { - S_PAGING_COMPLETED, + S_PAGING_SUCCEEDED, + S_PAGING_EXPIRED, }; /* SS_SMS signals */ diff --git a/openbsc/src/gsm_04_08_utils.c b/openbsc/src/gsm_04_08_utils.c index e96a1ca..2183743 100644 --- a/openbsc/src/gsm_04_08_utils.c +++ b/openbsc/src/gsm_04_08_utils.c @@ -488,7 +488,7 @@ int gsm48_handle_paging_resp(struct msgb *msg, struct gsm_subscriber *subscr) sig_data.bts = msg->lchan->ts->trx->bts; sig_data.lchan = msg->lchan; - dispatch_signal(SS_PAGING, S_PAGING_COMPLETED, &sig_data); + dispatch_signal(SS_PAGING, S_PAGING_SUCCEEDED, &sig_data); /* Stop paging on the bts we received the paging response */ paging_request_stop(msg->trx->bts, subscr, msg->lchan); diff --git a/openbsc/src/paging.c b/openbsc/src/paging.c index b273419..6cd4d05 100644 --- a/openbsc/src/paging.c +++ b/openbsc/src/paging.c @@ -212,7 +212,7 @@ static void paging_T3113_expired(void *data) cbfn = req->cbfn; paging_remove_request(&req->bts->paging, req); - dispatch_signal(SS_PAGING, S_PAGING_COMPLETED, &sig_data); + dispatch_signal(SS_PAGING, S_PAGING_EXPIRED, &sig_data); if (cbfn) cbfn(GSM_HOOK_RR_PAGING, GSM_PAGING_EXPIRED, NULL, NULL, cbfn_param); diff --git a/openbsc/src/rrlp.c b/openbsc/src/rrlp.c index 60ce750..3504451 100644 --- a/openbsc/src/rrlp.c +++ b/openbsc/src/rrlp.c @@ -89,10 +89,12 @@ static int paging_sig_cb(unsigned int subsys, unsigned int signal, struct paging_signal_data *psig_data = signal_data; switch (signal) { - case S_PAGING_COMPLETED: + case S_PAGING_SUCCEEDED: /* A subscriber has attached. */ send_rrlp_req(psig_data->lchan); break; + case S_PAGING_EXPIRED: + break; } return 0; } -- 1.6.5.1

2 2

OpenBSC status report / Handover
by Harald Welte 20 Dec '09

20 Dec '09

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)

1 0

The need of RTP payload type IE in CRCX and MDCX
by Sylvain Munaut 20 Dec '09

20 Dec '09

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).

2 2

[PATCH] ipaccess: Send RTP Payload IE for CRCX & MDCX
by Sylvain Munaut 20 Dec '09

20 Dec '09

From: Sylvain Munaut <tnt(a)246tNt.com> For GSM V1 FR, the payload type is fixed to 3 in the RFC. But for the other codecs, the payload type is dynamically assigned between 96 and 127. Here, we use a static mapping internal to OpenBSC. This patch is needed to make a rather old 139 unit (with sw version 120a002_v149b42d0) work with something else than FR codec. I also tested this patch on a newer 139 (with sw version 120a352_v267b22d0) to make sure it didn't add a regression. More testing with newer EDGE units should be done by whoever has some of theses. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- openbsc/include/openbsc/gsm_data.h | 1 + openbsc/include/openbsc/rtp_proxy.h | 6 ++++ openbsc/src/abis_rsl.c | 53 ++++++++++++++++++++++++++++++++-- openbsc/src/rtp_proxy.c | 3 -- 4 files changed, 56 insertions(+), 7 deletions(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index bc1dbe6..16d6d94 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -204,6 +204,7 @@ struct gsm_lchan { u_int16_t bound_port; u_int16_t connect_port; u_int16_t conn_id; + u_int8_t rtp_payload; u_int8_t rtp_payload2; u_int8_t speech_mode; struct rtp_socket *rtp_socket; diff --git a/openbsc/include/openbsc/rtp_proxy.h b/openbsc/include/openbsc/rtp_proxy.h index a3e4596..07cf5a2 100644 --- a/openbsc/include/openbsc/rtp_proxy.h +++ b/openbsc/include/openbsc/rtp_proxy.h @@ -28,6 +28,12 @@ #include <openbsc/linuxlist.h> #include <openbsc/select.h> +#define RTP_PT_GSM_FULL 3 +#define RTP_PT_GSM_HALF 96 +#define RTP_PT_GSM_EFR 97 +#define RTP_PT_AMR_FULL 98 +#define RTP_PT_AMR_HALF 99 + enum rtp_rx_action { RTP_NONE, RTP_PROXY, diff --git a/openbsc/src/abis_rsl.c b/openbsc/src/abis_rsl.c index 2d55806..f4c42b8 100644 --- a/openbsc/src/abis_rsl.c +++ b/openbsc/src/abis_rsl.c @@ -39,6 +39,7 @@ #include <openbsc/paging.h> #include <openbsc/signal.h> #include <openbsc/meas_rep.h> +#include <openbsc/rtp_proxy.h> #define RSL_ALLOC_SIZE 1024 #define RSL_ALLOC_HEADROOM 128 @@ -1496,6 +1497,44 @@ static u_int8_t ipa_smod_s_for_lchan(struct gsm_lchan *lchan) return 0; } +static u_int8_t ipa_rtp_pt_for_lchan(struct gsm_lchan *lchan) +{ + switch (lchan->tch_mode) { + case GSM48_CMODE_SPEECH_V1: + switch (lchan->type) { + case GSM_LCHAN_TCH_F: + return RTP_PT_GSM_FULL; + case GSM_LCHAN_TCH_H: + return RTP_PT_GSM_HALF; + default: + break; + } + case GSM48_CMODE_SPEECH_EFR: + switch (lchan->type) { + case GSM_LCHAN_TCH_F: + return RTP_PT_GSM_EFR; + /* there's no half-rate EFR */ + default: + break; + } + case GSM48_CMODE_SPEECH_AMR: + switch (lchan->type) { + case GSM_LCHAN_TCH_F: + return RTP_PT_AMR_FULL; + case GSM_LCHAN_TCH_H: + return RTP_PT_AMR_HALF; + default: + break; + } + default: + break; + } + LOGP(DRSL, LOGL_ERROR, "Cannot determine ip.access rtp payload type for " + "tch_mode == 0x%02x\n & lchan_type == %d", + lchan->tch_mode, lchan->type); + return 0; +} + /* ip.access specific RSL extensions */ static void ipac_parse_rtp(struct gsm_lchan *lchan, struct tlv_parsed *tv) { @@ -1562,11 +1601,14 @@ int rsl_ipacc_crcx(struct gsm_lchan *lchan) /* 0x1- == receive-only, 0x-1 == EFR codec */ lchan->abis_ip.speech_mode = 0x10 | ipa_smod_s_for_lchan(lchan); + lchan->abis_ip.rtp_payload = ipa_rtp_pt_for_lchan(lchan); msgb_tv_put(msg, RSL_IE_IPAC_SPEECH_MODE, lchan->abis_ip.speech_mode); + msgb_tv_put(msg, RSL_IE_IPAC_RTP_PAYLOAD, lchan->abis_ip.rtp_payload); DEBUGP(DRSL, "channel=%s chan_nr=0x%02x IPAC_BIND " - "speech_mode=0x%02x\n", gsm_ts_name(lchan->ts), - dh->chan_nr, lchan->abis_ip.speech_mode); + "RTP_PAYLOAD=%d speech_mode=0x%02x\n", + gsm_ts_name(lchan->ts), dh->chan_nr, + lchan->abis_ip.rtp_payload, lchan->abis_ip.speech_mode); msg->trx = lchan->ts->trx; @@ -1593,12 +1635,14 @@ int rsl_ipacc_mdcx(struct gsm_lchan *lchan, u_int32_t ip, u_int16_t port, /* 0x0- == both directions, 0x-1 == EFR codec */ lchan->abis_ip.speech_mode = 0x00 | ipa_smod_s_for_lchan(lchan); + lchan->abis_ip.rtp_payload = ipa_rtp_pt_for_lchan(lchan); ia.s_addr = htonl(ip); DEBUGP(DRSL, "channel=%s chan_nr=0x%02x IPAC_MDCX " - "IP=%s PORT=%d RTP_PAYLOAD2=%d CONN_ID=%d speech_mode=0x%02x\n", + "IP=%s PORT=%d RTP_PAYLOAD=%d RTP_PAYLOAD2=%d CONN_ID=%d speech_mode=0x%02x\n", gsm_ts_name(lchan->ts), dh->chan_nr, inet_ntoa(ia), port, - rtp_payload2, lchan->abis_ip.conn_id, lchan->abis_ip.speech_mode); + lchan->abis_ip.rtp_payload, rtp_payload2, + lchan->abis_ip.conn_id, lchan->abis_ip.speech_mode); msgb_tv16_put(msg, RSL_IE_IPAC_CONN_ID, lchan->abis_ip.conn_id); msgb_v_put(msg, RSL_IE_IPAC_REMOTE_IP); @@ -1606,6 +1650,7 @@ int rsl_ipacc_mdcx(struct gsm_lchan *lchan, u_int32_t ip, u_int16_t port, *att_ip = ia.s_addr; msgb_tv16_put(msg, RSL_IE_IPAC_REMOTE_PORT, port); msgb_tv_put(msg, RSL_IE_IPAC_SPEECH_MODE, lchan->abis_ip.speech_mode); + msgb_tv_put(msg, RSL_IE_IPAC_RTP_PAYLOAD, lchan->abis_ip.rtp_payload); if (rtp_payload2) msgb_tv_put(msg, RSL_IE_IPAC_RTP_PAYLOAD2, rtp_payload2); diff --git a/openbsc/src/rtp_proxy.c b/openbsc/src/rtp_proxy.c index 5513497..6896755 100644 --- a/openbsc/src/rtp_proxy.c +++ b/openbsc/src/rtp_proxy.c @@ -81,9 +81,6 @@ struct rtp_x_hdr { #define RTP_VERSION 2 -#define RTP_PT_GSM_FULL 3 -#define RTP_PT_GSM_EFR 97 - /* decode an rtp frame and create a new buffer with payload */ static int rtp_decode(struct msgb *msg, u_int32_t callref, struct msgb **data) { -- 1.6.5.1

1 0

fix of lcr_rtp and systeminfo
by Andreas.Eversberg 20 Dec '09

20 Dec '09

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

1 0

[PATCH 0/7] Preliminary fixes
by Sylvain Munaut 18 Dec '09

18 Dec '09

Here's a small series with some minor fixes I found when looking at multiple SMS in a single RR connection. For the MO case, it actually now works as described in the spec in the no-error case. But what can happen is that after the second CM SERVICE REQUEST, we may never receive the last CP-ACK of the previous transaction (and thus leak a transaction). The spec says than when receiving a CP-DATA after a CM SERVICE REQUEST we should consider we also implicitely received the last CP-ACK of the previous transaction ... that's not implemented yet. For the MT case, it currently makes several RR connection which is quite bad ... to be fixed. Sylvain

3 9

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC