OpenBSC July 2010

openbsc@lists.osmocom.org

19 participants
48 discussions

[PATCH] * when comparing the coded result with the expected coded values, do not compare n bytes where n is the result of gsm_7bit_encode() but the actual length of the input string as gsm_7bit_encode() returns the number of septets not octets
by Nico Golde 19 Jul '10

19 Jul '10

--- tests/sms/sms_test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/sms/sms_test.c b/tests/sms/sms_test.c index 3742dd8..cab91ab 100644 --- a/tests/sms/sms_test.c +++ b/tests/sms/sms_test.c @@ -99,7 +99,7 @@ int main(int argc, char** argv) return -1; } - if (memcmp(coded, test_encode[i].expected, length) != 0) { + if (memcmp(coded, test_encode[i].expected, strlen(test_encode[i].expected)) != 0) { fprintf(stderr, "Encoded content does not match for %d\n", i); return -1; -- 1.7.1 --Kj7319i9nmIyA2yE--

1 0

Re: RFC about Osmcoom TCAP / MAP implementation
by mosbah abdelkader 19 Jul '10

19 Jul '10

Hello, Is the source code made public.

2 2

RFC about Osmcoom TCAP / MAP implementation
by Harald Welte 18 Jul '10

18 Jul '10

Hi! As some of you will have noticed, I've been working hard on a TCAP implementation. As this is now getting into pretty good shape, I'm looking at implementing MAP. Right now I'm trying to come up with a good design to implement both MAP client (let's say a SGSN or MSC that issues a Location Updating Request) and server applications (think of HLR receiving + processing the Loc Upd Req). The full flow of primitives can be seen in the attached diagram (which by the way was designed unsing the new gen_ladder tool from git://git.osmocom.org/gen_ladder.git). In TCAP, it is relatively hard to grasp that every message consists of a dialogue part and an (optional) collection of component parts. The dialogue and component state machines are separate but interact. Since a lot of functionality is possibly contained in one PDU, this ladder diagram does not really care about actual messages/packets, but about the sequencing of primitives. First, terminology: client: A "request-side" client like a SGSN or MSC wanting to do loc upd libmap-cl: The libosmo-map instance at the client libtcap-cl: The libosmo-tcap instance at the client [between the two libtcap instances we have the signalling link] libtcap-srv: The libosmo-tcap instance at the server libmap-srv: The libosmo-map instance at the server server: The "responder-side" server like a HLR that receives loc upd 1) MAP-OPEN primitive is sent sent from client to libosmo-map. Note that no actual packets are exchanged on the signalling linke yet! 2) two MAP-INVOKE component requests are sent to libosmo-map. They contain the actual location updating requests (two of them for two different MS) 3) MAP-DELIMITER.req primitive is issued by client to libosmo-map. At this point, a TCAP TC-BEGIN.req primitive is issued to libosmo-tcap. libosmo-tcap assembles a TCAP message consisting of a TC-BEGIN dialogue portion (including loc upd req application context) containing two TC-INVOKE components. This message is sent over the signalling link. 4) The server libosmo-tcap receives the TC-BEGIN message with two TC-INVOKE components. It issues a TC-BEGIN.indication to libosmo-map, which in turn generates a MAP-OPEN.indicatin for the server application 5) The server application checks if it supports the application context and then confirms the MAP-OPEN by a MAP-OPEN.response primitive. This primitive is "cached" at libosmo-map at that time. 6) the server libosmo-tcap sends the first TC-INVOKE.indication to libosmo-map which forwards it to the server application. the application respondes with a 'result-last' primitive that is passed up to libosmo-tcap 7) the server libosmo-tcap sends the second TC-INVOKE.indication to libosmo-map which forwards it to the server application. the application respondes with a 'result-last' primitive that is passed up to libosmo-tcap Since this TC-INVOKE.ind is flagged as 'last', libosmo-map will issue a MAP-DELIMITER.indication to the server program. 8) The server application responds with MAP-DELIMITER.request, which triggers libosmo-map to issue a TC-CONTINUE.request, which in turn triggers generating the TCAP TC-CONTINUE message containing the two TC-RESULT-Last components [...] This primitive sequencing is mandated by the combination of the ITU-T Q.77x specifications and the GSM TS 09.02 / 29.002. Now the task at hand is to decide on the software architecture and which parts have to be handled synchronously or not. It was my idea to pass everything by-value at the libosmo-tcap/libosmo-map interface. While they both keep state information, I do not want to pass any information by reference at thee inter-layer boundaries. This might cause headaches in memory management (reference counting, etc.) Another aspect is that the actual execution of the function (e.g. location updating operation) might not be finished synchronously. If the server process implements a HLR, the HLR might be implemented as on-disk storage (e.g. SQL). In that case, the MAP-INVOKE.ind containing the location update will trigger some disk access. Only once that disk access has finished, the corresponding MAP-RESULT-L.req can be generated. The rough idea would be to have a queue of those tcap<->map primitives. This way, we could have single-threaed or (with proper locking) a thread pool approach, where each thread then dequeues one primitive, processes it, and sends a response primitive once it is finished. Any feedback/comments to this proposed architecture are most welcome. 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 1

AW: LCR crashes. Please help me!
by Andreas.Eversberg 16 Jul '10

16 Jul '10

hi luca, it seems that there is a change in the API. therefore i prepared a "snapshot" at www.linux-call-router.de to be downloaded. this version of openbsc and lcr is older, but works together. as soon as the current openbsc has been tested more (channel ressource handling has changed for example), i will make it work again. regards, andreas > #0 0x0805b009 in gsm0408_rcvmsg (msg=0x864ffb8, link_id=0 '\0') at openbsc/src/bsc_api.c:111 > 111 rc = api->compl_l3(lchan->conn, msg, 0); > > The problem seems to be the variable api, which is NULL. > > (gdb) print api > $1 = (struct bsc_api *) 0x0

4 5

OpenBSC+LCR+Asterisk: I got it!
by Luca Bertoncello 14 Jul '10

14 Jul '10

Hi, List! I got it! Now can I call mobile phones with Asterisk. If someone is interested, the problem was in the Asterisk-configuration (from HowTo). To use in extensions.conf is: [btsctrl] exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4) exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)}) exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG}) exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120) So can I define a prefix (02) for mobiles and forward the calls to LCR. Maybe help someone other having my problem. I suggest Andreas Everberg to update his HowTo... And now the next problem: calling a VoIP-phone from mobile phone... :) I'll get it, too! Bye -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

