March 2012 - OpenBSC - lists.osmocom.org

by Peter Caprioli

Hello everyone, I've just finnished writing together a small web interface for the OpenBSC HLR. It allows you to modify various parameters in the database and also provides a set of functions to modify the HLR or sending SMSes in your own scripts. The project is still very alpha but it seems to work reasonably good. Feel free to give any feedback! Screenshots and source code is available on my website: https://stormhub.org/simplehlr/ -- *Best regards, Peter Caprioli*

10 years, 10 months

3
6
0 0

Several questions

by jason mercury

I have some questions: 1) When I start bsc_hack bsc_init.c first establishes OML link and initializes the bts then it establishes RSL link and bts starts broadcasting. However, it takes so much time to start the bts. Instead of this I want to do the following: it establishes OML link at the beginning and only once, then when i want to start broadcasting it establishes just the RSL link and bts will start faster since i don't have to wait for OML link. What should be done for this? 2) If i send one or two word messages from telnet interface it is okay. But if i send a longer message the phone could't receive the end of the message correctly(last words may be incomplete). Did any one encounter with this problem? What is wrong with me? 3) Could I send SMS in which extension of the sender is text not integer. For example, i want to send an information SMS that this is a test network. For this purpose i want to send an SMS from 'OpenBSC'. I set the extension of the first subscriber in database as text and tried to send the SMS but SMS wasn't delivered. What should i do? 4) Can i add SMS externally to SMS table of database? Thanks. Jason

11 years, 4 months

4
3
0 0

Re: Recording / Re: Regular Osmocom meeting in Berlin?

by Katrin Verclas

It was my understanding from your suggestion that there would be presentations and discussions after those presentations at the meetings, making this not just having a beer with friends but more formal affairs. That would be useful for people elsewhere to see, given that this is a global community. Not sure what German law has to do with putting online or streaming such presentations. Cameras off when it comes to the informal part and beer time.. Love this list otherwise. And will come to Berlin this summer so may attend one or two, regardless :) Cheers from New York. K ------Original Message------ From: Harald Welte To: Katrin Verclas Cc: Holger Hans Peter Freyther Cc: Akib Sayyed Cc: baseband-devel(a)lists.osmocom.org Cc: openbsc(a)lists.osmocom.org Subject: Recording / Re: Regular Osmocom meeting in Berlin? Sent: Mar 31, 2012 8:01 AM Hi Katrin, On Fri, Mar 30, 2012 at 07:17:17PM +0000, Katrin Verclas wrote: > Could not disagree more. We live-stream local events all the time with > a very unobtrusive webcam/ustream and it bothers no one who is there > but benefits all who are not. And I couldn't disagree more with you. The mere existance of the two words 'camera' and 'unobtrusive' in one sentence are a contradiction in terms. If I want to meet with a small group of people and informally discuss technical topic, than that is _very_ different from being live streamed to an unknonwn number of people, any of which could make recordings and I would have to very carefully think about each and every word that I'm saying. That's not a particularly relaxed environment and would kill all the fun there is in having the meeting in the first place. Legally, In Germany this corresponds to "not publicly spoken word" (nicht oeffentlich gesprochenes Wort). It is punishable under law to record or broadcast that. (Clause 201 of German criminal code). 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) Sent via mobile. Hence, short.

12 years

2
1
0 0

Re: Regular Osmocom meeting in Berlin?

by Katrin Verclas

Could not disagree more. We live-stream local events all the time with a very unobtrusive webcam/ustream and it bothers no one who is there but benefits all who are not. Best, Katrin ------Original Message------ From: Holger Hans Peter Freyther Sender: baseband-devel-bounces(a)lists.osmocom.org To: Akib Sayyed Cc: baseband-devel(a)lists.osmocom.org Cc: openbsc(a)lists.osmocom.org Subject: Re: Regular Osmocom meeting in Berlin? Sent: Mar 30, 2012 3:13 PM On 03/30/2012 07:27 PM, Akib Sayyed wrote: > even i am in.people who cannot participate please make some > arrangement for them like live streaming and chat support. > <http://www.ustream.tv/ support free live streaming> Hi, I don't think this is a good idea. It kills the local atmosphere without having any real benefit. Every decision/code and most likely slides will be public anyway. z. Sent via mobile. Hence, short.

12 years

3
2
0 0

Regular Osmocom meeting in Berlin?

by Harald Welte

Hi all, I was pondering to start a regular Osmocom meeting (monthly or bi-weekly) in Berlin. The idea would be not only to converge the existing developers in Berlin (zecke, roh, prom, tobias, peter, kevin, myself, ...) but to also try to share some knowledge and excitement with other interested hackers in the wider community. A split format for the event might make sense: Have a more or less organized 45min talk about one particular topic + 15min discussion and then switch to an informal meeting style without any particular topic or moderator. For the first half there is a long list of topics intended at informing people about the status and capabilities of the respective projects: OsmocomBB, OsmoTETRA, OsmoGMR, SIMtrace, etc. Regarding the venue, I would suggest to hold it at the Berlin CCC. What do you generally think about this? What day of the week should we be aiming at? Tuesday and Thursday is generally not a good idea, as those are already occupied with other events. If you think it's a good idea, I would request/register the event with the CCC Berlin. 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)

12 years

9
8
0 0

Re: Regular Osmocom meeting in Berlin?

by Zsombor

Can you record the video about the presentations and upload to some video sharing site ? I'm certain, that there would be some interest watching it :) Thanks, Zsombor On 2012.03.30. 13:33, "Tobias Engel" <t-openbsc(a)tobias.org> wrote: On 29.03.2012 21:41, Peter Stuge wrote: > Harald Welte wrote: >> I was pondering to start a regular ... I would say monthly is more realistic. But I'm also fine with bi-weekly. >> What day of the week should we be aiming at? > > I like Wednesday. Me too. -Tobias

12 years

1
0
0 0

Call for participation LSM/RMLL

by Mathias Coinchon

Dear Osmocom community, This email to inform you that the call for participation for the next Libre Software Meeting (LSM or RMLL: Rencontres Mondiales du Logiciel Libre) ends on 31st March: http://2012.rmll.info/en/participate/call-for-papers This edition will take place in Geneva from 7th to 12th July 2012 (7-8 general public days, 9-12 theme focused, professional). It would be of great interest for the communities to learn about the Osmocom projects in presentations or workshop. Real world applications would be interesting too. So please don't hesitate to directly submit. Don't hesitate also to contact me for more information. Mathias Coinchon

12 years

1
0
0 0

Question regarding timeouts and RRLP

by Refik Hadzialic

Dear group members, I would like to ask you a question regarding the timeouts and initiating/allocating an SDCCH channel for a subscriber inside of the GSM network. I am trying to modify some parts of OpenBSC (/openbsc/src/libmsc/rrlp.c) and to implement the MS-based RRLP in OpenBSC (to send assistance data in form of almanac, ephemeris, BTS geolocation data and GPS reference time to the MS). At the moment I use the silent sms to start an RRLP request (send RRLP request + assistance data and then send the silent sms). But if it takes too long to send the assistance data OpenBSC starts from the beginning (send rrlp request + assistance data + sms again). I think this is because OpenBSC waits for an ack from the MS for the silent sms (which has not been sent) and therefore it's a timeout issue. As a quick hack I have modified parts of the code and got the RRLP to work (sent successfully these data and I got a position from the MS). Just for the curious one, I commented out three lines just before the return, in /openbsc/src/libmsc/gsm_04_11.c in the function, gsm411_rx_rp_ack, the following lines: //else //gsm411_release_conn(trans->conn); /* free the transaction here */ //trans_free(trans); and I changed one timer value from 10 to 100, in /openbsc/src/libbsc/bsc_rll.c in the function, rll_establish to: osmo_timer_schedule(&rllr->timer, 100, 0);. As I know what I did was wrong (since changing the timers and not releasing the channel properly influences the whole system) but I just did it for the purpose of testing and to see do I send correct data and does the RRLP work at all. I hope you can give me some hints and guides how to allocate a channel for around 130 seconds and to send the RRLP assistance data within that channel without doing the above tricks. Once everything works properly I will provide the RRLP code. Best regards, Refik Hadzialic

12 years

1
0
0 0

Generate html with coverage info for osmocom

by Holger Hans Peter Freyther

Hi All, I wrote this very simple script to build a bit of osmocom with coverage info, run the tests and use the lcov utility to create html. I am too lazy to upload the result somewhere right now. holger

12 years, 1 month

1
1
0 0

[PATCH] ofono: add support for Wavecom Q2403 modem

by pablo＠gnumonks.org

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> Hi! Harald and me have been working on getting Wavecom Q2403 modem working with ofono. I promise to submit this to ofono mainstream at some point. It includes the udev configuration (see 80-ofono-wavecom.rules). Pablo Neira Ayuso (1): ofono: add support for Wavecom Q2403 modem 80-ofono-wavecom.rules | 6 ++ Makefile.am | 3 + acinclude.m4 | 2 +- drivers/atmodem/sim.c | 8 ++ drivers/atmodem/sms.c | 31 ++++++- drivers/atmodem/vendor.h | 1 + gatchat/gatchat.c | 3 +- plugins/udev.c | 2 + plugins/wavecom_q.c | 192 ++++++++++++++++++++++++++++++++++++++++++++++ 9 files changed, 241 insertions(+), 7 deletions(-) create mode 100644 80-ofono-wavecom.rules create mode 100644 plugins/wavecom_q.c -- 1.7.2.5

12 years, 1 month

1
1
0 0

Supplementary Services / Call Waiting in openbsc

by Tobias Engel

Hi, I pushed the branches tobias/supplementary_services to libosmocore and openbsc repositories. The idea is to enhance openbsc to be able to provide Supplementary Services other than USSD. I tried to implement activation, deactivation and interrogation in a generic way. Registration is not yet implemented, also handling of different teleservices is missing (Everything will be treated as requested for "Telephony"). Call Waiting is now implemented on top of those changes (it is one of the SS that doesn't need registration). (De-)Activation and interrogation can be triggered from the phone using either the menu or the MMI codes *43#, #43# and *#43# (see GSM 02.30). So a call to a subscriber will now only proceed if said subscriber isn't busy or CW has been provisioned and activated. (For details see the commit messages.) I know this isn't the most sexy new feature, but I needed it to test something and maybe somebody wants to implement other supplementary services like call forwarding... -Tobias

12 years, 1 month

1
0
0 0

OsmoDevCon video recording

by Alexander Chemeris

Hi all, On Tue, Feb 21, 2012 at 11:54, Harald Welte <laforge(a)gnumonks.org> wrote: > On Tue, Feb 21, 2012 at 08:10:35AM +0100, Sylvain Munaut wrote: >> As for live audio/video stream, I would suggest it's a bit of a >> complication we don't need. We could just do recordings and upload >> them publically or not afterwards depending on the speaker choice. > > that might be an idea, but in fact it would be better to have the > speaker be able to decide not to be recorded in the first place ;) > > Rule number one of data protection: Don't even create/store data that > you don't require to store... (German: "Datensparsamkeit") Following up on this, it seems to me that there is an agreement that we want to record talks where speaker doesn't object against recording. So, I'll try to get a good FullHD camera today and bring it to the conference, but we also need a tripod for a good quality recording. Is there anyone local who could bring one? We don't want to bring one from Moscow. :) -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