1 0

Re: [BUG REPORT]: Unable to send SMS
by Dieter Spaar 14 Jul '10

14 Jul '10

Hello Luca, On Wed, 14 Jul 2010 11:22:05 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote: > > I can confirm, that "neci 1" solve my problem! > I can call and send SMS without any problem, from the NE110, too! Great to hear that. I am not sure how well OpenBSC is tested with NECI set to "1" but I guess it should not cause too many problems, its only the channel allocator which behaves differently. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: [BUG REPORT]: Unable to send SMS
by Dieter Spaar 14 Jul '10

14 Jul '10

Hello Holger, On Wed, 14 Jul 2010 17:52:51 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > maybe I was too blind and didn't see it in GSM 04.08, but setting NECI=1 > will not allow us to assign a TCH/F for MO Call. What about this: 0100xxxx Originating speech call from dual-rate mobile station when TCH/H is sufficient and supported by the MS for speech calls and the network sets NECI bit to 1 At least this is what the Nokia 3310 uses for a voice call. OpenBSC should than allocate a TCH for it. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: [BUG REPORT]: Unable to send SMS
by Dieter Spaar 14 Jul '10

14 Jul '10

Hello Harald, On Tue, 13 Jul 2010 16:06:55 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > The Netzing NE110 (as well as other MTK phones) seem to have a bug in > their MO-SMS code. Dieter has told me he is looking at a workaround to this > (by sending dummy authentication request/response), and he will e-mail this > list once he has some results. This was a tough one. I tried Authentication and Ciphering commands in various combinations without any success. Finally I changed the allocated channel to SDCCH instead of TCH. And voila, it worked, even without Authentication and/or Ciphering. So it seems that there is a problem with MTK phones (and maybe others) and MO-SMS on a TCH channel. I am not sure yet if there is a workaround to solve this and still use the TCH. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

Re: [BUG REPORT]: Unable to send SMS
by Dieter Spaar 14 Jul '10

14 Jul '10

Hello Holger, On Wed, 14 Jul 2010 14:56:27 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > do you remember which kind of channel the phone is requesting? is it > really asking for a channel for calls? Yes, the phone always sets the mask according to this (from the spec): 111xxxxx Originating call and TCH/F is needed, or originating call and the network does not set NECI bit to 1, or procedures that can be completed with a SDCCH and the network does not set NECI bit to 1 This was the same for other phones, not just MTK based phones. NECI was set to 0, however I think that setting NECI to 1 might be the solution for the problem, without the need to change the Very Early Assignment procedure. I have not yet tested this in detail, so I might miss something. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: [BUG REPORT]: Unable to send SMS
by Dieter Spaar 14 Jul '10

14 Jul '10

Hello Luca, On Wed, 14 Jul 2010 10:04:05 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote: > > Wow! It works! And I can send SMS with the NE110 phones too! > Maybe could it be a solution to set lctype to GSM_LCHAN_SDCCH if the > phone tried to send an SMS? Harald probably knows the details better, but the basic problem is that the phone does not tell you exactly what channels it needs when it sends the Channel Request, at least if NECI is set to 0 (new establishment causes are not supported). So the channel allocator allocates a TCH channel, to be able to handle everything (SMS and Voice). One solution for this is to switch from Very Early Assignment to other assignment procedures. I think Holger and Harald have plans to support this. However there also seems to be a different solution: You can set NECI to 1, this way the phone can tell you in more detail what it wants. I have not done extensive tests, but it seems that this could solve the problem without the need to change the code. You just have to set "neci 1" in the OpenBSC configuration file. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2010