12 years, 1 month

1
1
0 0

LAPD sequence error issues while bootstrapping RBS2308

by Pablo Neira Ayuso

Hi Andreas, I'm having some problems while bootstrapping RBS2308 with the existing code. I think it is related to LAPD sequence number checkings: lapd.c:595 TX: 02 01 02 00 0c 11 01 80 1e 02 27 17 59 06 0 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 dahdi.c:248 dahdi TX (TS=1): 37 bytes lapd_core.c:1832 msg-len 31 sent 31 left 0 N201 260 t byte 0c lapd.c:345 RX: 02 01 01 04 lapd_core.c:1256 RR received in state LAPD_STATE_MF_EST lapd_core.c:739 ack frame 1 lapd_core.c:216 stop T200 lapd_core.c:208 start T203 lapd_core.c:1780 lapd_send_i() called from line 1294 lapd.c:345 RX: 00 01 02 04 10 1c 1a 02 62 11 1c 11 01 80 lapd_core.c:1463 I received in state LAPD_STATE_MF_EST lapd_core.c:1512 N(S) sequence error: N(S)=1, V(R)=0 ^^^^^^^^^^^^^^ It seems to me that the BSC transmits data while something is still coming from the BTS. Then, BSC's LAPD code silently drops the message (without rejection). Just a bit later the BSC gets a rejection from BTS's RSL layer. lapd.c:595 TX: 00 01 09 00 dahdi.c:248 dahdi TX (TS=1): 6 bytes lapd_core.c:224 stop T203 lapd_core.c:208 start T203 lapd_core.c:1780 lapd_send_i() called from line 1538 lapd.c:345 RX: 00 01 00 04 10 1c 1a 02 62 11 1c 11 01 80 lapd_core.c:1463 I received in state LAPD_STATE_MF_EST lapd_core.c:1546 incrementing V(R) to 1 lapd_core.c:224 stop T203 lapd_core.c:208 start T203 lapd_core.c:1555 message in single I frame abis_rsl.c:1128 (bts=0,trx=0) ERROR REPORT CAUSE=0x62(Message Sequence Error) So the bootstrapping process never ends and the BTS never comes up. Let me know if you can provide any clue to resolve this issue. Thanks!

12 years, 1 month

2
1
0 0

"Osmo-USRP": combining OpenBTS and Osmocom

by Thomas Cooper

Hey all, I've been working on connecting OpenBTS and osmo-bts ever since Harald formed the openbts-osmo repo (http://cgit.osmocom.org/cgit/openbts-osmo) and left me with a nice muxer framework and L1-L2 separation. I've named it Osmo-USRP but you can call it openbts-osmo or TrueBTS or whatever; it's not a big deal. Unfortunately I'm running short on time for completing my MS research, so testing is nowhere near complete but I figured I'd let the public users help me out a bit here if they want to try it out. Many thanks to Tom Tsou for helping me weed out bugs and test too. I've only scratched the surface of testing it with USRP1, USRP2, single vs. multiple PCs (Ubuntu and Fedora), and multiple BTSs. I've been able to get a stable network of 1 and 2 BTSs across 2 PCs with multiple MSs camped, and voice calls and SMS working. There seem to be a few fickle and unknown issues depending on which PC/Linux flavors/time of day I tested, and of course sometimes it will work for a certain MS but not another. Sometimes MSs won't location update to the network, or will hit errors when establishing a call; in the usual case, this won't even free the TCH so if resources run out the BTS must be rebooted. Just a few issues to name here, and I'm sure there are more out there. The current focus of work (when I can find time) is implementing handover between cells. I'm not even sure if osmo-bts and OpenBTS contain all the supporting functionality for handover (OpenBSC does though). The MSs correctly send SACCH meas reports, the BSC detects and decides to handover, and the TCH is activated, but I think the Handover Command is getting lost in the BTS or the MS Handover Accept bursts are being processed. The newly activated osmo-bts instance segfaults somewhere in LAPDm. I haven't had time lately to pinpoint the error, but just wanted to update on the current status of that. Also, multiple configuration files are needed because I have network parameters hard-coded (just for ease), which is elaborated some in the wiki. I ran into a segfault/bug trying to implement passing in config parameters from OpenBSC, and gave up to pursue more critical aspects of the project. Github repo: https://github.com/tacooper (first release tag for Osmo-USRP = v0.1) README/Guide: https://github.com/tacooper/Osmo-USRP/downloads (issues, configuration, and example setup for single/multi-BTS networks) If you'd like to help out by testing or even working on this project, it is much appreciated, even if only to help me grow my understanding of GSM networks through discussion. Thanks! Tom Cooper

12 years, 1 month

3
4
0 0

[PATCH 9/9] Fixed problem of mute audio on some calls

by Andreas Eversberg

When reading from RTP socket, the first read() may fail right after connecting to remote socket. Subsequent read() will work as it should. If the remote socket does not open fast enough, the transmitted RTP payload can cause an ICMP (connection refused) packet reply. This causes the read to fail with errno=111. In all other error cases, the errno is logged at debug level. In all error cases, reading is not disabled. --- openbsc/src/libtrau/rtp_proxy.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 88753b6..23d0d1d 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -503,9 +503,16 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss) return -ENOMEM; rc = read(rss->bfd.fd, msg->data, RTP_ALLOC_SIZE); - if (rc <= 0) { - rss->bfd.when &= ~BSC_FD_READ; - return rc; + if (rc == 0) + goto out_free; + if (rc < 0) { + /* Ignore "connection refused". this happens, If we open the + * socket faster than the remove side. */ + if (errno == ECONNREFUSED) + goto out_free; + DEBUGPC(DLMUX, "Read of RTP socket (%p) failed (errno %d, " + "%s)\n", rs, errno, strerror(errno)); + goto out_free; } msgb_put(msg, rc); -- 1.8.1.5 --------------060407040809040206020102--

12 years, 1 month

1
0
0 0

[PATCH 9/9] Fixed problem of mute audio on some calls

by Andreas Eversberg

When reading from RTP socket, the first read() may fail right after connecting to remote socket. Subsequent read() will work as it should. If the remote socket does not open fast enough, the transmitted RTP payload can cause an ICMP (connection refused) packet reply. This causes the read to fail with errno=111. In all other error cases, the errno is logged at debug level. In all error cases, reading is not disabled. --- openbsc/src/libtrau/rtp_proxy.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 88753b6..bb158e8 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -503,9 +503,16 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss) return -ENOMEM; rc = read(rss->bfd.fd, msg->data, RTP_ALLOC_SIZE); + if (rc == 0) + goto out_free; if (rc <= 0) { - rss->bfd.when &= ~BSC_FD_READ; - return rc; + /* Ignore "connection refused". this happens, If we open the + * socket faster than the remove side. */ + if (errno == 111) + return 0; + DEBUGPC(DLMUX, "Read of RTP socket (%p) failed (errno %d)\n", + rs, errno); + goto out_free; } msgb_put(msg, rc); -- 1.8.1.5 --------------050303020108080701030307--

12 years, 1 month

1
0
0 0

Unknown payload type on OpenBSC when using rtp-bridge on LCR

by Nik Pakar

Hi Andreas, After some extensive testing i have done using jolly/rtpmux branch to get rtp to go directly between bsc and softswitch (yate in this case) i came across following scenario. MO call goes to OpenBSC/LCR then to yate routed back to OpenBSC/LCR and MT. Signalling seems all fine including codec negotiating as through out the path AMR/96 is been negotiated well. But once call connected, no rtp stream exist and i see following error on OpenBSC. received RTP frame with unknown payload type 98 Full topology and logs/trace from openbsc, LCR and yate is on this attachment. What could be the reason for bsc to get payload type 98. http://pastebin.com/rPfMamx0 Rgds Nik

12 years, 1 month

3
2
0 0

Compiling LCR for OpenBSC

by Nik Pakar

Do I have to have mISDN for LCR even im not going to use any isdn interface ? Im trying to connect the NITB to LCR and LCR to asterisk all on ip. Thanks for any help. Rgds Nik

12 years, 1 month

8
29
0 0

study on openbsc

by Kwan

Hello, I am a student from Hong Kong and I take a project about openbsc. I have a BTS that product from interWave. I contacted interWave engineer and he said he can borrow us the E1 card to connect BTS. But I don't know how to make openbsc to support this BTS. I can provide some detail about this BTS if you need. Thank, Kwan

12 years, 1 month

2
3
0 0

nanoBTS behind NAT

by Nik Pakar

Dear all, will the openbsc setup works with nanoBTSs sitting behind a NAT ? Rgds Nik

12 years, 1 month

5
10
0 0

[PATCH] Add support for AMR frames to MNCC/RTP interface

by Andreas Eversberg

AMR rate is currently fixed to 5.9k. --- openbsc/src/libmsc/gsm_04_08.c | 1 + openbsc/src/libtrau/rtp_proxy.c | 53 ++++++++++++++++++++++++++++++++++++----- 2 files changed, 48 insertions(+), 6 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index df93433..a0650ab 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -2953,6 +2953,7 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg) case GSM_TCHF_FRAME: case GSM_TCHF_FRAME_EFR: case GSM_TCHH_FRAME: + case GSM_TCH_FRAME_AMR: /* Find callref */ trans = trans_find_by_callref(net, data->callref); if (!trans) { diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 143bfa0..95729ef 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -192,21 +192,41 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data) return -EINVAL; } break; + case RTP_PT_AMR: + break; default: DEBUGPC(DLMUX, "received RTP frame with unknown payload " "type %d\n", rtph->payload_type); return -EINVAL; } - new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + payload_len, - "GSM-DATA"); + if (payload_len > 33) { + DEBUGPC(DLMUX, "RTP payload too large (%d octets)\n", + payload_len); + return -EINVAL; + } + + if (rtph->payload_type == RTP_PT_AMR) { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + 1 + + payload_len, "GSM-DATA (AMR)"); + } else { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + + payload_len, "GSM-DATA"); + } if (!new_msg) return -ENOMEM; frame = (struct gsm_data_frame *)(new_msg->data); frame->msg_type = msg_type; frame->callref = callref; - memcpy(frame->data, payload, payload_len); - msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + if (rtph->payload_type == RTP_PT_AMR) { + frame->data[0] = payload_len; + msgb_put(new_msg, sizeof(struct gsm_data_frame) + 1 + + payload_len); + memcpy(frame->data + 1, payload, payload_len); + } else { + msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + memcpy(frame->data, payload, payload_len); + } *data = new_msg; return 0; @@ -264,6 +284,11 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) payload_len = RTP_LEN_GSM_HALF; duration = RTP_GSM_DURATION; break; + case GSM_TCH_FRAME_AMR: + payload_type = RTP_PT_AMR; + payload_len = frame->data[0]; + duration = RTP_GSM_DURATION; + break; default: DEBUGPC(DLMUX, "unsupported message type %d\n", frame->msg_type); @@ -291,7 +316,18 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) } } - msg = msgb_alloc(sizeof(struct rtp_hdr) + payload_len, "RTP-GSM-FULL"); + if (payload_len > 33) { + DEBUGPC(DLMUX, "RTP payload too large (%d octets)\n", + payload_len); + return -EINVAL; + } + + if (frame->msg_type == GSM_TCH_FRAME_AMR) + msg = msgb_alloc(sizeof(struct rtp_hdr) + payload_len, + "RTP-GSM (AMR)"); + else + msg = msgb_alloc(sizeof(struct rtp_hdr) + payload_len, + "RTP-GSM"); if (!msg) return -ENOMEM; rtph = (struct rtp_hdr *)msg->data; @@ -305,7 +341,12 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rtph->timestamp = htonl(rs->transmit.timestamp); rs->transmit.timestamp += duration; rtph->ssrc = htonl(rs->transmit.ssrc); - memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, payload_len); + if (frame->msg_type == GSM_TCH_FRAME_AMR) + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data + 1, + payload_len); + else + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, + payload_len); msgb_put(msg, sizeof(struct rtp_hdr) + payload_len); msgb_enqueue(&rss->tx_queue, msg); rss->bfd.when |= BSC_FD_WRITE; -- 1.8.1.5 --------------040208000603050009060705--

12 years, 1 month

1
0
0 0

[PATCH] Add support for AMR frames to MNCC/RTP interface

by Andreas Eversberg

AMR rate is currently fixed to 5.9k. --- openbsc/src/libmsc/gsm_04_08.c | 1 + openbsc/src/libtrau/rtp_proxy.c | 35 ++++++++++++++++++++++++++++++----- 2 files changed, 31 insertions(+), 5 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index df93433..a0650ab 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -2953,6 +2953,7 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg) case GSM_TCHF_FRAME: case GSM_TCHF_FRAME_EFR: case GSM_TCHH_FRAME: + case GSM_TCH_FRAME_AMR: /* Find callref */ trans = trans_find_by_callref(net, data->callref); if (!trans) { diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 143bfa0..913d64d 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -192,21 +192,35 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data) return -EINVAL; } break; + case RTP_PT_AMR: + break; default: DEBUGPC(DLMUX, "received RTP frame with unknown payload " "type %d\n", rtph->payload_type); return -EINVAL; } - new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + payload_len, - "GSM-DATA"); + if (rtph->payload_type == RTP_PT_AMR) { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + 1 + + payload_len, "GSM-DATA"); + } else { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + + payload_len, "GSM-DATA"); + } if (!new_msg) return -ENOMEM; frame = (struct gsm_data_frame *)(new_msg->data); frame->msg_type = msg_type; frame->callref = callref; - memcpy(frame->data, payload, payload_len); - msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + if (rtph->payload_type == RTP_PT_AMR) { + frame->data[0] = payload_len; + msgb_put(new_msg, sizeof(struct gsm_data_frame) + 1 + + payload_len); + memcpy(frame->data + 1, payload, payload_len); + } else { + msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + memcpy(frame->data, payload, payload_len); + } *data = new_msg; return 0; @@ -264,6 +278,11 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) payload_len = RTP_LEN_GSM_HALF; duration = RTP_GSM_DURATION; break; + case GSM_TCH_FRAME_AMR: + payload_type = RTP_PT_AMR; + payload_len = frame->data[0]; + duration = RTP_GSM_DURATION; + break; default: DEBUGPC(DLMUX, "unsupported message type %d\n", frame->msg_type); @@ -305,7 +324,13 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rtph->timestamp = htonl(rs->transmit.timestamp); rs->transmit.timestamp += duration; rtph->ssrc = htonl(rs->transmit.ssrc); - memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, payload_len); + if (frame->msg_type == GSM_TCH_FRAME_AMR) { + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data + 1, + payload_len); + } else { + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, + payload_len); + } msgb_put(msg, sizeof(struct rtp_hdr) + payload_len); msgb_enqueue(&rss->tx_queue, msg); rss->bfd.when |= BSC_FD_WRITE; -- 1.8.3.2 --------------090303090405010206070901--

12 years, 1 month

1
0
0 0

[PATCH 8/9] Fixed (ipaccess BTS) delay/silence problems, if RTP stream jitters too much

by Andreas Eversberg

After OpenBSC stalled for some reason (e.g. CPU overload or database access) or after speech frames have been lost (MNCC application problems / hold/retrieve call), the timestamp and the sequence number of the RTP socket state must be corrected. The amount of incrmentation is calculated from the elapsed time. Not incrementing timestamp and sequence number would cause all frames to be dropped by ipaccess BTS, because the BTS expects frames with more recent timestamps. If speech frames are received too fast, they must be dropped. The timestamp and sequence number of the RTP socket state are not changed in this case. Incmenetating timestamp and sequence number would causes high delay at ipaccess BTS, because the BTS would queue the frames until the timestamp matches the current time. There is a simple test case: Make a call between two phones and check the delay. (When using LCR, make a call to the echo test.) The press CTRL+z to suspend OpenBSC process for a few seconds and enter "fg" to continue OpenBSC process. There shall be no change in the delay, even after repeating this test many times. --- openbsc/src/libtrau/rtp_proxy.c | 89 +++++++++++++++++++++++++++-------------- 1 file changed, 60 insertions(+), 29 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 0c4d82b..fa6b629 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -236,19 +236,65 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data, in return 0; } -/* "to - from" */ -static void tv_difference(struct timeval *diff, const struct timeval *from, - const struct timeval *__to) +#define USEC_1S 1000000 +#define USEC_10MS 10000 +#define USEC_20MS 20000 +#define SAMPLES_1S 8000 +#define USEC_SAMPLE 125 + +/* add usec to tv */ +static void tv_add_usec(struct timeval *tv, long int usec) { - struct timeval _to = *__to, *to = &_to; + struct timeval tv_add; - if (to->tv_usec < from->tv_usec) { - to->tv_sec -= 1; - to->tv_usec += 1000000; + tv_add.tv_sec = usec / USEC_1S; + tv_add.tv_usec = usec % USEC_1S; + timeradd(tv, &tv_add, tv); +} + +static int correct_timestamp(struct rtp_socket *rs, int duration) +{ + struct timeval tv, tv_diff; + long int usec_diff, frame_diff; + int usec_duration = duration * USEC_SAMPLE; + + gettimeofday(&tv, NULL); + timersub(&tv, &rs->transmit.last_tv, &tv_diff); + + usec_diff = tv_diff.tv_sec * USEC_1S + tv_diff.tv_usec; + frame_diff = (usec_diff + (usec_duration >> 1)) / usec_duration; /* round */ + + /* Drop frame, if current time to too much in advance of the last_tv. + * < 0 means that the time difference in frames must be at lease 2 + * frames below the expected difference of 1. + */ + if (frame_diff < 0) + return -1; + + /* Increment last_tv by the duration of one frame. */ + tv_add_usec(&rs->transmit.last_tv, usec_duration); + + /* Increment last_tv, if the current time is too much afterwards. + * Also increment timestamp and sequence number of RTP socket state. + * > 2 means that the time difference in frames must be at least 2 + * frames above the expected difference of 1. + */ + if (frame_diff > 2) { + long int frame_diff_excess = frame_diff - 1; + long int sample_diff_excess = frame_diff_excess * duration; + + /* correct last_tv */ + tv_add_usec(&rs->transmit.last_tv, + sample_diff_excess * USEC_SAMPLE); + LOGP(DLMUX, LOGL_NOTICE, + "Correcting timestamp difference of %ld frames " + "(to %s)\n", frame_diff_excess, + (rs->rx_action == RTP_RECV_APP) ? "app" : "BTS"); + rs->transmit.sequence += frame_diff_excess; + rs->transmit.timestamp += sample_diff_excess; } - diff->tv_usec = to->tv_usec - from->tv_usec; - diff->tv_sec = to->tv_sec - from->tv_sec; + return 0; } /*! \brief encode and send a rtp frame @@ -265,6 +311,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) int duration; /* in samples */ int is_amr = 0, is_bfi = 0; uint8_t dynamic_pt = 0; + int rc; if (rs->rx_action == RTP_RECV_APP) dynamic_pt = rs->receive.payload_type; @@ -275,6 +322,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rs->transmit.ssrc = rand(); rs->transmit.sequence = random(); rs->transmit.timestamp = random(); + gettimeofday(&rs->transmit.last_tv, NULL); } switch (frame->msg_type) { @@ -311,26 +359,9 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) return -EINVAL; } - { - struct timeval tv, tv_diff; - long int usec_diff, frame_diff; - - gettimeofday(&tv, NULL); - tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); - rs->transmit.last_tv = tv; - - usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec; - frame_diff = (usec_diff / 20000); - - if (abs(frame_diff) > 1) { - long int frame_diff_excess = frame_diff - 1; - - LOGP(DLMUX, LOGL_NOTICE, - "Correcting frame difference of %ld frames\n", frame_diff_excess); - rs->transmit.sequence += frame_diff_excess; - rs->transmit.timestamp += frame_diff_excess * duration; - } - } + rc = correct_timestamp(rs, duration); + if (rc) + return 0; if (is_bfi) { /* In case of a bad frame, just count and drop packt. */ -- 1.8.1.5 --------------070804050601000205010809--

12 years, 1 month

1
0
0 0

[PATCH 8/9] Fixed (nanoBTS) delay problems, if RTP stream jitters too much

by Andreas Eversberg

The RTP stream is generated or forwarded by OpenBSC to nanoBTS. Due to switching of streams (hold/retrieve call), packet loss or even stalling of sender's process, the time stamp must be corrected. If outdated packets are received, they get dropped. --- openbsc/src/libtrau/rtp_proxy.c | 82 ++++++++++++++++++++++++++++++----------- 1 file changed, 61 insertions(+), 21 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 2284798..88753b6 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -236,6 +236,12 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data, in return 0; } +#define USEC_1S 1000000 +#define USEC_10MS 10000 +#define USEC_20MS 20000 +#define SAMPLES_1S 8000 +#define USEC_SAMPLE 125 + /* "to - from" */ static void tv_difference(struct timeval *diff, const struct timeval *from, const struct timeval *__to) @@ -244,13 +250,62 @@ static void tv_difference(struct timeval *diff, const struct timeval *from, if (to->tv_usec < from->tv_usec) { to->tv_sec -= 1; - to->tv_usec += 1000000; + to->tv_usec += USEC_1S; } diff->tv_usec = to->tv_usec - from->tv_usec; diff->tv_sec = to->tv_sec - from->tv_sec; } +/* add sec,usec to tv */ +static void tv_add(struct timeval *tv, int sec, int usec) +{ + + while (usec < 0) { + usec += USEC_1S; + sec--; + } + tv->tv_sec += sec; + tv->tv_usec += usec; + while (tv->tv_usec >= USEC_1S) { + tv->tv_sec++; + tv->tv_usec -= USEC_1S; + } +} + +static int correct_timestamp(struct rtp_socket *rs, int duration) +{ + struct timeval tv, tv_diff; + long int usec_diff, frame_diff; + + gettimeofday(&tv, NULL); + tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); + tv_add(&rs->transmit.last_tv, 0, USEC_20MS); + + usec_diff = tv_diff.tv_sec * USEC_1S + tv_diff.tv_usec; + frame_diff = ((usec_diff + (USEC_10MS)) / USEC_20MS); /* round */ + + if (abs(frame_diff - 1) > 1) { + long int frame_diff_excess = frame_diff - 1; + long int sample_diff_excess = frame_diff_excess * duration; + + /* correct last_tv */ + tv_add(&rs->transmit.last_tv, sample_diff_excess / SAMPLES_1S, + (sample_diff_excess % SAMPLES_1S) * USEC_SAMPLE); + /* drop frame, if time stamp is in the past */ + if (frame_diff_excess < 0) + return -1; + LOGP(DLMUX, LOGL_NOTICE, + "Correcting timestamp difference of %ld frames " + "(to %s)\n", frame_diff_excess, + (rs->rx_action == RTP_RECV_L4) ? "app" : "BTS"); + rs->transmit.sequence += frame_diff_excess; + rs->transmit.timestamp += sample_diff_excess; + } + + return 0; +} + /*! \brief encode and send a rtp frame * \param[in] rs RTP socket through which we shall send * \param[in] frame GSM RTP frame to be sent @@ -265,6 +320,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) int duration; /* in samples */ int amr = 0; uint8_t dynamic_pt = 0; + int rc; if (rs->rx_action == RTP_RECV_L4) dynamic_pt = rs->receive.payload_type; @@ -275,6 +331,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rs->transmit.ssrc = rand(); rs->transmit.sequence = random(); rs->transmit.timestamp = random(); + gettimeofday(&rs->transmit.last_tv, NULL); } switch (frame->msg_type) { @@ -313,26 +370,9 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) return -EINVAL; } - { - struct timeval tv, tv_diff; - long int usec_diff, frame_diff; - - gettimeofday(&tv, NULL); - tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); - rs->transmit.last_tv = tv; - - usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec; - frame_diff = (usec_diff / 20000); - - if (abs(frame_diff) > 1) { - long int frame_diff_excess = frame_diff - 1; - - LOGP(DLMUX, LOGL_NOTICE, - "Correcting frame difference of %ld frames\n", frame_diff_excess); - rs->transmit.sequence += frame_diff_excess; - rs->transmit.timestamp += frame_diff_excess * duration; - } - } + rc = correct_timestamp(rs, duration); + if (rc) + return 0; if (frame->msg_type == GSM_BAD_FRAME) return 0; -- 1.8.1.5 --------------000504080100090805040102--

12 years, 1 month

1
0
0 0

[PATCH 8/9] Fixed (nanoBTS) delay problems, if RTP stream jitters too much

by Andreas Eversberg

The RTP stream is generated or forwarded by OpenBSC to nanoBTS. Due to switching of streams (hold/retrieve call), packet loss or even stalling of sender's process, the time stamp must be corrected. If outdated packets are received, they get dropped. --- openbsc/src/libtrau/rtp_proxy.c | 80 ++++++++++++++++++++++++++++++----------- 1 file changed, 59 insertions(+), 21 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index ed7479d..3e6c462 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -236,6 +236,12 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data, in return 0; } +#define USEC_1S 1000000 +#define USEC_10MS 10000 +#define USEC_20MS 20000 +#define SAMPLES_1S 8000 +#define USEC_SAMPLE 125 + /* "to - from" */ static void tv_difference(struct timeval *diff, const struct timeval *from, const struct timeval *__to) @@ -244,13 +250,60 @@ static void tv_difference(struct timeval *diff, const struct timeval *from, if (to->tv_usec < from->tv_usec) { to->tv_sec -= 1; - to->tv_usec += 1000000; + to->tv_usec += USEC_1S; } diff->tv_usec = to->tv_usec - from->tv_usec; diff->tv_sec = to->tv_sec - from->tv_sec; } +/* add sec,usec to tv */ +static void tv_add(struct timeval *tv, int sec, int usec) +{ + + if (usec < 0) + usec += USEC_1S; + tv->tv_sec += sec; + tv->tv_usec += usec; + if (tv->tv_usec >= USEC_1S) { + tv->tv_sec++; + tv->tv_usec -= USEC_1S; + } +} + +static int correct_timestamp(struct rtp_socket *rs, int duration) +{ + struct timeval tv, tv_diff; + long int usec_diff, frame_diff; + + gettimeofday(&tv, NULL); + tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); + tv_add(&rs->transmit.last_tv, 0, USEC_20MS); + + usec_diff = tv_diff.tv_sec * USEC_1S + tv_diff.tv_usec; + frame_diff = ((usec_diff + (USEC_10MS)) / USEC_20MS); /* round */ + + if (abs(frame_diff - 1) > 1) { + long int frame_diff_excess = frame_diff - 1; + long int sample_diff_excess = frame_diff_excess * duration; + + /* correct last_tv */ + tv_add(&rs->transmit.last_tv, sample_diff_excess / SAMPLES_1S, + (sample_diff_excess % SAMPLES_1S) * USEC_SAMPLE); + /* drop frame, if time stamp is in the past */ + if (frame_diff_excess < 0) + return -1; + LOGP(DLMUX, LOGL_NOTICE, + "Correcting timestamp difference of %ld frames " + "(to %s)\n", frame_diff_excess, + (rs->rx_action == RTP_RECV_L4) ? "app" : "BTS"); + rs->transmit.sequence += frame_diff_excess; + rs->transmit.timestamp += sample_diff_excess; + } + + return 0; +} + /*! \brief encode and send a rtp frame * \param[in] rs RTP socket through which we shall send * \param[in] frame GSM RTP frame to be sent @@ -265,6 +318,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) int duration; /* in samples */ int amr = 0; uint8_t dynamic_pt = 0; + int rc; if (rs->rx_action == RTP_RECV_L4) dynamic_pt = rs->receive.payload_type; @@ -275,6 +329,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rs->transmit.ssrc = rand(); rs->transmit.sequence = random(); rs->transmit.timestamp = random(); + gettimeofday(&rs->transmit.last_tv, NULL); } switch (frame->msg_type) { @@ -313,26 +368,9 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) return -EINVAL; } - { - struct timeval tv, tv_diff; - long int usec_diff, frame_diff; - - gettimeofday(&tv, NULL); - tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); - rs->transmit.last_tv = tv; - - usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec; - frame_diff = (usec_diff / 20000); - - if (abs(frame_diff) > 1) { - long int frame_diff_excess = frame_diff - 1; - - LOGP(DLMUX, LOGL_NOTICE, - "Correcting frame difference of %ld frames\n", frame_diff_excess); - rs->transmit.sequence += frame_diff_excess; - rs->transmit.timestamp += frame_diff_excess * duration; - } - } + rc = correct_timestamp(rs, duration); + if (rc) + return 0; if (frame->msg_type == GSM_BAD_FRAME) return 0; -- 1.8.1.5 --------------090106010400060202050508--

12 years, 1 month

1
0
0 0

Bounce action notification

by mailman＠lists.osmocom.org

This is a Mailman mailing list bounce action notice: List: OpenBSC Member: philip.lansink(a)lan-consult.nl Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

12 years, 1 month

1
0
0 0

Information about OpenBsc

by Ludovic Fotso

Hello, My Name is Tassy Fotso, I study communication Technologies in Higher Institut of Sahel (Cameroon).please How can I do to get OpenBSC. thanks

12 years, 1 month

2
1
0 0

Smoke a CAMEL?

by Jay R. Worthington

Hi y'all, not really sure if this help on building a "full fledged hlr", but the current version 4 of yate supports the MAP part of SS7, as well as CAMEL... http://yate.null.ro/ Regards, Jay

12 years, 1 month

1
0
0 0

BSC_MGCP

by Nik Pakar

Dear all, Is this BSC_MGCP is functioning ? Is that mean Open_BSC can be act as a MGCP gateway and can control from a MGCP_CA ? Rgds Nik

12 years, 1 month

3
11
0 0

Re: GSM video lectures (en)

by thriveni

12 years, 1 month

1
0
0 0

MySQL for HLR

by Nik Pakar

Is it possible to use mysql for HLR. I can see some notes within the source. Rgds Nik

12 years, 1 month

6
10
0 0

OpenBSC-LCR integration

by Nik Pakar

When OpenBSC integrates with LCR, is it mean all call routing capabilities going to LCR including gsm-gsm on net calls. Or is it only external calls going to LCR while gsm-gsm calls routed within NITB Rgds Nik

12 years, 1 month

2
2
0 0

mISDN/lcr/asterisk compilation issues

by carcelle

Dear openbsc folks, i am following up on the osmo-nitb/ggsn/sgsn config running w/ a nanoBTS-1800. i have been trying to get mISDN/lcr to build to be able to create the chan_lcr into asterisk (i am more familiar w/ dahdi/asterisk for isdn cahnnels) though so far i am not able to get it to work : *configuration : **host : running linux debian lenny 2.6.26-2-686) **autoconf 2.61 **mISDN-1_1_9.1 (downloaded as a tarball) builds mISDN_dsp.ko but not mISDN_l1loop.ko **lcr doest not build (./configure passes) /usr/src/lcr# git-apply --verbose lcrOpenBSC.patch Checking patch gsm_bs.cpp... error: while searching for: int bts_model_nanobts_init(void); static struct log_target *stderr_target; /* timer to store statistics */ #define DB_SYNC_INTERVAL 60, 0 static struct timer_list db_sync_timer; error: patch failed: gsm_bs.cpp:39 error: gsm_bs.cpp: patch does not apply /usr/src/lcr# make (...) gcc -DWITH_GSM_BS -I./openbsc/include -I./libosmocore/include -I./openbsc -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -D_GNU_SOURCE -fPIC -c bchannel.c -o bchannel.po bchannel.c:29:31: error: mISDN/mISDNcompat.h: No such file or directory bchannel.c:30: error: 'MISDN_AF_ISDN' undeclared here (not in a function) bchannel.c:31:24: error: mISDN/q931.h: No such file or directory bchannel.c: In function 'bchannel_create': bchannel.c:148: error: 'PF_ISDN' undeclared (first use in this function) bchannel.c:148: error: (Each undeclared identifier is reported only once bchannel.c:148: error: for each function it appears in.) bchannel.c:174: error: 'AF_ISDN' undeclared (first use in this function) make[1]: *** [bchannel.po] Error 1 make[1]: Leaving directory `/usr/src/lcr' (lcr from git : commit 6e1e99808e5b1c16b00904d31f95d0b74487023e) *questions : **do i need misdn to build lcr if running a nanobts w/ Abis-over-ip ? **am i missing something in the build order ? **any packaged version of misdn for debian 2.6.26-2-686 ? thanks for your support. Xavier.

12 years, 1 month

8
19
0 0

Adding subscriber to HLR database

by Don Fanning

Does anyone have the steps/commands to add a new handset to the HLR database? I wanted to add in a new handset into my system but couldn't find the information short of opening access to the site.

12 years, 1 month

4
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2012