From laforge at gnumonks.org  Thu Jan  5 12:17:56 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 5 Jan 2012 13:17:56 +0100
Subject: Apartment rental during Osmocom developer workshop 2012
In-Reply-To: <20111214215203.GA4696@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
	<20111214155054.GC27642@prithivi.gnumonks.org>
	<20111214215203.GA4696@prithivi.gnumonks.org>
Message-ID: <20120105121756.GM28075@prithivi.gnumonks.org>

Hi all!

Regarding accomodation:  I've found out that there are numerous
inexpensive apartments in Berlin that can be rented for very little
money.  The sites are mostly German (like
http://www.ferienwohnungen-berlin.de/ or
www.kostenlose-zimmervermittlung-berlin.de/) but they offer
single-bedroom-apartments from as low as 21 EUR (typically though in the
40 to 50 EUR range) per night.  They all have their own bathroom,
kitchen.

There are also 3/4 bedroom apartments with multiple bedrooms that can be
used by e.g. up to 8 people.

If some of the attendees prefer to stay at such a place (as opposed to
the hostel or a real hotel), please first coordinate who would all want
to stay at the same place and then let me know the total number of beds
required.  I can look and search for a place that is available and not
too distant from the venue (if possible).

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Fri Jan 13 22:04:49 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 13 Jan 2012 23:04:49 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20111223200847.GL12250@prithivi.gnumonks.org>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
Message-ID: <20120113220449.GT6457@prithivi.gnumonks.org>

Hi all!

The osmo-x1-xcvr PCBs arrived earlier today.  I soldered four units, and
from a clock / DC measurements / power consumption point of view things
are looking fine so far.

I don't yet have any driver software for the transceiver though, i.e. no
code that can initialize the registers to a sane E1-mode state.  Thus,
I'm not able to verify if the actual analog/digital E1 side is working.

Due to lots of other work, I don't think I'll find much time during the
next 10 days or so.

If anyone is interested in writing that driver, connecting it to a
USB-SPI adapter or a microcontroller development board with SPI:  I'm
happy to send two of those fully assembled boards out.  One is for me
and another one for dieter.

For anyone else who wants to build one him/herself: There are 6 more
PCBs that I am happy to send out.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From ajlennon at dynamicdevices.co.uk  Sat Jan 14 00:53:28 2012
From: ajlennon at dynamicdevices.co.uk (Alex J Lennon)
Date: Sat, 14 Jan 2012 00:53:28 +0000
Subject: Fosdem attendance
In-Reply-To: <20120113220449.GT6457@prithivi.gnumonks.org>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
	<20120113220449.GT6457@prithivi.gnumonks.org>
Message-ID: <4F10D208.4060909@dynamicdevices.co.uk>

Hi,

Will any of you chaps be in Brussels for Fosdem? What could be more fun 
than talking  GSM standards and telco misdemeanours over a Lambic or two ;)

Regards,

Alex




From peter at stuge.se  Sat Jan 14 20:16:42 2012
From: peter at stuge.se (Peter Stuge)
Date: Sat, 14 Jan 2012 21:16:42 +0100
Subject: Fosdem attendance
In-Reply-To: <4F10D208.4060909@dynamicdevices.co.uk>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
	<20120113220449.GT6457@prithivi.gnumonks.org>
	<4F10D208.4060909@dynamicdevices.co.uk>
Message-ID: <20120114201642.9397.qmail@stuge.se>

Alex J Lennon wrote:
> Will any of you chaps be in Brussels for Fosdem?

I'm going, and I think a few others are as well.


//Peter



From chris at orr.me.uk  Sun Jan 15 12:39:17 2012
From: chris at orr.me.uk (Christopher Orr)
Date: Sun, 15 Jan 2012 13:39:17 +0100
Subject: Fosdem attendance
In-Reply-To: <20120114201642.9397.qmail@stuge.se>
References: <20111216174428.GQ17847@prithivi.gnumonks.org>
	<20111223200847.GL12250@prithivi.gnumonks.org>
	<20120113220449.GT6457@prithivi.gnumonks.org>
	<4F10D208.4060909@dynamicdevices.co.uk>
	<20120114201642.9397.qmail@stuge.se>
Message-ID: <4F12C8F5.7030805@orr.me.uk>

On 14/01/2012 21:16, Peter Stuge wrote:
> Alex J Lennon wrote:
>> Will any of you chaps be in Brussels for Fosdem?
>
> I'm going, and I think a few others are as well.

I see there is a telecoms devroom this year, but apparently nothing 
relating to GSM:
http://fosdem.org/2012/schedule/track/telephony_and_communications_devroom

However, this may be of interest, if Osmocommers want to meet up at some 
point:
http://fosdem.org/2012/news/meeting-rooms

Regards,
Chris



From nalin at ieee.org  Thu Jan 19 19:05:22 2012
From: nalin at ieee.org (Nalin Karunasinghe)
Date: Fri, 20 Jan 2012 00:35:22 +0530
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <20120113220449.GT6457@prithivi.gnumonks.org>
References: <20120113220449.GT6457@prithivi.gnumonks.org>
Message-ID: <4F186972.2020503@ieee.org>

Dear Harald,
I have experience in USB/SPI and telecommunications. I have just 
installed and tested openbts and i love to offer my help to osmocom 
project. i can make a usb to spi adapter working with your board.
Thanks
Nalin Karunasinghe



From peter at stuge.se  Fri Jan 20 03:06:57 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 20 Jan 2012 04:06:57 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <4F186972.2020503@ieee.org>
References: <20120113220449.GT6457@prithivi.gnumonks.org>
	<4F186972.2020503@ieee.org>
Message-ID: <20120120030657.4853.qmail@stuge.se>

Hi Nalin,

Nalin Karunasinghe wrote:
> I have experience in USB/SPI and telecommunications. I have just
> installed and tested openbts and i love to offer my help to osmocom
> project.

Please note that openbts has nothing to do with osmocom. Do you mean
openbsc?


> i can make a usb to spi adapter working with your board.

Do you know if there's a CDC subclass that fits, or would it be
vendor specific with an open protocol?

Please send your suggestion of what the protocol would look like.


//Peter



From laforge at gnumonks.org  Fri Jan 20 07:56:20 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 20 Jan 2012 08:56:20 +0100
Subject: Building an E1/T1/J1 line interface
In-Reply-To: <4F186972.2020503@ieee.org>
References: <20120113220449.GT6457@prithivi.gnumonks.org>
	<4F186972.2020503@ieee.org>
Message-ID: <20120120075620.GD834@prithivi.gnumonks.org>

Hi Nalin,

On Fri, Jan 20, 2012 at 12:35:22AM +0530, Nalin Karunasinghe wrote:

> I have experience in USB/SPI and telecommunications. I have just
> installed and tested openbts and i love to offer my help to osmocom
> project. i can make a usb to spi adapter working with your board.

Thanks a lot for bringing this up and offering your help.  Right now we
still need to finish the design of the E1 transceiver part.

After that, there is room for evaluating different options of using it,
both using a pure 'software defined E1' approach using a microcontroller
and doing all the mux/demux/HDLC in software - as well as for an
approach with some programmable logic involved.

That kind of experimentation doesn't really need a new board, as you can
just connect the osmo-e1-xcvr via SPI/SSC to e.g. your favorite
microcontroller.

If you're happy to work on that, e.g. to create a 'software defined E1'
implementation, you're most welcome.  I can send you either a populated
PCB or a component kit + pcb to solder it yourself.

Design of a new board with integrated microcontroller is premature at
this point.  we first have to make it working as a wired-up prototype...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From rp.labs at gmx.ch  Sun Jan  8 12:29:43 2012
From: rp.labs at gmx.ch (Labs)
Date: Sun, 08 Jan 2012 13:29:43 +0100
Subject: OpenBSC development
Message-ID: <4F098C37.4080101@gmx.ch>

Hello,

First of all congratulations to all people involved in this project.
I am new to this list but I watch the project for some time. I have some 
questions and maybe some ideas how to make this project testers or 
enthusiasts friendly.

I work with BSCes and BTSes every day at my work but I would like to try 
and play with OpenBSC but the installation and configuration looks time 
consuming and not friendly at all.

I have some questions and suggestions below:

* What about some packages for OpenBSC so we can install them easier 
from a repository? How hard, time consuming is to make a nightly build 
of the git sources and have some pre-compiled Debian packages?

* Did somebody try to build OpenBSC on SPARC architecture? I have some 
Sun servers that I would like to use for this project. Same thing like 
before, some pre-compiled packages would be nice for SPARC.

* Now, more like a project design request.

There is not so much documentation how to configure the parameters of 
OpenBSC, SGSN and BTS so a web interface also would be nice and very 
helpful.

Second thing on this topic, moving configuration from one server to 
another needs to be exported easily and imported in the same way to new 
hardware. What about a DB that keeps all the settings and with one 
command in CLI or web interface you export everything and import it on 
another hardware?

I am sorry if some things are already in OpenBSC but it's kind of hard 
to find important stuff on that wiki. Also I know that OpenBSC is under 
hard development so new features might come later.

Best regards,
R.



From holger at freyther.de  Sun Jan  8 13:33:04 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 08 Jan 2012 14:33:04 +0100
Subject: OpenBSC development
In-Reply-To: <4F098C37.4080101@gmx.ch>
References: <4F098C37.4080101@gmx.ch>
Message-ID: <4F099B10.9070500@freyther.de>

On 01/08/2012 01:29 PM, Labs wrote:
> Hello,
> 
> First of all congratulations to all people involved in this project.
> I am new to this list but I watch the project for some time. I have some
> questions and maybe some ideas how to make this project testers or enthusiasts
> friendly.

welcome! From my point of view the barrier is not lack of packages or
documentation but more the lack of affordable hardware.


> 
> * What about some packages for OpenBSC so we can install them easier from a
> repository? How hard, time consuming is to make a nightly build of the git
> sources and have some pre-compiled Debian packages?

Thank to Jan we have packages.osmocom.org with Debian/Ubuntu packages, our
libraries are also on the way into debian repositories (again thanks to Jan's
effort). We do not have nightly builds though, I don't know Debian's policy of
automatically signing nightly builds though.


> 
> * Did somebody try to build OpenBSC on SPARC architecture? I have some Sun
> servers that I would like to use for this project. Same thing like before,
> some pre-compiled packages would be nice for SPARC.

Not tham I am aware of.


> 
> * Now, more like a project design request.
> 
> There is not so much documentation how to configure the parameters of OpenBSC,
> SGSN and BTS so a web interface also would be nice and very helpful.

I have started generating XML (to be used by docbook or converted to Trac Wiki
Syntax) from our VTY (Virtual TeleType) interface. The XML generated from the
application can be merged (via XSLT) with additional documentation and then be
included in any kind of documentation.



> Second thing on this topic, moving configuration from one server to another
> needs to be exported easily and imported in the same way to new hardware. What
> about a DB that keeps all the settings and with one command in CLI or web
> interface you export everything and import it on another hardware?

I don't understand this part, our config files are plain text and can be
copied around nicely. I assume you refer to something else. We also have the
beginning of a Machine-Interface (gdb terminology) but no conclusion of how to
combine that with the vty.



To summarize, you are more than welcome to help us on the documentation part,
bring more structure to the wiki, create a docbook for OpenBSC, include the
VTY commands and config options in a reference kind of manual.






From peter at stuge.se  Mon Jan  9 09:34:17 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jan 2012 10:34:17 +0100
Subject: OpenBSC development
In-Reply-To: <4F099B10.9070500@freyther.de>
References: <4F098C37.4080101@gmx.ch> <4F099B10.9070500@freyther.de>
Message-ID: <20120109093417.4570.qmail@stuge.se>

Holger Hans Peter Freyther wrote:
> > * Did somebody try to build OpenBSC on SPARC architecture? I have some Sun
> > servers that I would like to use for this project. Same thing like before,
> > some pre-compiled packages would be nice for SPARC.
> 
> Not tham I am aware of.

For anyone who wishes to try this and feed back results into the
project I can recommend requesting an account for the GCC Compile
Farm, which has several sparc and sparc64 hosts. No cost.

http://gcc.gnu.org/wiki/CompileFarm


//Peter



From rp.labs at gmx.ch  Mon Jan  9 18:42:17 2012
From: rp.labs at gmx.ch (Labs)
Date: Mon, 09 Jan 2012 19:42:17 +0100
Subject: OpenBSC development
In-Reply-To: <20120109093417.4570.qmail@stuge.se>
References: <4F098C37.4080101@gmx.ch> <4F099B10.9070500@freyther.de>
	<20120109093417.4570.qmail@stuge.se>
Message-ID: <4F0B3509.3090006@gmx.ch>

On 09-Jan-12 10:34, Peter Stuge wrote:
> Holger Hans Peter Freyther wrote:
>>> * Did somebody try to build OpenBSC on SPARC architecture? I have some Sun
>>> servers that I would like to use for this project. Same thing like before,
>>> some pre-compiled packages would be nice for SPARC.
>>
>> Not tham I am aware of.
>
> For anyone who wishes to try this and feed back results into the
> project I can recommend requesting an account for the GCC Compile
> Farm, which has several sparc and sparc64 hosts. No cost.
>
> http://gcc.gnu.org/wiki/CompileFarm
>

The problem is not hardware. I guess it's more like CPU architecture 
issue. I think many things needs to be changed...

> //Peter
>

R.



From laforge at gnumonks.org  Mon Jan  9 11:26:57 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Jan 2012 12:26:57 +0100
Subject: OpenBSC development
In-Reply-To: <4F099B10.9070500@freyther.de>
References: <4F098C37.4080101@gmx.ch>
 <4F099B10.9070500@freyther.de>
Message-ID: <20120109112657.GF7738@prithivi.gnumonks.org>

Hi all,

On Sun, Jan 08, 2012 at 02:33:04PM +0100, Holger Hans Peter Freyther wrote:
> > First of all congratulations to all people involved in this project.
> > I am new to this list but I watch the project for some time. I have some
> > questions and maybe some ideas how to make this project testers or enthusiasts
> > friendly.
> 
> welcome! From my point of view the barrier is not lack of packages or
> documentation but more the lack of affordable hardware.

I whole-heartedly agree.

> > * Did somebody try to build OpenBSC on SPARC architecture? I have some Sun
> > servers that I would like to use for this project. Same thing like before,
> > some pre-compiled packages would be nice for SPARC.
> 
> Not tham I am aware of.

Well, we have to be careful here.  So far, to the best of my knowledge,
OpenBSC has been tested (and deployed) on x86, x86_64 and ARM, all in
little endian mode.

Running OpenBSC on a big endian platform like SPARC or PPC might run us
into some trouble, especially if the endianness of bit-fields is
different, a lot of our definitions in
libosmocore/include/osmocom/gsm/protocol/ will have to be adapted/fixed.

So I would suggest to at least first verify OpenBSC works for you on
x86/x86_64 or ARM, and then proceed to SPARC32/SPARC64 in a next step.

If you encounter a given bug, you can always test against x86 in order
to see if it is caused by the architecture difference or a general bug.

> > There is not so much documentation how to configure the parameters of OpenBSC,
> > SGSN and BTS so a web interface also would be nice and very helpful.

I agree there is not much documentation, but it is a community project
and we invite everyone to contribute not only in code but also in
documentation.  There are at least several dozen people on this list who
have successfully installed and used OpenBSC, and who have the skills to
write and/or improvde documentation - as opposed to the handful of
people who actually are working hard to improve and extend the code.

Also, regarding a web interface:  Tens of thousands of network
administrators world wide are able to work with cisco style interfaces
on routers and switches without any problem.  Agreed, there is good
documentation available.  But I'm really against some kind of web
interface.  Operating a GSM network should be done by people who have at
least some level of technical understanding of what they are doing.

If we appear to make it usable by everone, even people with zero
technical knowledge, we can assume that they will run RF equipment in
configurations which are neither legal nor safe and which will only get
them in trouble eventually.

So yes, there should be better reference documentation and
guides/HOWTOs.  But please don't talk about making this software usable
to non-technical people.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From rp.labs at gmx.ch  Mon Jan  9 19:10:13 2012
From: rp.labs at gmx.ch (Labs)
Date: Mon, 09 Jan 2012 20:10:13 +0100
Subject: OpenBSC development
In-Reply-To: <20120109112657.GF7738@prithivi.gnumonks.org>
References: <4F098C37.4080101@gmx.ch> <4F099B10.9070500@freyther.de>
	<20120109112657.GF7738@prithivi.gnumonks.org>
Message-ID: <4F0B3B95.4030100@gmx.ch>

Hello Harald,

On 09-Jan-12 12:26, Harald Welte wrote:
>> welcome! From my point of view the barrier is not lack of packages or
>> documentation but more the lack of affordable hardware.
>
> I whole-heartedly agree.
>

As all probably know, imagine what can happen when you sell on the 
street 3000 BTS units?! Operators that replace entire network will sell 
everything to poor countries in one package. Not all the people have 
enough knowledge to operate RF equipments and bad things can happen.
I guess I said enough here...

> Well, we have to be careful here.  So far, to the best of my knowledge,
> OpenBSC has been tested (and deployed) on x86, x86_64 and ARM, all in
> little endian mode.
>
> Running OpenBSC on a big endian platform like SPARC or PPC might run us
> into some trouble, especially if the endianness of bit-fields is
> different, a lot of our definitions in
> libosmocore/include/osmocom/gsm/protocol/ will have to be adapted/fixed.
>
> So I would suggest to at least first verify OpenBSC works for you on
> x86/x86_64 or ARM, and then proceed to SPARC32/SPARC64 in a next step.
>
> If you encounter a given bug, you can always test against x86 in order
> to see if it is caused by the architecture difference or a general bug.
>

This is what I was afraid of, that's why I asked first before loosing 
time. Thanks for confirming this point.

> Also, regarding a web interface:  Tens of thousands of network
> administrators world wide are able to work with cisco style interfaces
> on routers and switches without any problem.  Agreed, there is good
> documentation available.  But I'm really against some kind of web
> interface.  Operating a GSM network should be done by people who have at
> least some level of technical understanding of what they are doing.
>

I like the CLI but to check the status of an E1 line, change some IP 
addresses, check the temperature of TRX modules or other small things I 
guess is not a problem and it's not that I cannot type a few commands.

> If we appear to make it usable by everone, even people with zero
> technical knowledge, we can assume that they will run RF equipment in
> configurations which are neither legal nor safe and which will only get
> them in trouble eventually.

I agree with you until some point. From what you say this means that 
OpenBSC will never be usable because some zero technical can use it to 
run RF equipments and who knows what can happen. Am I wrong here?

> So yes, there should be better reference documentation and
> guides/HOWTOs.  But please don't talk about making this software usable
> to non-technical people.
>

If some people will want to run some RF equipments they will do it with 
or without help of OpenBSC. All new BSC hardware from X,Y,Z vendors are 
running Linux now. If the BSC doesn't look like a normal PC this doesn't 
mean anything. They use x86 HW combined with some FPGA and that's all. A 
little tweaking and you can run it on low cost hardware.

Another thing, maybe it will be easier for a programmer to run OpenBSC 
than a RAN/CN engineer without programming skills. Last part was from a 
discussion at work today.

Watching the lists and blogs I know that everybody on this project 
worked hard and I am sorry if what I said is wrong.

Best regards,
R.



From rp.labs at gmx.ch  Mon Jan  9 07:32:26 2012
From: rp.labs at gmx.ch (Labs)
Date: Mon, 09 Jan 2012 08:32:26 +0100
Subject: OpenBSC development
In-Reply-To: <4F098C37.4080101@gmx.ch>
References: <4F098C37.4080101@gmx.ch>
Message-ID: <4F0A980A.6080806@gmx.ch>

On 01/08/2012 02:33 PM, Holger Hans Peter Freyther wrote:

 >welcome! From my point of view the barrier is not lack of packages or
 >documentation but more the lack of affordable hardware.

What do you mean affordable hardware? I guess it's not about servers 
running OpenBSC but BTS hardware which is hard to find.

My idea is that if you want cheap hardware go and ask an operator which 
is replacing the old BTS equipments with new one from other vendors.

In Germany I know at least 2 operators which are swapping right now with 
other vendor all network so you will have on the market thousands of BTS 
equipments, mostly Siemens. The problem is power and space because you 
will not find micro-cells. They mostly have big ones.

 >Thank to Jan we have packages.osmocom.org with Debian/Ubuntu packages, 
 >our
 >libraries are also on the way into debian repositories (again thanks 
 >to Jan's
 >effort). We do not have nightly builds though, I don't know Debian's 
 >policy of
 >automatically signing nightly builds though.

I already checked the link but the package repository doesn't keep up 
with updates from git repository. Most of them were built in the summer 
last year, that's why I wanted a nightly built to have the latest bug 
fixes and features.

 >>
 >> * Did somebody try to build OpenBSC on SPARC architecture? I have 
 >>some Sun
 >> servers that I would like to use for this project. Same thing like 
 >>before,
 >> some pre-compiled packages would be nice for SPARC.

 >Not tham I am aware of.

That's bad because I wanted to run OpenBSC on SPARC and my programming 
skills are almost zero and some help with compiling was nice. :=)

 >I have started generating XML (to be used by docbook or converted to 
 >Trac Wiki
 >Syntax) from our VTY (Virtual TeleType) interface. The XML generated 
 >from the
 >application can be merged (via XSLT) with additional documentation and 
 >then be
 >included in any kind of documentation.

Normally I prefer the VTY on any kind of hardware configuration but the 
VTY for OpenBSC is not so intuitive and helpful that's why I asked for a 
web interface to help setup the BSC, BTS and transmission parts.

I guess you were referring to osmo-nitb.
http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY

My idea was to change the way it is now and split the commands in:
"list or show or get" - for checking already set parameters
"display" - for checking live parameters, like transport layer errors, 
line up, down, BTS up, down
"set,add" - for adding new configuration parameters
"modify" - for changing a parameter value

This will be the main commands and after you can define the parameters 
and also split them in some classes like BTS transport layer 
configuration, IP or E1 configuration for BSC, Cell and frequency 
parameters, etc.

In this way it will be much easier to know what you will configure.
There is more to discuss on this topic...

 >I don't understand this part, our config files are plain text and can >be
 >copied around nicely. I assume you refer to something else. We also 
 >have the
 >beginning of a Machine-Interface (gdb terminology) but no conclusion 
 >of how to
 >combine that with the vty.

I was talking about all config parameters to be in one DB and not in 
text files. Also it can be an XML file with all configuration and not 
many text files.

 From VTY just run let's say "backup live-config" command and you will 
have an XML with all configuration that you can move on other hardware.

XML should contain everything like E1 or IP settings, BTS and cell 
parameters, etc.

 >To summarize, you are more than welcome to help us on the 
 >documentation part,
 >bring more structure to the wiki, create a docbook for OpenBSC, 
 >include the
 >VTY commands and config options in a reference kind of manual.

I will gladly help but I will need first to make some time. I am very 
busy with jobs and kids but I will try in the next weeks to set up a lab 
at home for OpenBSC and after we can discuss more based on real facts.

Thank you,
R.



From 246tnt at gmail.com  Mon Jan  9 08:16:57 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 9 Jan 2012 09:16:57 +0100
Subject: OpenBSC development
In-Reply-To: <4F0A980A.6080806@gmx.ch>
References: <4F098C37.4080101@gmx.ch>
	<4F0A980A.6080806@gmx.ch>
Message-ID: <CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>

Hi,

> In Germany I know at least 2 operators which are swapping right now with
> other vendor all network so you will have on the market thousands of BTS
> equipments, mostly Siemens. The problem is power and space because you will
> not find micro-cells. They mostly have big ones.

The "micro cell" was implied ... of course not every one wants a macro
cell to play with.
Also "cheap" is like < 1kEUR new and probably < 500 EUR used.


> That's bad because I wanted to run OpenBSC on SPARC and my programming
> skills are almost zero and some help with compiling was nice. :=)

Well, here's a chance to learn. And do yourself a favor and pick up
any mini-itx x86 board and run it on that ...


> Normally I prefer the VTY on any kind of hardware configuration but the VTY
> for OpenBSC is not so intuitive and helpful that's why I asked for a web
> interface to help setup the BSC, BTS and transmission parts.

If you had any experience with cisco, it would be pretty intuitive ...
also there is autocompletion


> My idea was to change the way it is now and split the commands in:
> "list or show or get" - for checking already set parameters
> "display" - for checking live parameters, like transport layer errors, line
> up, down, BTS up, down
> "set,add" - for adding new configuration parameters
> "modify" - for changing a parameter value

Just because _you_ don't like it doesn't mean we'll all change our way
of doing things to accommodate you. I personally like the current
config method and it allows to do everything you listed above (with
different command names) and so I don't see any benefit of spending a
significant amount of time rewriting code that works ....


> I was talking about all config parameters to be in one DB and not in text
> files. Also it can be an XML file with all configuration and not many text
> files.

"many" ?

OpenBSC has exactly 1 text file ... and why on earth would we want to
change that to a binary db format, or worse an XML ...
The text file is easily readable and editable by hand and matches the
VTY commands (so once you know one, you know the other)


> From VTY just run let's say "backup live-config" command and you will have
> an XML with all configuration that you can move on other hardware.
>
> XML should contain everything like E1 or IP settings, BTS and cell
> parameters, etc.

The OpenBSC config contains ... the OpenBSC config. All other
parameters (IP or E1 card driver settings ...) are outside of scope of
this project. This is meant to be a software BSC, not an "appliance".

If you want to make it "appliance" like with all the OS and
surrounding drivers and some kind of unified config for everything and
such, feel free to start a new project for that, but this is
independent of the core BSC software. If you don't have the time or
skill for that, you can always hire someone to do it for you.


Cheers,

    Sylvain



From rp.labs at gmx.ch  Mon Jan  9 18:39:14 2012
From: rp.labs at gmx.ch (Labs)
Date: Mon, 09 Jan 2012 19:39:14 +0100
Subject: OpenBSC development
In-Reply-To: <CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>
	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
Message-ID: <4F0B3452.1070702@gmx.ch>

On 09-Jan-12 09:16, Sylvain Munaut wrote:

> The "micro cell" was implied ... of course not every one wants a macro
> cell to play with.
> Also "cheap" is like<  1kEUR new and probably<  500 EUR used.
>

500 EUR for a used micro-cell is not much considering what is inside and 
what you can do with it. The problem is who is selling you one?

You can get a Layer 3 switch for a lot more so the price is ok

> Well, here's a chance to learn. And do yourself a favor and pick up
> any mini-itx x86 board and run it on that ...
>

My main issue is that where I have the BTS, I cannot go with my own 
server/laptop and I need to use the servers/workstations in there.

> If you had any experience with cisco, it would be pretty intuitive ...
> also there is autocompletion
>

I have experience with Cisco and Juniper hardware and CLI but for some 
basic things I prefer to have a web console.

> Just because _you_ don't like it doesn't mean we'll all change our way
> of doing things to accommodate you. I personally like the current
> config method and it allows to do everything you listed above (with
> different command names) and so I don't see any benefit of spending a
> significant amount of time rewriting code that works ....
>

I didn't say that I don't like it but the VTY commands are not so 
intuitive. For example tell me how I can check what "CellID" I have 
configured for BTS "X" from the VTY?

There is no option from what I can see in the wiki to list configured 
parameters on BSC?!

I didn't yet installed OpenBSC so I am telling this after reading the 
wiki. Sorry if there is such option but not documented.

> OpenBSC has exactly 1 text file ... and why on earth would we want to
> change that to a binary db format, or worse an XML ...
> The text file is easily readable and editable by hand and matches the
> VTY commands (so once you know one, you know the other)
>

When I refer to config this means also the config for management 
interfaces of server, users, firewall settings (if any configured).

> The OpenBSC config contains ... the OpenBSC config. All other
> parameters (IP or E1 card driver settings ...) are outside of scope of
> this project. This is meant to be a software BSC, not an "appliance".
>

OpenBSC config should also contain the config for IP or E1 cards because 
otherwise you software BSC will not work without it. I would say that is 
a mandatory dependency. This is just my way of thinking...

> If you want to make it "appliance" like with all the OS and
> surrounding drivers and some kind of unified config for everything and
> such, feel free to start a new project for that, but this is
> independent of the core BSC software. If you don't have the time or
> skill for that, you can always hire someone to do it for you.
>

I am not planning to make any appliance for it. I was just thinking for 
a way to make a fast recovery of a deployment/test lab. It will take a 
couple of days to make all the settings again if something goes wrong 
with hardware, right?

>
> Cheers,
>

Thanks's for sharing some light and excuse me if some things are wrong.
This is how I am seeing things from outside and after reading the 
project pages.

>      Sylvain
>

Regards,
R.



From holger at freyther.de  Mon Jan  9 19:57:07 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 09 Jan 2012 20:57:07 +0100
Subject: OpenBSC development
In-Reply-To: <4F0B3452.1070702@gmx.ch>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
	<4F0B3452.1070702@gmx.ch>
Message-ID: <4F0B4693.7080107@freyther.de>

On 01/09/2012 07:39 PM, Labs wrote:
> On 09-Jan-12 09:16, Sylvain Munaut wrote:


> Thanks's for sharing some light and excuse me if some things are wrong.
> This is how I am seeing things from outside and after reading the project pages.

It is not wrong, we appear to follow different philosophies here. We follow
the Unix one, our BSC is doing what a BSC should do by definition (assigning
radio resources). What you want is that OpenBSC is an appliance and include
things that would be provided by other parts of the system.

E.g. Link State, Firewall settings should probably go through SNMP, mISDN
should export the MIB via procfs, the SNMP daemon should read this file to
provide the status to whoever asks. In case the A-link is the only interface
to the outside the BSC could help to tunnel SNMP over the O&M link.


In one point you are right, our documentation is not mature, incomplete,
outdated. Do you want to help to correct that?

holger





From rp.labs at gmx.ch  Mon Jan  9 22:20:30 2012
From: rp.labs at gmx.ch (Labs)
Date: Mon, 09 Jan 2012 23:20:30 +0100
Subject: OpenBSC development
In-Reply-To: <4F0B4693.7080107@freyther.de>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>
	<4F0B4693.7080107@freyther.de>
Message-ID: <4F0B682E.7030806@gmx.ch>

On 09-Jan-12 20:57, Holger Hans Peter Freyther wrote:
>> Thanks's for sharing some light and excuse me if some things are wrong.
>> This is how I am seeing things from outside and after reading the project pages.
>
> It is not wrong, we appear to follow different philosophies here. We follow
> the Unix one, our BSC is doing what a BSC should do by definition (assigning
> radio resources). What you want is that OpenBSC is an appliance and include
> things that would be provided by other parts of the system.
>

Let's see; below is quote from the main page:

Quote:
"What this means: OpenBSC is not just a standard BSC, but a GSM network 
in a box software, implementing the minimal necessary parts to build a 
small, self-contained GSM network.

OpenBSC includes functionality normally performed by the following 
components of a GSM network: BSC (Base Station Controller), MSC (Mobile 
Switching Center), HLR (Home Location Register), AuC (Authentication 
Center), VLR (Visitor Location Register), EIR (Equipment Identity 
Register)."

What you have here in real/live network are a few racks, not to mention 
the SGSN and GGSN that you have already implemented.

Am I missing something? Sorry for saying that but it looks like to me 
that it is an appliance.

> E.g. Link State, Firewall settings should probably go through SNMP, mISDN
> should export the MIB via procfs, the SNMP daemon should read this file to
> provide the status to whoever asks. In case the A-link is the only interface
> to the outside the BSC could help to tunnel SNMP over the O&M link.
>

I didn't install yet the OpenBSC but as I said in a previous email I 
will have it done by the end of next week and check all configs.

I was thinking that you already have everything implemented in OpenBSC 
(BSC/MSC/VLR/HLR/AuC/EIR/SGSN/GGSN) and the only interfaces out are Abis 
(IP or E1) and another ethernet for management of OpenBSC box.
So from my assumption above it started the idea with all-in-one config 
and GUI for the mentioned pieces of this puzzle.

I guess I am wrong here...

>
> In one point you are right, our documentation is not mature, incomplete,
> outdated. Do you want to help to correct that?
>

I would really like to do that but I am not a programmer and I will/can 
write documentation based on my tests and real life experience.
We need to discuss more on this topic.

> holger
>

Best regards,
R.



From peter at stuge.se  Mon Jan  9 22:48:08 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 9 Jan 2012 23:48:08 +0100
Subject: OpenBSC development
In-Reply-To: <4F0B682E.7030806@gmx.ch>
References: <4F098C37.4080101@gmx.ch> <4F0A980A.6080806@gmx.ch>
	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
	<4F0B3452.1070702@gmx.ch> <4F0B4693.7080107@freyther.de>
	<4F0B682E.7030806@gmx.ch>
Message-ID: <20120109224808.13953.qmail@stuge.se>

Labs wrote:
> Am I missing something? Sorry for saying that but it looks like to
> me that it is an appliance.

I understand your reasoning. Some points come to mind:

* An appliance is an integrated system and not only a software package

OpenBSC can certainly be part of something larger, but it is "just" a
software package, even if a very comprehensive one. So far I don't
know about any open source appliances using OpenBSC. One thing that
might be interesting to make the very first testing easier would be a
preconfigure VM image that could be started to have an OpenBSC
running in seconds, for when the environment being used is not so
convenient for downloading and building the source, and configuring
network interfaces.

We had some tangential discussions at 28c3 in Berlin between X-mas
and NYE, where we last ran an OpenBSC test network.


* The OpenBSC software may be integrated in many different ways

OpenBSC does not neccessarily run only on Linux operating systems
(maybe this is actually a requirement now, but I don't think it needs
to be, and generally it is good to have software be portable across
many different operating systems) - this is significant because any
interface configuration is always highly system specific, and every
integration will have different processes here. Following the UNIX
principle, this is outside the scope of OpenBSC. Ie. interface
configuration is one step considered belonging to the base system,
while software configuration to use those interfaces is a separate
step which needs to match the system base configuration.

I actually don't think it is such a bad idea to also have OpenBSC be
involved in, or even take responsibility for, some interface
configuration, but this may well require some significant changes in
the source code, so it will not happen very quickly.

If it happens I would argue that OpenBSC should configure only those
interfaces which are related to GSM, and that they be kept separate
from the "regular" interfaces used by the system.

Such a change will tie OpenBSC more strongly to the particular
operating systems it runs on, which is generally considered a bad
thing. However, I agree with you that there is a certain value to
indeed have all GSM-network-related configuration, including IP, in
the configuration file.

Also note that I'm not really a core developer, so even if I kindof
like the idea that does not have to mean very much. :)


> I didn't install yet the OpenBSC but as I said in a previous email
> I will have it done by the end of next week and check all configs.

You should be able to do it rather quickly, also without being a
programmer. The dependencies are not very many.


> I was thinking that you already have everything implemented in OpenBSC 
> (BSC/MSC/VLR/HLR/AuC/EIR/SGSN/GGSN) and the only interfaces out are Abis 
> (IP or E1) and another ethernet for management of OpenBSC box.
> So from my assumption above it started the idea with all-in-one
> config and GUI for the mentioned pieces of this puzzle.
>
> I guess I am wrong here...

GUI or CLI is a matter of (sometimes strong) taste. I think it's fine
to have different types of user interfaces, but this will possibly
require re-engineering of the existing CLI config interface a bit,
so that other types of interfaces can be integrated seamlessly.

Of course it's also possible to build a GUI which in fact just uses
the CLI and has nice buttons to click on. All relevant information
must be available through CLI anyway.


> I will/can write documentation based on my tests and real life
> experience. We need to discuss more on this topic.

All contributions are valuable, and you absolutely don't have to be a
programmer to be able to contribute. Documentation contributions, in
particular from real life experience, are indeed very welcome!


//Peter



From rp.labs at gmx.ch  Mon Jan  9 23:43:33 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 00:43:33 +0100
Subject: OpenBSC development
In-Reply-To: <20120109224808.13953.qmail@stuge.se>
References: <4F098C37.4080101@gmx.ch>
	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>
	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>
	<20120109224808.13953.qmail@stuge.se>
Message-ID: <4F0B7BA5.2090802@gmx.ch>

On 09-Jan-12 23:48, Peter Stuge wrote:
>
> I understand your reasoning. Some points come to mind:
>
> * An appliance is an integrated system and not only a software package
>
> OpenBSC can certainly be part of something larger, but it is "just" a
> software package, even if a very comprehensive one. So far I don't
> know about any open source appliances using OpenBSC. One thing that
> might be interesting to make the very first testing easier would be a
> preconfigure VM image that could be started to have an OpenBSC
> running in seconds, for when the environment being used is not so
> convenient for downloading and building the source, and configuring
> network interfaces.
>

This is what I will do so I will be able to move the image in different 
labs but my main issue will be how I will connect an E1 transmission 
based BTS to a VM?!

I also don't have an E1 PCI card to plug-in in a PC. I will check if I 
can use a Cisco router with an E1 port WIC or NM module and send the 
traffic via ethernet to VM. Did somebody try it? I will start a new 
topic for this one...

> We had some tangential discussions at 28c3 in Berlin between X-mas
> and NYE, where we last ran an OpenBSC test network.
>

So there are more people thinking like me?

>
> * The OpenBSC software may be integrated in many different ways
>
> OpenBSC does not neccessarily run only on Linux operating systems
> (maybe this is actually a requirement now, but I don't think it needs
> to be, and generally it is good to have software be portable across
> many different operating systems) - this is significant because any
> interface configuration is always highly system specific, and every
> integration will have different processes here. Following the UNIX
> principle, this is outside the scope of OpenBSC. Ie. interface
> configuration is one step considered belonging to the base system,
> while software configuration to use those interfaces is a separate
> step which needs to match the system base configuration.
>

I am thinking that you always need to separate the traffic based on 
destination. That being said you will not use the same interface for 
management of the box and also for Abis or A interfaces. All of them 
should be separately defined.

Management interface can be defined via normal OS way (or an OpenBSC 
GUI/startup menu?) but the rest of interfaces should be defined via 
OpenBSC config. I don't know how it works now, is there any "limitation" 
or you can have everything on one ethernet interface?

> I actually don't think it is such a bad idea to also have OpenBSC be
> involved in, or even take responsibility for, some interface
> configuration, but this may well require some significant changes in
> the source code, so it will not happen very quickly.
>

I know all of you dedicated a lot of time for this project but design 
should be done in advance so there will not be a complete re-write of 
the code in case of small/big? changes. Sorry if somebody feels hurt 
here. It is just my thinking about this, please no hard feelings.

> If it happens I would argue that OpenBSC should configure only those
> interfaces which are related to GSM, and that they be kept separate
> from the "regular" interfaces used by the system.
>

Correct, agree.

> Such a change will tie OpenBSC more strongly to the particular
> operating systems it runs on, which is generally considered a bad
> thing. However, I agree with you that there is a certain value to
> indeed have all GSM-network-related configuration, including IP, in
> the configuration file.
>

It is considered bad but you cannot just keep on testing different 
behaviors on all Linux flavors. I think most, probably 99%, are running 
the project on Debian.

Regarding configuration, maybe it will change in time, who knows?

> Also note that I'm not really a core developer, so even if I kindof
> like the idea that does not have to mean very much. :)
>

It is an open source project so I guess we can have an open discussion 
on different ideas or design changes that's why I started this thread.

>> I didn't install yet the OpenBSC but as I said in a previous email
>> I will have it done by the end of next week and check all configs.
>
> You should be able to do it rather quickly, also without being a
> programmer. The dependencies are not very many.
>

I know it will be fast just need some time to power on my VMware server. 
I shut it down last year...

> GUI or CLI is a matter of (sometimes strong) taste. I think it's fine
> to have different types of user interfaces, but this will possibly
> require re-engineering of the existing CLI config interface a bit,
> so that other types of interfaces can be integrated seamlessly.
>
> Of course it's also possible to build a GUI which in fact just uses
> the CLI and has nice buttons to click on. All relevant information
> must be available through CLI anyway.
>

I guess I put it in the wrong way in my first email. I work with CLI 
everyday but for some things I like the GUI. I am probably used with the 
commercial BSC CLI/GUI so...

I prefer to have a GUI for checking fast some transmission line 
parameters (type/line code/BER results/IP address of BTS), check and 
reset different BTS boards that go crazy sometime...

I am not sure what you can do now in regard to BTS components/modules 
and if the OML commands sent to BTS can do the above things.

I am working on integration/operation of RAN so I need to combine both 
to be fast and fix the issues.

>> I will/can write documentation based on my tests and real life
>> experience. We need to discuss more on this topic.
>
> All contributions are valuable, and you absolutely don't have to be a
> programmer to be able to contribute. Documentation contributions, in
> particular from real life experience, are indeed very welcome!
>

I will definitely start to write some docs and update the wiki after I 
will install and get used with the project.

> //Peter
>

R.



From bouchtaoui at gmail.com  Tue Jan 10 10:40:06 2012
From: bouchtaoui at gmail.com (nordin)
Date: Tue, 10 Jan 2012 11:40:06 +0100
Subject: OpenBSC development
In-Reply-To: <4F0B7BA5.2090802@gmx.ch>
References: <4F098C37.4080101@gmx.ch>
	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>
	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>
	<20120109224808.13953.qmail@stuge.se> <4F0B7BA5.2090802@gmx.ch>
Message-ID: <4F0C1586.5080801@gmail.com>

If you have a nanoBTS, you can install/setup and run your own network 
very easy. There is no E1 interface needed or a special lib or a 
modified kernel or something. Just install debian and other libs you can 
easily install it with apt, git-clone the project and connect the bts 
with a utp-cable and you're on the go.
If I can do it, I'm sure everybody else can do it.

When you get that running, than you can talk about lack of 
documentation, or better design or whatever.
Good luck.



On 10-1-2012 0:43, Labs wrote:
> On 09-Jan-12 23:48, Peter Stuge wrote:
>>
>> I understand your reasoning. Some points come to mind:
>>
>> * An appliance is an integrated system and not only a software package
>>
>> OpenBSC can certainly be part of something larger, but it is "just" a
>> software package, even if a very comprehensive one. So far I don't
>> know about any open source appliances using OpenBSC. One thing that
>> might be interesting to make the very first testing easier would be a
>> preconfigure VM image that could be started to have an OpenBSC
>> running in seconds, for when the environment being used is not so
>> convenient for downloading and building the source, and configuring
>> network interfaces.
>>
>
> This is what I will do so I will be able to move the image in 
> different labs but my main issue will be how I will connect an E1 
> transmission based BTS to a VM?!
>
> I also don't have an E1 PCI card to plug-in in a PC. I will check if I 
> can use a Cisco router with an E1 port WIC or NM module and send the 
> traffic via ethernet to VM. Did somebody try it? I will start a new 
> topic for this one...
>
>> We had some tangential discussions at 28c3 in Berlin between X-mas
>> and NYE, where we last ran an OpenBSC test network.
>>
>
> So there are more people thinking like me?
>
>>
>> * The OpenBSC software may be integrated in many different ways
>>
>> OpenBSC does not neccessarily run only on Linux operating systems
>> (maybe this is actually a requirement now, but I don't think it needs
>> to be, and generally it is good to have software be portable across
>> many different operating systems) - this is significant because any
>> interface configuration is always highly system specific, and every
>> integration will have different processes here. Following the UNIX
>> principle, this is outside the scope of OpenBSC. Ie. interface
>> configuration is one step considered belonging to the base system,
>> while software configuration to use those interfaces is a separate
>> step which needs to match the system base configuration.
>>
>
> I am thinking that you always need to separate the traffic based on 
> destination. That being said you will not use the same interface for 
> management of the box and also for Abis or A interfaces. All of them 
> should be separately defined.
>
> Management interface can be defined via normal OS way (or an OpenBSC 
> GUI/startup menu?) but the rest of interfaces should be defined via 
> OpenBSC config. I don't know how it works now, is there any 
> "limitation" or you can have everything on one ethernet interface?
>
>> I actually don't think it is such a bad idea to also have OpenBSC be
>> involved in, or even take responsibility for, some interface
>> configuration, but this may well require some significant changes in
>> the source code, so it will not happen very quickly.
>>
>
> I know all of you dedicated a lot of time for this project but design 
> should be done in advance so there will not be a complete re-write of 
> the code in case of small/big? changes. Sorry if somebody feels hurt 
> here. It is just my thinking about this, please no hard feelings.
>
>> If it happens I would argue that OpenBSC should configure only those
>> interfaces which are related to GSM, and that they be kept separate
>> from the "regular" interfaces used by the system.
>>
>
> Correct, agree.
>
>> Such a change will tie OpenBSC more strongly to the particular
>> operating systems it runs on, which is generally considered a bad
>> thing. However, I agree with you that there is a certain value to
>> indeed have all GSM-network-related configuration, including IP, in
>> the configuration file.
>>
>
> It is considered bad but you cannot just keep on testing different 
> behaviors on all Linux flavors. I think most, probably 99%, are 
> running the project on Debian.
>
> Regarding configuration, maybe it will change in time, who knows?
>
>> Also note that I'm not really a core developer, so even if I kindof
>> like the idea that does not have to mean very much. :)
>>
>
> It is an open source project so I guess we can have an open discussion 
> on different ideas or design changes that's why I started this thread.
>
>>> I didn't install yet the OpenBSC but as I said in a previous email
>>> I will have it done by the end of next week and check all configs.
>>
>> You should be able to do it rather quickly, also without being a
>> programmer. The dependencies are not very many.
>>
>
> I know it will be fast just need some time to power on my VMware 
> server. I shut it down last year...
>
>> GUI or CLI is a matter of (sometimes strong) taste. I think it's fine
>> to have different types of user interfaces, but this will possibly
>> require re-engineering of the existing CLI config interface a bit,
>> so that other types of interfaces can be integrated seamlessly.
>>
>> Of course it's also possible to build a GUI which in fact just uses
>> the CLI and has nice buttons to click on. All relevant information
>> must be available through CLI anyway.
>>
>
> I guess I put it in the wrong way in my first email. I work with CLI 
> everyday but for some things I like the GUI. I am probably used with 
> the commercial BSC CLI/GUI so...
>
> I prefer to have a GUI for checking fast some transmission line 
> parameters (type/line code/BER results/IP address of BTS), check and 
> reset different BTS boards that go crazy sometime...
>
> I am not sure what you can do now in regard to BTS components/modules 
> and if the OML commands sent to BTS can do the above things.
>
> I am working on integration/operation of RAN so I need to combine both 
> to be fast and fix the issues.
>
>>> I will/can write documentation based on my tests and real life
>>> experience. We need to discuss more on this topic.
>>
>> All contributions are valuable, and you absolutely don't have to be a
>> programmer to be able to contribute. Documentation contributions, in
>> particular from real life experience, are indeed very welcome!
>>
>
> I will definitely start to write some docs and update the wiki after I 
> will install and get used with the project.
>
>> //Peter
>>
>
> R.
>




From rp.labs at gmx.ch  Tue Jan 10 20:03:52 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 21:03:52 +0100
Subject: OpenBSC development
In-Reply-To: <4F0C1586.5080801@gmail.com>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch> <4F0C1586.5080801@gmail.com>
Message-ID: <4F0C99A8.5090901@gmx.ch>

On 10-Jan-12 11:40, nordin wrote:
> If you have a nanoBTS, you can install/setup and run your own network
> very easy. There is no E1 interface needed or a special lib or a
> modified kernel or something. Just install debian and other libs you can
> easily install it with apt, git-clone the project and connect the bts
> with a utp-cable and you're on the go.
> If I can do it, I'm sure everybody else can do it.
>

I installed today Debian and compiled OpenBSC in a VMware machine 
according to the guide here:

http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC

After this I tried to load run osmo-nitb -c and one example config and I 
got the error:

"(000) telnet_interface.c:85 Telnet interface failed to bind"

After 4 hours of searching and trying to see what is wrong I just quit.

> When you get that running, than you can talk about lack of
> documentation, or better design or whatever.
> Good luck.
>

Do you have any idea what is wrong with that error?

I don't have access to any nanoBTS and apparently is hard to get one.
I have other BTS units to test with but all are using E1 and I don't 
have any PCI E1 card. After I will see it running in a VM I will try to 
use a Cisco router to send the Abis from E1 to ethernet in VM.

Regards,
R.



From 246tnt at gmail.com  Tue Jan 10 20:18:56 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 10 Jan 2012 21:18:56 +0100
Subject: OpenBSC development
In-Reply-To: <4F0C99A8.5090901@gmx.ch>
References: <4F098C37.4080101@gmx.ch> <4F0A980A.6080806@gmx.ch>
	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
	<4F0B3452.1070702@gmx.ch> <4F0B4693.7080107@freyther.de>
	<4F0B682E.7030806@gmx.ch> <20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch> <4F0C1586.5080801@gmail.com>
	<4F0C99A8.5090901@gmx.ch>
Message-ID: <CAHL+j0-65u1O8iVD+_A8-gPO4GeN-txzCn7zF0i8m-oDhsWxsg@mail.gmail.com>

Hi,

> "(000) telnet_interface.c:85 Telnet interface failed to bind"

No idea how that could be unless you are on a heavily restricted
system ... or if you have something else listening on port 4242
Basically it means it wasn't able to "listen/open" the port for the
telnet config on port 4242

> I will try to use a
> Cisco router to send the Abis from E1 to ethernet in VM.

I've never been able to find how to do that ... that doesn't seem to
be supported AFAICT ...

Cheers,

     Sylvain



From rp.labs at gmx.ch  Tue Jan 10 21:12:00 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 22:12:00 +0100
Subject: OpenBSC development
In-Reply-To: <CAHL+j0-65u1O8iVD+_A8-gPO4GeN-txzCn7zF0i8m-oDhsWxsg@mail.gmail.com>
References: <4F098C37.4080101@gmx.ch>
	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>
	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>
	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<CAHL+j0-65u1O8iVD+_A8-gPO4GeN-txzCn7zF0i8m-oDhsWxsg@mail.gmail.com>
Message-ID: <4F0CA9A0.8030503@gmx.ch>

On 10-Jan-12 21:18, Sylvain Munaut wrote:
> Hi,
>
>> "(000) telnet_interface.c:85 Telnet interface failed to bind"
>
> No idea how that could be unless you are on a heavily restricted
> system ... or if you have something else listening on port 4242
> Basically it means it wasn't able to "listen/open" the port for the
> telnet config on port 4242
>

The system was installed fresh today with Debian net-install CD (minimal 
install with SSH server option). After this I installed the packages 
listed in wiki plus another one not listed in there, I guess it was 
libortp8 and was a dependency to openbsc.

I checked with netstat and nothing is running on that port. There is no 
SElinux or iptables running on that machine... Strange behavior.

>> I will try to use a
>> Cisco router to send the Abis from E1 to ethernet in VM.
>
> I've never been able to find how to do that ... that doesn't seem to
> be supported AFAICT ...

I will manage it somehow and if not I will try to get a native IP BTS to 
connect to OpenBSC but that one doesn't have any Abis written in OpenBSC 
so it will be tough...

I have the traces for new hardware and I will have to compare with what 
you have to see which one is closer.

Many things to do with no spare time...

> Cheers,
>
>       Sylvain
>

Thank you Sylvain,
R.



From ajlennon at dynamicdevices.co.uk  Tue Jan 10 20:19:01 2012
From: ajlennon at dynamicdevices.co.uk (Alex J Lennon)
Date: Tue, 10 Jan 2012 20:19:01 +0000
Subject: OpenBSC development
In-Reply-To: <4F0C99A8.5090901@gmx.ch>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch> <4F0C1586.5080801@gmail.com>
	<4F0C99A8.5090901@gmx.ch>
Message-ID: <4F0C9D35.20507@dynamicdevices.co.uk>


> "(000) telnet_interface.c:85 Telnet interface failed to bind"

Perhaps a silly question but there isn't anything listening on the socket
you are trying to bind is there? 'netstat -an' would tell you I guess?

Alex




From rp.labs at gmx.ch  Tue Jan 10 21:13:38 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 22:13:38 +0100
Subject: OpenBSC development
In-Reply-To: <4F0C9D35.20507@dynamicdevices.co.uk>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<4F0C9D35.20507@dynamicdevices.co.uk>
Message-ID: <4F0CAA02.5000206@gmx.ch>

On 10-Jan-12 21:19, Alex J Lennon wrote:
>
>> "(000) telnet_interface.c:85 Telnet interface failed to bind"
>
> Perhaps a silly question but there isn't anything listening on the socket
> you are trying to bind is there? 'netstat -an' would tell you I guess?

No, nothing is listening on that port. Checked it a few times and also 
no fw in place...

> Alex
>

Thanks,
R.



From ajlennon at dynamicdevices.co.uk  Tue Jan 10 21:20:14 2012
From: ajlennon at dynamicdevices.co.uk (Alex J Lennon)
Date: Tue, 10 Jan 2012 21:20:14 +0000
Subject: OpenBSC development
In-Reply-To: <4F0CAA02.5000206@gmx.ch>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<4F0C9D35.20507@dynamicdevices.co.uk> <4F0CAA02.5000206@gmx.ch>
Message-ID: <4F0CAB8E.80301@dynamicdevices.co.uk>


 >No, nothing is listening on that port. Checked it a few times and also 
no fw in place...

Stop me if this is all noddy stuff you've already tried, but is it worth 
running
strace to see what exactly is going wrong?

Cheers,
A/

On 10/01/2012 21:13, Labs wrote:
> On 10-Jan-12 21:19, Alex J Lennon wrote:
>>
>>> "(000) telnet_interface.c:85 Telnet interface failed to bind"
>>
>> Perhaps a silly question but there isn't anything listening on the 
>> socket
>> you are trying to bind is there? 'netstat -an' would tell you I guess?
>
> No, nothing is listening on that port. Checked it a few times and also 
> no fw in place...
>
>> Alex
>>
>
> Thanks,
> R.
>



From 246tnt at gmail.com  Tue Jan 10 21:29:17 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 10 Jan 2012 22:29:17 +0100
Subject: OpenBSC development
In-Reply-To: <4F0CAB8E.80301@dynamicdevices.co.uk>
References: <4F098C37.4080101@gmx.ch> <4F0A980A.6080806@gmx.ch>
	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
	<4F0B3452.1070702@gmx.ch> <4F0B4693.7080107@freyther.de>
	<4F0B682E.7030806@gmx.ch> <20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch> <4F0C1586.5080801@gmail.com>
	<4F0C99A8.5090901@gmx.ch> <4F0C9D35.20507@dynamicdevices.co.uk>
	<4F0CAA02.5000206@gmx.ch> <4F0CAB8E.80301@dynamicdevices.co.uk>
Message-ID: <CAHL+j0-LmogPXReJAaE3R5j0f9u8c2EZ1+Zve_kZiM17beiWog@mail.gmail.com>

>>No, nothing is listening on that port. Checked it a few times and also no
>> fw in place...
>
> Stop me if this is all noddy stuff you've already tried, but is it worth
> running
> strace to see what exactly is going wrong?

Yes it'd be interesting because that's an issue that doesn't come up often ...

Cheers,

    Sylvain



From rp.labs at gmx.ch  Tue Jan 10 21:47:42 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 22:47:42 +0100
Subject: OpenBSC development
In-Reply-To: <CAHL+j0-LmogPXReJAaE3R5j0f9u8c2EZ1+Zve_kZiM17beiWog@mail.gmail.com>
References: <4F098C37.4080101@gmx.ch>
	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>
	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>
	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<4F0C9D35.20507@dynamicdevices.co.uk>	<4F0CAA02.5000206@gmx.ch>
	<4F0CAB8E.80301@dynamicdevices.co.uk>
	<CAHL+j0-LmogPXReJAaE3R5j0f9u8c2EZ1+Zve_kZiM17beiWog@mail.gmail.com>
Message-ID: <4F0CB1FE.1050806@gmx.ch>

On 10-Jan-12 22:29, Sylvain Munaut wrote:
>>> No, nothing is listening on that port. Checked it a few times and also no
>>> fw in place...
>>
>> Stop me if this is all noddy stuff you've already tried, but is it worth
>> running
>> strace to see what exactly is going wrong?

I will do that and report back. I will connect now on the box.

>
> Yes it'd be interesting because that's an issue that doesn't come up often ...
>

I was thinking that it is a particular case because there is no info 
about it searching on the web..

> Cheers,
>
>      Sylvain
>
>

Regards,
R.



From rp.labs at gmx.ch  Tue Jan 10 22:08:26 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 23:08:26 +0100
Subject: OpenBSC development
In-Reply-To: <4F0CB1FE.1050806@gmx.ch>
References: <4F098C37.4080101@gmx.ch>
	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>
	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>
	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<4F0C9D35.20507@dynamicdevices.co.uk>	<4F0CAA02.5000206@gmx.ch>
	<4F0CAB8E.80301@dynamicdevices.co.uk>
	<CAHL+j0-LmogPXReJAaE3R5j0f9u8c2EZ1+Zve_kZiM17beiWog@mail.gmail.com>
	<4F0CB1FE.1050806@gmx.ch>
Message-ID: <4F0CB6DA.7080907@gmx.ch>

On 10-Jan-12 22:47, Labs wrote:
>
> I will do that and report back. I will connect now on the box.

When I left from work I shut down the VM and now after power on it seems 
to work using the command:

osmo-nitb -c hsl/openbsc.cfg

But that is not all, if I stop the process with Ctrl+Z and run it again 
(same command) I get the error mentioned below:

"(000) telnet_interface.c:85 Telnet interface failed to bind"

I just pressed the Ctrl+Z because Ctrl-C was not working and I forgot to 
use -D parameter to run it as a daemon.

I will install strace and give you more details. If you have a test 
machine try the same steps maybe you can reproduce it on another 
installation. If not it means is something wrong on my machine only.

Version used is the one available on git repository in the morning. 
Don't know if other code was committed in the mean time.

Thanks,
R.



From 246tnt at gmail.com  Tue Jan 10 22:18:26 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 10 Jan 2012 23:18:26 +0100
Subject: OpenBSC development
In-Reply-To: <4F0CB6DA.7080907@gmx.ch>
References: <4F098C37.4080101@gmx.ch> <4F0A980A.6080806@gmx.ch>
	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
	<4F0B3452.1070702@gmx.ch> <4F0B4693.7080107@freyther.de>
	<4F0B682E.7030806@gmx.ch> <20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch> <4F0C1586.5080801@gmail.com>
	<4F0C99A8.5090901@gmx.ch> <4F0C9D35.20507@dynamicdevices.co.uk>
	<4F0CAA02.5000206@gmx.ch> <4F0CAB8E.80301@dynamicdevices.co.uk>
	<CAHL+j0-LmogPXReJAaE3R5j0f9u8c2EZ1+Zve_kZiM17beiWog@mail.gmail.com>
	<4F0CB1FE.1050806@gmx.ch> <4F0CB6DA.7080907@gmx.ch>
Message-ID: <CAHL+j09NrGcy89HGxU-G3-7eyY91WcU3U3NYeNukOJsOLoHuhQ@mail.gmail.com>

> When I left from work I shut down the VM and now after power on it seems to
> work using the command:
>
> osmo-nitb -c hsl/openbsc.cfg
>
> But that is not all, if I stop the process with Ctrl+Z and run it again
> (same command) I get the error mentioned below:
>
> "(000) telnet_interface.c:85 Telnet interface failed to bind"

Well that's expected ... if you do CTRL-Z, the process is "stopped"
but still exists (it's not terminated) and so the associated resources
are still allocated to it, including ownership of port 4242 ... so you
can't launch a second process that would use the same stuff ...

That's standard unix stuff.

Cheers,

   Sylvain



From rp.labs at gmx.ch  Tue Jan 10 22:38:23 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 23:38:23 +0100
Subject: OpenBSC development
In-Reply-To: <CAHL+j09NrGcy89HGxU-G3-7eyY91WcU3U3NYeNukOJsOLoHuhQ@mail.gmail.com>
References: <4F098C37.4080101@gmx.ch>
	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>
	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>
	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<4F0C9D35.20507@dynamicdevices.co.uk>	<4F0CAA02.5000206@gmx.ch>
	<4F0CAB8E.80301@dynamicdevices.co.uk>	<CAHL+j0-LmogPXReJAaE3R5j0f9u8c2EZ1+Zve_kZiM17beiWog@mail.gmail.com>	<4F0CB1FE.1050806@gmx.ch>
	<4F0CB6DA.7080907@gmx.ch>
	<CAHL+j09NrGcy89HGxU-G3-7eyY91WcU3U3NYeNukOJsOLoHuhQ@mail.gmail.com>
Message-ID: <4F0CBDDF.2010504@gmx.ch>

On 10-Jan-12 23:18, Sylvain Munaut wrote:
>
> Well that's expected ... if you do CTRL-Z, the process is "stopped"
> but still exists (it's not terminated) and so the associated resources
> are still allocated to it, including ownership of port 4242 ... so you
> can't launch a second process that would use the same stuff ...
>

I replied to my email earlier and I just saw yours now.

> That's standard unix stuff.

I don't know what I was thinking at that time in the morning...

> Cheers,
>
>     Sylvain
>



From rp.labs at gmx.ch  Tue Jan 10 22:34:21 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 23:34:21 +0100
Subject: OpenBSC development
In-Reply-To: <4F0CB6DA.7080907@gmx.ch>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>	<4F0C9D35.20507@dynamicdevices.co.uk>	<4F0CAA02.5000206@gmx.ch>	<4F0CAB8E.80301@dynamicdevices.co.uk>	<CAHL+j0-LmogPXReJAaE3R5j0f9u8c2EZ1+Zve_kZiM17beiWog@mail.gmail.com>	<4F0CB1FE.1050806@gmx.ch>
	<4F0CB6DA.7080907@gmx.ch>
Message-ID: <4F0CBCED.90807@gmx.ch>

On 10-Jan-12 23:08, Labs wrote:
> On 10-Jan-12 22:47, Labs wrote:
>>
>> I will do that and report back. I will connect now on the box.
>
> When I left from work I shut down the VM and now after power on it seems
> to work using the command:
>
> osmo-nitb -c hsl/openbsc.cfg
>
> But that is not all, if I stop the process with Ctrl+Z and run it again
> (same command) I get the error mentioned below:
>
> "(000) telnet_interface.c:85 Telnet interface failed to bind"
>
> I just pressed the Ctrl+Z because Ctrl-C was not working and I forgot to
> use -D parameter to run it as a daemon.
>

I'm stupid!
Problem was that I used Ctrl+Z (which sends SIGSUSP) and if I run strace 
says "Address already in use", that's why it complains that it cannot 
bind. After this step I saw that running netstat, 127.0.0.1:4242 is used 
and also a ps reports that it is running.

I just killed the process and started again and it worked. This time I 
stopped it with Ctrl+C (odd that is working now, probably some virtual 
machine issue?!) and run it again. Of course it works.

Thanks guys for your help. It works like a charm :-)

Regards,
R.



From ptr.yuan at googlemail.com  Tue Jan 10 21:46:53 2012
From: ptr.yuan at googlemail.com (Peter Yuan)
Date: Tue, 10 Jan 2012 22:46:53 +0100
Subject: OpenBSC development
In-Reply-To: <4F0C99A8.5090901@gmx.ch>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch> <4F0C1586.5080801@gmail.com>
	<4F0C99A8.5090901@gmx.ch>
Message-ID: <4F0CB1CD.4050109@googlemail.com>

Hi all,

Labs wrote:
> On 10-Jan-12 11:40, nordin wrote:
>> If you have a nanoBTS, you can install/setup and run your own network
>> very easy. There is no E1 interface needed or a special lib or a
>> modified kernel or something. Just install debian and other libs you can
>> easily install it with apt, git-clone the project and connect the bts
>> with a utp-cable and you're on the go.
>> If I can do it, I'm sure everybody else can do it.
>>
>
> I installed today Debian and compiled OpenBSC in a VMware machine
> according to the guide here:
>
> http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
>
> After this I tried to load run osmo-nitb -c and one example config and
> I got the error:

I also managed to build openBSC today succesfully an Debian VM.
(jfyi: libortp-dev had to be installed additionally which had not been
mentioned in the doc.)
I also want to play around with the nitb configuration.

Therefore I'd like to support you by testing and maybe also coding.
And that's why I'd like to get me some hardware BTS for testing.
Is there any available as I couldn't find any on the great bay.

Cheers,
ptr




From ptr.yuan at googlemail.com  Tue Jan 10 22:25:03 2012
From: ptr.yuan at googlemail.com (Peter Yuan)
Date: Tue, 10 Jan 2012 23:25:03 +0100
Subject: OpenBSC development
In-Reply-To: <4F0C99A8.5090901@gmx.ch>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch> <4F0C1586.5080801@gmail.com>
	<4F0C99A8.5090901@gmx.ch>
Message-ID: <4F0CBABF.4050809@googlemail.com>

Hi all,

Labs wrote:
> On 10-Jan-12 11:40, nordin wrote:
>> If you have a nanoBTS, you can install/setup and run your own network
>> very easy. There is no E1 interface needed or a special lib or a
>> modified kernel or something. Just install debian and other libs you can
>> easily install it with apt, git-clone the project and connect the bts
>> with a utp-cable and you're on the go.
>> If I can do it, I'm sure everybody else can do it.
>>
>
> I installed today Debian and compiled OpenBSC in a VMware machine
> according to the guide here:
>
> http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
>
> After this I tried to load run osmo-nitb -c and one example config and
> I got the error:

I also managed to build openBSC today succesfully an Debian VM.
(jfyi: libortp-dev had to be installed additionally which had not been
mentioned in the doc.)
I also want to play around with the nitb configuration.

Therefore I'd like to support you by testing and maybe also coding.
And that's why I'd like to get me some hardware BTS for testing.
Is there any available as I couldn't find any on the great bay.

Cheers,
ptr




From rp.labs at gmx.ch  Tue Jan 10 22:46:04 2012
From: rp.labs at gmx.ch (Labs)
Date: Tue, 10 Jan 2012 23:46:04 +0100
Subject: OpenBSC development
In-Reply-To: <4F0CBABF.4050809@googlemail.com>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<4F0CBABF.4050809@googlemail.com>
Message-ID: <4F0CBFAC.3080001@gmx.ch>

On 10-Jan-12 23:25, Peter Yuan wrote:
> Hi all,

Hello Peter,

> I also managed to build openBSC today succesfully an Debian VM.
> (jfyi: libortp-dev had to be installed additionally which had not been
> mentioned in the doc.)

Yes, that's the package.

> I also want to play around with the nitb configuration.

It looks much better than the wiki doc. I really like it.

>
> Therefore I'd like to support you by testing and maybe also coding.
> And that's why I'd like to get me some hardware BTS for testing.
> Is there any available as I couldn't find any on the great bay.
>

I just saw this one earlier but the guy says it sends it to US only.
http://www.ebay.com/itm/1-USED-NANO-BTS-165B-PARTS-REPAIR-ONLY-/220926719447?pt=LH_DefaultDomain_0&hash=item33704235d7

I have the hardware at work and I also look for something small at home.

We have some old Siemens that might work with BS-11 config and new ones 
that are totally different in concept that I will not be able I guess to 
use it besides the vendor BSC.

> Cheers,
> ptr
>
Regards,
R.



From ptr.yuan at googlemail.com  Wed Jan 11 12:49:12 2012
From: ptr.yuan at googlemail.com (Peter Yuan)
Date: Wed, 11 Jan 2012 13:49:12 +0100
Subject: OpenBSC development
In-Reply-To: <4F0CBFAC.3080001@gmx.ch>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>
	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>
	<4F0CBABF.4050809@googlemail.com> <4F0CBFAC.3080001@gmx.ch>
Message-ID: <4F0D8548.8040004@googlemail.com>

Hi,

Labs wrote:
> I just saw this one earlier but the guy says it sends it to US only.
> http://www.ebay.com/itm/1-USED-NANO-BTS-165B-PARTS-REPAIR-ONLY-/220926719447?pt=LH_DefaultDomain_0&hash=item33704235d7
>
>
> I have the hardware at work and I also look for something small at home.
>
> We have some old Siemens that might work with BS-11 config and new
> ones that are totally different in concept that I will not be able I
> guess to use it besides the vendor BSC.

so it seems kind of hard to get hardware at the moment.

Quote of http://openbsc.osmocom.org/trac/wiki/OpenBSC#Thingsthatwork:
> Things that are not implemented
>     Cell Broadcast
>     Any type of transcoding of voice data
>     TCH/H voice calls (they work in osmo-bsc, but not in osmo-nitb)
>     CSD? calls
>     emergency call handling (works in osmo-bsc, but not in osmo-nitb)
>     Discontinuous TX and RX (DTX? / DRX?) support 
Is this list still up to date? Somebody working on one of these topics?
Which of these topics do you think is easiest to get one's hands on?

Cheers
ptr



From rp.labs at gmx.ch  Wed Jan 11 21:29:05 2012
From: rp.labs at gmx.ch (Labs)
Date: Wed, 11 Jan 2012 22:29:05 +0100
Subject: OpenBSC development
In-Reply-To: <4F0D8548.8040004@googlemail.com>
References: <4F098C37.4080101@gmx.ch>	<4F0A980A.6080806@gmx.ch>	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>	<4F0B3452.1070702@gmx.ch>	<4F0B4693.7080107@freyther.de>	<4F0B682E.7030806@gmx.ch>	<20120109224808.13953.qmail@stuge.se>	<4F0B7BA5.2090802@gmx.ch>	<4F0C1586.5080801@gmail.com>	<4F0C99A8.5090901@gmx.ch>	<4F0CBABF.4050809@googlemail.com>
	<4F0CBFAC.3080001@gmx.ch> <4F0D8548.8040004@googlemail.com>
Message-ID: <4F0DFF21.7090807@gmx.ch>

On 11-Jan-12 13:49, Peter Yuan wrote:

Hello Peter,

>
> so it seems kind of hard to get hardware at the moment.

Yes it is. On ebay in EU it's almost zero chance if you want one fast.
I found a lot of modules from Ericsson but not a complete BTS so you 
will have to wait. If you don't mind paying the shipping from overseas 
and taxes you can find many BTS units from US or Asian countries.

Regards,
Razvan



From peter at stuge.se  Wed Jan 11 00:00:35 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 11 Jan 2012 01:00:35 +0100
Subject: OpenBSC development
In-Reply-To: <4F0B7BA5.2090802@gmx.ch>
References: <4F098C37.4080101@gmx.ch> <4F0A980A.6080806@gmx.ch>
	<CAHL+j09bPtw6P7dYa3Lc0VncEMSPmx4jWbB9yfM1sbVXegPbiA@mail.gmail.com>
	<4F0B3452.1070702@gmx.ch> <4F0B4693.7080107@freyther.de>
	<4F0B682E.7030806@gmx.ch> <20120109224808.13953.qmail@stuge.se>
	<4F0B7BA5.2090802@gmx.ch>
Message-ID: <20120111000035.22424.qmail@stuge.se>

Labs wrote:
>> We had some tangential discussions at 28c3 in Berlin between X-mas
>> and NYE, where we last ran an OpenBSC test network.
>
> So there are more people thinking like me?

I started an early discussion because I was thinking of how we could
make it even easier to run an OpenBSC CCC event network, which has
been done on a handful of times by now but mostly with some amount of
manual labour also on the software side, and without producing
documentation.

My idea so far is to start with a so-called spec file for the Gentoo
catalyst tool, which can be used to very conveniently build a
ready-to-run system. That work would be reusable for a VM image.


>> * The OpenBSC software may be integrated in many different ways
>>
>> OpenBSC does not neccessarily run only on Linux operating systems
>> (maybe this is actually a requirement now, but I don't think it needs
>> to be, and generally it is good to have software be portable across
>> many different operating systems) - this is significant because any
>> interface configuration is always highly system specific, and every
>> integration will have different processes here. Following the UNIX
>> principle, this is outside the scope of OpenBSC. Ie. interface
>> configuration is one step considered belonging to the base system,
>> while software configuration to use those interfaces is a separate
>> step which needs to match the system base configuration.
>
> I am thinking that you always need to separate the traffic based on 
> destination. That being said you will not use the same interface for 
> management of the box and also for Abis or A interfaces.

You can.


> All of them should be separately defined.

Not neccessarily.


> Management interface can be defined via normal OS way (or an OpenBSC 
> GUI/startup menu?)

This part falls very clearly outside the scope of the OpenBSC
software. It could however be part of another, "higher level"
software project, something like a Linux distribution tailed
to OpenBSC.


> but the rest of interfaces should be defined via OpenBSC 
> config. I don't know how it works now, is there any "limitation"
> or you can have everything on one ethernet interface?

OpenBSC does nothing at all with interfaces, and does not care where
or how communication goes as long as it has IP connectivity with the
units it needs to communicate with. Management and BTSes can be on
the same network if so desired.


> design should be done in advance

I am sure that you appreciate that OpenBSC was not put together
without design. Please be careful with wording.


> so there will not be a complete re-write of the code in case of
> small/big? changes.

If you're not a programmer it seems you're now venturing into a field
you may not be experienced in. The developers in OpenBSC are, on the
other hand, quite experienced. Don't worry about the code quality.

Re-write is not neccessary to avoid at all cost, especially not at
very high design cost. In fact, one solution in the short term is
perfectly fine even if a different solution has already been foreseen
to be neccessary in the medium term.


>> If it happens I would argue that OpenBSC should configure only those
>> interfaces which are related to GSM, and that they be kept separate
>> from the "regular" interfaces used by the system.
>
> Correct, agree.

It's important to remember that OpenBSC supporting such configuration
MUST NOT mean that operations and management are suddenly required to
be on different interfaces. But this is easy; OpenBSC will just not
do any configuration at all unless told to do it.


>> Such a change will tie OpenBSC more strongly to the particular
>> operating systems it runs on, which is generally considered a bad
>> thing.
>
> It is considered bad but you cannot just keep on testing different 
> behaviors on all Linux flavors.

Oh it's not about Linux distributions. Linux is a single operating
system. Distributions are not relevant. I'm talking about various
variants of BSD, Windows and Solaris.


> I think most, probably 99%, are running the project on Debian.

Again, this does not, and MUST NOT, matter. OpenBSC is not and will
quite likely never be debian specific.


> I guess I put it in the wrong way in my first email. I work with CLI 
> everyday but for some things I like the GUI. I am probably used with 
> the commercial BSC CLI/GUI so...

Of course all constructive ideas for the user interface are
interesting. Since the CLI is what is currently there it can be
compared with other BSC CLI, and if OpenBSC can be made even better
than it is then of course the good ideas should not get lost.


> I prefer to have a GUI for checking fast some transmission line parameters 
> (type/line code/BER results/IP address of BTS), check and reset different 
> BTS boards that go crazy sometime...
>
> I am not sure what you can do now in regard to BTS components/modules

The "show bts 1" command is probably a good start. Of course, if you
think it should be extended with further important information then
let's hear about it.


> and if the OML commands sent to BTS can do the above things.

That depends on the BTS, right?


//Peter



From laforge at gnumonks.org  Mon Jan  9 11:32:38 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Jan 2012 12:32:38 +0100
Subject: OpenBSC development
In-Reply-To: <4F0A980A.6080806@gmx.ch>
References: <4F098C37.4080101@gmx.ch>
 <4F0A980A.6080806@gmx.ch>
Message-ID: <20120109113238.GG7738@prithivi.gnumonks.org>

Hi again,

On Mon, Jan 09, 2012 at 08:32:26AM +0100, Labs wrote:

> I already checked the link but the package repository doesn't keep
> up with updates from git repository. Most of them were built in the
> summer last year, that's why I wanted a nightly built to have the
> latest bug fixes and features.

Are you volunteering to setup and maintain such a repository?

Pleaes don't try to issue complaints/demands to people who are
constantly overworked and who already give away all the results of their
work as Free Software.  We publish our software in source code form for
everyone to be used.

If somebody steps up and maintains such repositories, fine, we certainly
welcome that.  But I don't see the very small group of developers
spending their non-existing spare time on building packages for
god-knows-how-many different Linux distributions and other platforms out
there, sorry.

> I was talking about all config parameters to be in one DB and not in
> text files. Also it can be an XML file with all configuration and
> not many text files.

It right now is exactly _one_ text file for OpenBSC, containing _all_
parameters.  So I don't really see what XML would gain us, apart from
being unreadable by human users, and requiring bloated large libraries
for parsing and validation of the data.

> From VTY just run let's say "backup live-config" command and you
> will have an XML with all configuration that you can move on other
> hardware.

> XML should contain everything like E1 or IP settings, BTS and cell
> parameters, etc.

we have exactly that with openbsc.cfg. Just not XML.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From holger at freyther.de  Mon Jan  9 18:45:24 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 09 Jan 2012 19:45:24 +0100
Subject: OpenBSC development
In-Reply-To: <4F0A980A.6080806@gmx.ch>
References: <4F098C37.4080101@gmx.ch> <4F0A980A.6080806@gmx.ch>
Message-ID: <4F0B35C4.1010107@freyther.de>

On 01/09/2012 08:32 AM, Labs wrote:
> On 01/08/2012 02:33 PM, Holger Hans Peter Freyther wrote:


> I guess you were referring to osmo-nitb.
> http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY


The above page shows the problem. We have an outdated and incomplete VTY
documentation, being the engineer I am, I think we should automatically
generate it (see mails from December/November).

holger



From rp.labs at gmx.ch  Mon Jan  9 22:05:37 2012
From: rp.labs at gmx.ch (Labs)
Date: Mon, 09 Jan 2012 23:05:37 +0100
Subject: OpenBSC development
In-Reply-To: <4F0B35C4.1010107@freyther.de>
References: <4F098C37.4080101@gmx.ch> <4F0A980A.6080806@gmx.ch>
	<4F0B35C4.1010107@freyther.de>
Message-ID: <4F0B64B1.7000203@gmx.ch>

On 09-Jan-12 19:45, Holger Hans Peter Freyther wrote:
>> I guess you were referring to osmo-nitb.
>> http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY
>
>
> The above page shows the problem. We have an outdated and incomplete VTY
> documentation, being the engineer I am, I think we should automatically
> generate it (see mails from December/November).

I think you are referring to this link?
http://lists.osmocom.org/pipermail/openbsc/2011-December/003441.html

No reply to your thread...

I will try to get an OpenBSC running by the end of next week and check 
the VTY/CLI commands. :)

> holger
>

R.




From upajmahat at gmail.com  Mon Jan  9 05:24:13 2012
From: upajmahat at gmail.com (Upaj Mahat)
Date: Mon, 9 Jan 2012 11:09:13 +0545
Subject: Required open BSC
Message-ID: <CAKemHJ-1z+4mN+9zQKz73T=JSuOz_9m5dX2_OmSfCvP4N+diyg@mail.gmail.com>

Dear all,

              I work for a mobile operator and we are working on R&D to
improve the quality of our network. For our R&D we required a open BSC, is
there any one who sells open BSC. If there is anyone then our company is
willing to buy one.

Regards
Upaj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120109/0aa00173/attachment.htm>

From holger at freyther.de  Mon Jan  9 08:40:31 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Mon, 09 Jan 2012 09:40:31 +0100
Subject: Required open BSC
In-Reply-To: <CAKemHJ-1z+4mN+9zQKz73T=JSuOz_9m5dX2_OmSfCvP4N+diyg@mail.gmail.com>
References: <CAKemHJ-1z+4mN+9zQKz73T=JSuOz_9m5dX2_OmSfCvP4N+diyg@mail.gmail.com>
Message-ID: <4F0AA7FF.6090603@freyther.de>

On 01/09/2012 06:24 AM, Upaj Mahat wrote:
> Dear all, 
> 
>               I work for a mobile operator and we are working on R&D to
> improve the quality of our network. For our R&D we required a open BSC, is
> there any one who sells open BSC. If there is anyone then our company is
> willing to buy one.

Hi,

this is a Free Software Project[1]. For the BSC we are using the "GNU Affero
General Public License version 3 (or later)"[2] license, this license grants
you various rights but also sets some requirements (e.g. as you benefited of
the work of others, in case you do improvements you will need to offer the
users of the BSC the sourcecode, or publish it at osmocom.org)

This means to use the software you don't need to buy anything from the project
(you already have a License), we are happy to answer technical questions (e.g
not ask how to compile it). In case you really need to buy something, there
are people that can help you but this list is not the right place.

holger

[1] http://simple.wikipedia.org/wiki/Free_software
[2] http://www.gnu.org/licenses/agpl.html



From rp.labs at gmx.ch  Mon Jan  9 20:26:34 2012
From: rp.labs at gmx.ch (Labs)
Date: Mon, 09 Jan 2012 21:26:34 +0100
Subject: Required open BSC
In-Reply-To: <CAKemHJ-1z+4mN+9zQKz73T=JSuOz_9m5dX2_OmSfCvP4N+diyg@mail.gmail.com>
References: <CAKemHJ-1z+4mN+9zQKz73T=JSuOz_9m5dX2_OmSfCvP4N+diyg@mail.gmail.com>
Message-ID: <4F0B4D7A.1080604@gmx.ch>

On 09-Jan-12 06:24, Upaj Mahat wrote:
> Dear all,
>
>                I work for a mobile operator and we are working on R&D to
> improve the quality of our network. For our R&D we required a open BSC,
> is there any one who sells open BSC. If there is anyone then our company
> is willing to buy one.

If you are working for a mobile operator just take an unused server 
(there should be many I guess), install Debian, setup git, build the 
project and attach the real BTS to it. If your BTS is not supported just 
make a trace on Abis from vendor's BSC and ask/post in here and probably 
somebody will help you. I guess BTS units for "r&d" you have plenty so 
you can make tests with different types and multi-TRX configs.

> Regards
> Upaj

Regards,
R.



From holger at freyther.de  Thu Jan 12 22:35:37 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 12 Jan 2012 23:35:37 +0100
Subject: LAPDm, msgb and osmo-bts breakage
Message-ID: <4F0F6039.9070702@freyther.de>

Hi Jolly,

I have finally tracked down the LAPDm breakage we have in osmo-bts. It comes 
from the fact that we get a RSL message from the BSC and then forward the msgb 
that holds the IPA header followed by the RSL message. There is code in both 
lapdm.c and lapd_core.c that tries to extract the RSL_IE_L3_INFO and then 
updates the msgb to be of the length of that TLV and sets the l3h to the start 
of the L3_INFO:


Currently:
         msgb_pull_l2h(msg);
         msg->len = length;
         msg->tail = msg->data + length;

this kind of assumes that before the "msgb_pull_l2h", msg->l2h == msg->data 
but in the above case it does not hold true. You will need to use "msg->l3h + 
length" with this idiom.

Fixes:
I have pushed some fixes to "zecke/lapd-fixes", but I would like to see the
above pattern move to msgb.h, and it would be nice if we could write test 
cases for the other methods in lapdm.c that manipulate the msgb.h (currently 
only data request is tested).


One more thing:
I would be somehow happy if lapdm_rslms_recvmsg would indicate if any messages 
were sent or queued, currently it will return 0 in more than one case.


cheers
	holger



From andreas at eversberg.eu  Fri Jan 13 06:07:10 2012
From: andreas at eversberg.eu (jolly)
Date: Fri, 13 Jan 2012 07:07:10 +0100
Subject: LAPDm, msgb and osmo-bts breakage
In-Reply-To: <4F0F6039.9070702@freyther.de>
References: <4F0F6039.9070702@freyther.de>
Message-ID: <4F0FCA0E.2080701@eversberg.eu>


> Currently:
>         msgb_pull_l2h(msg);
>         msg->len = length;
>         msg->tail = msg->data + length;
hi holger,

you are right. the header (between l2h and l3h) is pulled away, but this
code assumes that there is nothing in front. you must use "msg->tail =
msg->l3h + lenght" to correctly set the length of the L3 data, in case
you have still something in front of l2h, so that l2h != data. since
osmocom does not have something in front of l2h, it works, even if it is
not the clean way.

regards,

andreas




From andreas at eversberg.eu  Tue Jan 17 16:28:00 2012
From: andreas at eversberg.eu (jolly)
Date: Tue, 17 Jan 2012 17:28:00 +0100
Subject: two minor bugs in libosmo-abis
Message-ID: <4F15A190.7030903@eversberg.eu>

hi,

i fixed two obvious bugs in libosmo-abis. the first fix uses correct reference for mISDN interface number, the other handles variable frame lengths. both are tested. if nobody minds, i like to commit them.

regards,

andreas



Fixed wrong reference while opening mISDN socket

diff --git a/src/input/misdn.c b/src/input/misdn.c
index 2ed152e..5fdd847 100644
--- a/src/input/misdn.c
+++ b/src/input/misdn.c
@@ -484,7 +484,7 @@ static int mi_e1_setup(struct e1inp_line *line, int release_l2)
 			}
 			memset(&addr, 0, sizeof(addr));
 			addr.family = AF_ISDN;
-			addr.dev = line->num;
+			addr.dev = line->port_nr;
 			addr.channel = 0;
 			addr.sapi = 0;
 			addr.tei = GROUP_TEI;


Fixed TRAU frame handling of packet lengths that are not a multiple of 4

diff --git a/src/subchan_demux.c b/src/subchan_demux.c
index 41fe1d2..8613c17 100644
--- a/src/subchan_demux.c
+++ b/src/subchan_demux.c
@@ -102,10 +102,6 @@ int subch_demux_in(struct subch_demux *dmx, uint8_t *data, int len)
 {
 	int i, c;
 
-	/* we avoid partially filled bytes in outbuf */
-	if (len % 4)
-		return -EINVAL;
-
 	for (i = 0; i < len; i++) {
 		uint8_t inbyte = data[i];
 




From laforge at gnumonks.org  Wed Jan 18 00:09:14 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 18 Jan 2012 01:09:14 +0100
Subject: two minor bugs in libosmo-abis
In-Reply-To: <4F15A190.7030903@eversberg.eu>
References: <4F15A190.7030903@eversberg.eu>
Message-ID: <20120118000914.GK7995@prithivi.gnumonks.org>

On Tue, Jan 17, 2012 at 05:28:00PM +0100, jolly wrote:
> hi,
> 
> i fixed two obvious bugs in libosmo-abis. the first fix uses correct
> reference for mISDN interface number, the other handles variable frame
> lengths. both are tested. if nobody minds, i like to commit them.

seems fine to me.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From hello2anjali.sharma at gmail.com  Wed Jan 18 13:52:45 2012
From: hello2anjali.sharma at gmail.com (Anjali Sharma)
Date: Wed, 18 Jan 2012 22:52:45 +0900
Subject: CRC
Message-ID: <CAPvskLQHD2r5VeT74M_n770f==E1CfVo74TUyqM4BfMtuE+2jA@mail.gmail.com>

I am trying to generate CRC table mentioned in
openbsc/src/gprs/crc24.c file
(http://lingrok.org/source/xref/openbsc/openbsc/src/gprs/crc24.c)

I modified a CRC16 code to generate CRC24 (updated polynomial as per
LLC specification). But I can not get right table.

Below is source code. Can someone help me out?

//******************************************************************************
//
//    Copyright (c) 1999 Axon Instruments.
//    All rights reserved.
//
//******************************************************************************
// HEADER:  CRC16.cpp
// PURPOSE: Contains functions calculating a 16 bit CRC code.
// SOURCE:  http://www.brokersys.com/snippets/   file: CRC_16F.C
//

#define POLYNOMIAL 0xAD85DD
#define CRC_WIDTH 24
#define BITS_PER_BYTE 8

typedef unsigned int WORD;
typedef unsigned int UINT;
typedef char BYTE;

static WORD correctCRCtable[1<<BITS_PER_BYTE] =     // as per
openbsc/src/gprs/crc24.c
{
	0x00000000, 0x00d6a776, 0x00f64557, 0x0020e221, 0x00b78115,
0x00612663, 0x0041c442, 0x00976334,
	0x00340991, 0x00e2aee7, 0x00c24cc6, 0x0014ebb0, 0x00838884,
0x00552ff2, 0x0075cdd3, 0x00a36aa5,
	/* skip rest */
};

void InitCRCtab()
{
   int v, i;
   int b;

   for ( b = 0; b <= (1<<BITS_PER_BYTE)-1; ++b )
   {
      int v = b << (CRC_WIDTH-BITS_PER_BYTE);
	  int i;
      for (i = BITS_PER_BYTE; --i >= 0; )
         v = v&0x800000 ? (v<<1) ^ POLYNOMIAL : v<<1;

	  if((v & 0xFFFFFF) == correctCRCtable[b])
		  correctCRCtable[b] = v;
	  else {
		  printf("Incorrect CRC table\n");
		  printf("correctCRCtable[%d]=0x%06x calculated=0x%06x\n", b,
correctCRCtable[b], v&0xFFFFFF);
		  exit(0);
	  }
   }
}

int main()
{
	InitCRCtab();
	printf("Correct CRC table\n");
	return 0;
}

/*
Below is LLC specification:

The FCS field shall consist of a 24?bit cyclic redundancy check (CRC)
code. The CRC-24 is used to detect bit errors in the frame header and
information fields.

The FCS field contains the value of a CRC calculation that is
performed over the entire contents of the header and information
field, except for UI frames transmitted in unprotected mode, in which
case the FCS field contains the value of a CRC calculation that is
performed over the frame header and the first N202 octets (see
subclause?8.9.6) of the information field only (see subclause
6.3.5.5.2). The information over which the CRC is calculated is
referred to as the dividend in this subclause. Bit?(1,?1) of the
dividend is the highest-order term in the calculation (see subclause
5.7.3). CRC calculation shall be done before ciphering at the
transmitting side, and after deciphering at the receiving side.
NOTE:	The definition below is different from that in 3GPP TS?24.022
[10] only with respect to the variable dividend length k of the LLC
frames. In 3GPP TS?24.022, the RLP frame has a fixed dividend length,
but the LLC frame has a variable dividend length.

The CRC shall be the ones complement of the sum (modulo?2) of:
-	the remainder of x^k?(x^23?+?x^22?+?x^21?+...?+?x^2?+?x?+?1) divided
(modulo?2) by the generator polynomial, where k is the number of bits
of the dividend; and
-	the remainder of the division (modulo?2) by the generator polynomial
of the product of x^24 by the dividend.

The CRC-24 generator polynomial is:
G(x)?=?x^24?+?x^23?+?x^21?+?x^20?+?x^19?+?x^17?+?x^16?+?x^15?+?x^13?+
x^8?+?x^7?+?x^5?+?x^4?+?x^2?+?1

The result of the CRC calculation is placed within the FCS field as
described in subclause?5.7.3.

NOTE:	As a typical implementation at the transmitter, the initial
content of the register of the device computing the remainder of the
division is pre-set to all "1's" and is then modified by division by
the generator polynomial (as described above) of the dividend; the
ones complement of the resulting remainder is put into the FCS field.
As a typical implementation at the receiver, the initial content of
the register of the device computing the remainder of the division is
pre-set to all "1's". The final remainder, after multiplication by x24
and then division (modulo?2) by the generator polynomial of the
received frame, will be (in the absence of errors):
C(x)?=?x^22?+?x^21?+?x^19?+?x^18?+?x^16?+?x^15?+?x^11?+?x^8?+?x^5?+?x^4
 */



From laforge at gnumonks.org  Fri Jan 20 08:16:37 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 20 Jan 2012 09:16:37 +0100
Subject: CRC
In-Reply-To: <CAPvskLQHD2r5VeT74M_n770f==E1CfVo74TUyqM4BfMtuE+2jA@mail.gmail.com>
References: <CAPvskLQHD2r5VeT74M_n770f==E1CfVo74TUyqM4BfMtuE+2jA@mail.gmail.com>
Message-ID: <20120120081637.GH834@prithivi.gnumonks.org>

Hi Anjali,

On Wed, Jan 18, 2012 at 10:52:45PM +0900, Anjali Sharma wrote:
> //    Copyright (c) 1999 Axon Instruments.
> //    All rights reserved.

So it seems you're working on a proprietary implementation, and you're
asking on a list dedicated to the development of Free Software for help
with your implementation?

If this is the case, I think you seem to misunderstand the intention and
motivation of the people on this list.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From peter at caprioli.se  Thu Jan 19 17:29:58 2012
From: peter at caprioli.se (Peter Caprioli)
Date: Thu, 19 Jan 2012 18:29:58 +0100
Subject: SimpleHLR: A web interface for OpenBSC
Message-ID: <CAJ9yJzH1wnC61xMzpxbWO5zjV+oGHrZZ-27G=bmbLGpEODZazQ@mail.gmail.com>

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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120119/76a43237/attachment.htm>

From caprioli32 at gmail.com  Thu Jan 19 18:04:54 2012
From: caprioli32 at gmail.com (Peter Caprioli)
Date: Thu, 19 Jan 2012 19:04:54 +0100
Subject: SimpleVLR: A webinterface for OpenBSC
Message-ID: <CAJ9yJzHV6ffzCubzF=tt_oWGB4k8b0JaXbor3P1vC2NQ3=fdWQ@mail.gmail.com>

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 at my website:
https://stormhub.org/simplehlr/

Best regards,
Peter Caprioli



From jmercury616 at gmail.com  Fri Jan 20 11:37:48 2012
From: jmercury616 at gmail.com (Jason Mercury)
Date: Fri, 20 Jan 2012 13:37:48 +0200
Subject: nanoBTS failure
Message-ID: <CAECA2oJ9v8HWrP8SQBFPCrYhxgvER2oTAMkeo5B1BV_fcWWuJA@mail.gmail.com>

Hi,

I am using OpenBSC with nanoBTS 165CU and 165AU models. In normal location
update BTS sends CHAN ACT NACK several times for the same ts and ss. After
that it sends some failure messages and restart the trx. Here i copy the
related logs from openbsc console:

Thu Jan 19 15:44:03 2012 <0000> chan_alloc.c:421 (bts=0,trx=0,ts=6,ss=0)
starting release sequence
Thu Jan 19 15:44:03 2012 <0003> gsm_04_08_utils.c:231 Sending Channel
Release: Chan: Number: 0 Type: 2
Thu Jan 19 15:44:03 2012 <0004> abis_rsl.c:579 (bts=0,trx=0,ts=6,ss=0)
DEACTivate SACCH CMD
Thu Jan 19 15:44:03 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:04 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:05 2012 <0004> abis_rsl.c:891 (bts=0,trx=0,ts=6,ss=0)
CONNECTION FAIL: RELEASING CAUSE=0x01(Radio Link Failure)
Thu Jan 19 15:44:05 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF
Channel Release CMD due error 1
Thu Jan 19 15:44:05 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:594 (bts=0,trx=0,ts=6,ss=0) is
back in operation.
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0000> abis_rsl.c:1490 (bts=0,trx=0,ts=6,ss=0)
SAPI=0 Thu Jan 19 15:44:08 2012 <0000> abis_rsl.c:1436
(bts=0,trx=0,ts=6,ss=0) ERROR INDICATION cause=Timer T200 expired (N200+1)
times
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF
Channel Release CMD due error 1
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:658 (bts=0,trx=0,ts=6,ss=0) RF
CHANNEL RELEASE ACK
Thu Jan 19 15:44:08 2012 <0000> chan_alloc.c:303 Freeing lchan with state
RELEASE DUE ERROR - setting to NONE
Thu Jan 19 15:44:08 2012 <0000> abis_rsl.c:1490 (bts=0,trx=0,ts=6,ss=0)
SAPI=0 RELEASE INDICATION
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1322 (bts=0,trx=0,ts=6,ss=0)
Activating ARFCN(885) SS(0) lctype TCH/F r=LOCATION_UPDATE ra=0x0f
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:658 (bts=0,trx=0,ts=6,ss=0) RF
CHANNEL RELEASE ACK
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:665 (bts=0,trx=0,ts=6,ss=0) CHAN
REL ACK but state ACTIVATION REQUESTED
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1322 (bts=0,trx=0,ts=6,ss=0)
Activating ARFCN(523) SS(0) lctype TCH/F r=LOCATION_UPDATE ra=0x0a
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1060 (bts=0,trx=0,ts=6,ss=0)
CHANNEL ACTIVATE ACK
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:856 (bts=0,trx=0,ts=6,ss=0)
CHANNEL ACTIVATE NACK CAUSE=0x50(Radio channel already activated) Thu Jan
19 15:44:08 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF Channel
Release CMD due error 1
Thu Jan 19 15:44:08 2012 <0000> chan_alloc.c:303 Freeing lchan with state
RELEASE DUE ERROR - setting to NONE
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:856 (bts=0,trx=0,ts=6,ss=0)
CHANNEL ACTIVATE NACK CAUSE=0x50(Radio channel already activated) Thu Jan
19 15:44:08 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF Channel
Release CMD due error 1
Thu Jan 19 15:44:08 2012 <0000> chan_alloc.c:303 Freeing lchan with state
RELEASE DUE ERROR - setting to NONE
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1322 (bts=0,trx=0,ts=6,ss=0)
Activating ARFCN(523) SS(0) lctype TCH/F r=LOCATION_UPDATE ra=0x0f
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional
Text=l3_dcm.c:1190
****
** l3_dcm.c#1190:Cn0x0e: Aborting RF Chan Rel on second attempt
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L3" @ (37329).
****
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional Text=TRX
Proc:L3:l3_dcm.c#1190 (37329)
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=16395:WARN:OAM_RES:trx_fatal_error_log.c#260:Cn0x0e: Aborting RF Chan
Rel on second attempt
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional Text=
[000ad1e8] |000ad230|800d2fe7|800a4144|000ad250|
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional Text=
[000ad278] |00000000|000b91cc|000ad3c4|000ad3c4|
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=16396:WARN:OAM_RES:res_trx_status.c#231:TRX is not responding -
reinitialising the unit...


I could not realize the reason of the problem but i think there is
something wrong about the sequence of channel activation, release,  ack and
nack messages between openbsc and bts. Could somebody help about the
solution of this or at give some idea to realize the problem?

Thanks
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120120/522b3020/attachment.htm>

From jmercury616 at gmail.com  Fri Jan 20 12:05:48 2012
From: jmercury616 at gmail.com (Jason Mercury)
Date: Fri, 20 Jan 2012 14:05:48 +0200
Subject: nanoBTS failure
Message-ID: <CAECA2oJkaY=D3SUufp4n=sjci5PDBqv_xYYmeFjUV-pbXv2xYA@mail.gmail.com>

Hi,

I am using OpenBSC with nanoBTS 165CU and 165AU models. In normal location
update BTS sends CHAN ACT NACK several times for the same ts and ss. After
that it sends some failure messages and restart the trx. Here i copy the
related logs from openbsc console:

Thu Jan 19 15:44:03 2012 <0000> chan_alloc.c:421 (bts=0,trx=0,ts=6,ss=0)
starting release sequence
Thu Jan 19 15:44:03 2012 <0003> gsm_04_08_utils.c:231 Sending Channel
Release: Chan: Number: 0 Type: 2
Thu Jan 19 15:44:03 2012 <0004> abis_rsl.c:579 (bts=0,trx=0,ts=6,ss=0)
DEACTivate SACCH CMD
Thu Jan 19 15:44:03 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:04 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:05 2012 <0004> abis_rsl.c:891 (bts=0,trx=0,ts=6,ss=0)
CONNECTION FAIL: RELEASING CAUSE=0x01(Radio Link Failure)
Thu Jan 19 15:44:05 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF
Channel Release CMD due error 1
Thu Jan 19 15:44:05 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:594 (bts=0,trx=0,ts=6,ss=0) is
back in operation.
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0000> abis_rsl.c:1490 (bts=0,trx=0,ts=6,ss=0)
SAPI=0 Thu Jan 19 15:44:08 2012 <0000> abis_rsl.c:1436
(bts=0,trx=0,ts=6,ss=0) ERROR INDICATION cause=Timer T200 expired (N200+1)
times
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF
Channel Release CMD due error 1
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:968 (bts=0,trx=0,ts=6,ss=0):
MEAS RES for inactive channel
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:658 (bts=0,trx=0,ts=6,ss=0) RF
CHANNEL RELEASE ACK
Thu Jan 19 15:44:08 2012 <0000> chan_alloc.c:303 Freeing lchan with state
RELEASE DUE ERROR - setting to NONE
Thu Jan 19 15:44:08 2012 <0000> abis_rsl.c:1490 (bts=0,trx=0,ts=6,ss=0)
SAPI=0 RELEASE INDICATION
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1322 (bts=0,trx=0,ts=6,ss=0)
Activating ARFCN(885) SS(0) lctype TCH/F r=LOCATION_UPDATE ra=0x0f
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:658 (bts=0,trx=0,ts=6,ss=0) RF
CHANNEL RELEASE ACK
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:665 (bts=0,trx=0,ts=6,ss=0) CHAN
REL ACK but state ACTIVATION REQUESTED
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1322 (bts=0,trx=0,ts=6,ss=0)
Activating ARFCN(523) SS(0) lctype TCH/F r=LOCATION_UPDATE ra=0x0a
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1060 (bts=0,trx=0,ts=6,ss=0)
CHANNEL ACTIVATE ACK
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:856 (bts=0,trx=0,ts=6,ss=0)
CHANNEL ACTIVATE NACK CAUSE=0x50(Radio channel already activated) Thu Jan
19 15:44:08 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF Channel
Release CMD due error 1
Thu Jan 19 15:44:08 2012 <0000> chan_alloc.c:303 Freeing lchan with state
RELEASE DUE ERROR - setting to NONE
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:856 (bts=0,trx=0,ts=6,ss=0)
CHANNEL ACTIVATE NACK CAUSE=0x50(Radio channel already activated) Thu Jan
19 15:44:08 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=6,ss=0) RF Channel
Release CMD due error 1
Thu Jan 19 15:44:08 2012 <0000> chan_alloc.c:303 Freeing lchan with state
RELEASE DUE ERROR - setting to NONE
Thu Jan 19 15:44:08 2012 <0004> abis_rsl.c:1322 (bts=0,trx=0,ts=6,ss=0)
Activating ARFCN(523) SS(0) lctype TCH/F r=LOCATION_UPDATE ra=0x0f
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=l3_if_dl.c:276Unrecognised signal(1302)
Thu Jan 19 15:44:08 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional
Text=l3_dcm.c:1190
****
** l3_dcm.c#1190:Cn0x0e: Aborting RF Chan Rel on second attempt
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L3" @ (37329).
****
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional Text=TRX
Proc:L3:l3_dcm.c#1190 (37329)
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=16395:WARN:OAM_RES:trx_fatal_error_log.c#260:Cn0x0e: Aborting RF Chan
Rel on second attempt
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional Text=
[000ad1e8] |000ad230|800d2fe7|800a4144|000ad250|
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=critical failure Probable cause= 03 00 00 Additional Text=
[000ad278] |00000000|000b91cc|000ad3c4|000ad3c4|
Thu Jan 19 15:44:09 2012 <0005> abis_nm.c:419 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Failure Event Report Type=processing failure
Severity=warning level failure Probable cause= 03 00 01 Additional
Text=16396:WARN:OAM_RES:res_trx_status.c#231:TRX is not responding -
reinitialising the unit...


I could not realize the reason of the problem but i think there is
something wrong about the sequence of channel activation, release,  ack and
nack messages between openbsc and bts. Could somebody help about the
solution of this or at give some idea to realize the problem?

Thanks

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120120/bdd2d030/attachment.htm>

From openbsc at xs4all.nl  Fri Jan 20 12:24:47 2012
From: openbsc at xs4all.nl (Peter)
Date: Fri, 20 Jan 2012 13:24:47 +0100
Subject: Error building libosmo-abis, ortp missing]
Message-ID: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>

Hello,

I'm new around here and started from scratch with a new Ubuntu server. I
followed the openBSC build guide on the WIKI page
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC.
Building libosmocore went smoothly
Building libosmo-abis ended in an error:

=====
checking for ORTP... no
configure: error: Package requirements (ortp >= 0.13.1) were not met:

No package 'ortp' found
=====

Where can I find the ortp package?
And secondly, is this the right version? I saw version 0.15.0 mentioned in
the mail archives aready.

Thanks in advance,
Peter.






From krkos at phd.feec.vutbr.cz  Fri Jan 20 12:53:44 2012
From: krkos at phd.feec.vutbr.cz (=?iso-8859-2?Q?Radko_Krko=B9?=)
Date: Fri, 20 Jan 2012 13:53:44 +0100
Subject: Error building libosmo-abis, ortp missing]
In-Reply-To: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
References: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
Message-ID: <000801ccd772$8b90ada0$a2b208e0$@phd.feec.vutbr.cz>

Hello,

> Building libosmo-abis ended in an error:
> 
> =====
> checking for ORTP... no
> configure: error: Package requirements (ortp >= 0.13.1) were not met:
> 
> No package 'ortp' found
> =====
> 
> Where can I find the ortp package?
> And secondly, is this the right version? I saw version 0.15.0 mentioned in
the
> mail archives aready.

Google search for "ortp" shows this at the first place:
http://www.linphone.org/eng/documentation/dev/ortp.html

If you scroll down, you can see that you have two options - download one of
the releases, or access a git repository. Releases should be more stable so
one of those is probably a better choice. The last release is 0.18.0 (dated
2011-12-26), here is the download link:
http://download.savannah.gnu.org/releases/linphone/ortp/sources/ortp-0.18.0.
tar.gz

> 
> Thanks in advance,
> Peter.
> 
Regards,
Radko





From alexander.huemer at xx.vu  Fri Jan 20 13:13:24 2012
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Fri, 20 Jan 2012 14:13:24 +0100
Subject: Error building libosmo-abis, ortp missing]
In-Reply-To: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
References: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
Message-ID: <20120120131319.GA24128@de.xx.vu>

On Fri, Jan 20, 2012 at 01:24:47PM +0100, Peter wrote:
> Where can I find the ortp package?
There is actually libortp-dev mentioned in the OpenBSC build guide.
Maybe Ubuntu has only versioned packages.
Try the following:
$ aptitude search libortp
this should show libortp7-dev or libortp8-dev.
I am quite sure both versions work.

Kind regards,
-Alexander Huemer



From openbsc at xs4all.nl  Fri Jan 20 13:35:36 2012
From: openbsc at xs4all.nl (Peter)
Date: Fri, 20 Jan 2012 14:35:36 +0100
Subject: Error building libosmo-abis, ortp missing]
In-Reply-To: <20120120131319.GA24128@de.xx.vu>
References: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
	<20120120131319.GA24128@de.xx.vu>
Message-ID: <4c5d9297b62fc9962f4ca28a2a726502.squirrel@webmail.xs4all.nl>


Alexander Huemer wrote:
> There is actually libortp-dev mentioned in the OpenBSC build guide.

I searched for the text on that page and it is there indeed. Just below it
is an example of how to install it on Debian. I used this line to setup my
system.

> apt-get install libdbi0-dev libdbd-sqlite3 build-essential libtool
autoconf automake git-core pkg-config

In this line the package "libortp-dev" is missing, causing the failure
later on.

Thanks for clarifying to me.
Best regards,
Peter.






From admin at manateeshome.com  Fri Jan 20 13:14:04 2012
From: admin at manateeshome.com (Seungju Kim)
Date: Fri, 20 Jan 2012 22:14:04 +0900
Subject: Error building libosmo-abis, ortp missing]
In-Reply-To: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
References: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
Message-ID: <36E8DD1C-8EF3-471A-A344-47442F822567@manateeshome.com>

I am using Debian and I could use the libortp8 package from the default repository.
Doesn't the same package exist for ubuntu?

Envoy? de mon iPhone

Le Jan 20, 2012 ? 9:24 PM, "Peter" <openbsc at xs4all.nl> a ?crit :

> Hello,
> 
> I'm new around here and started from scratch with a new Ubuntu server. I
> followed the openBSC build guide on the WIKI page
> http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC.
> Building libosmocore went smoothly
> Building libosmo-abis ended in an error:
> 
> =====
> checking for ORTP... no
> configure: error: Package requirements (ortp >= 0.13.1) were not met:
> 
> No package 'ortp' found
> =====
> 
> Where can I find the ortp package?
> And secondly, is this the right version? I saw version 0.15.0 mentioned in
> the mail archives aready.
> 
> Thanks in advance,
> Peter.
> 
> 
> 
> 




From rogier at virtunix.nl  Fri Jan 20 13:37:29 2012
From: rogier at virtunix.nl (Rogier van Eeten)
Date: Fri, 20 Jan 2012 14:37:29 +0100
Subject: Error building libosmo-abis, ortp missing]
In-Reply-To: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
References: <a0980f4de1872b4d7c405717769eebbe.squirrel@webmail.xs4all.nl>
Message-ID: <4F196E19.3040002@virtunix.nl>

On 01/20/2012 01:24 PM, Peter wrote:
> Hello,
>
> I'm new around here and started from scratch with a new Ubuntu server. I
> followed the openBSC build guide on the WIKI page
> http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC.
> Building libosmocore went smoothly
> Building libosmo-abis ended in an error:
>
> =====
> checking for ORTP... no
> configure: error: Package requirements (ortp>= 0.13.1) were not met:
>
> No package 'ortp' found
> =====
>
> Where can I find the ortp package?

I tried in on a ubuntu workstation:

rogier at Draver:~$ apt-cache search ortp
apt-utils - APT utility programs
libortp-dev - Real-time Transport Protocol stack
libortp8 - Real-time Transport Protocol stack


I'd try libortp-dev :)

Grz,
-- 
Rogier van Eeten



From dburgess at jcis.net  Fri Jan 20 16:03:20 2012
From: dburgess at jcis.net (David A. Burgess)
Date: Fri, 20 Jan 2012 08:03:20 -0800
Subject: wireshark GSMTAP
Message-ID: <2CEA2C3F-F624-4D50-BB2C-9DE7299011FD@jcis.net>

Hello -

I have been using Wireshark 1.7 from wireshark.org for GSMTAP analysis.  I have seen some discrepancies that might be bugs.  So I have two questions.  First, is there a better-suited WS with more up-to-date GSMTAP support that I should be using (and hopefully pre-built for Mac OS X)?  Second, where should I report these suspected bugs?

-- David





From 246tnt at gmail.com  Fri Jan 20 16:13:08 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 20 Jan 2012 17:13:08 +0100
Subject: wireshark GSMTAP
In-Reply-To: <2CEA2C3F-F624-4D50-BB2C-9DE7299011FD@jcis.net>
References: <2CEA2C3F-F624-4D50-BB2C-9DE7299011FD@jcis.net>
Message-ID: <CAHL+j09TXNxTNvZhPK3tUH646sHx4qUnix93ti_XpqwJ2Ln=ww@mail.gmail.com>

Hi,

> I have been using Wireshark 1.7 from wireshark.org for GSMTAP analysis. ?I have seen some discrepancies that might be bugs. ?So I have two questions. ?First, is there a better-suited WS with more up-to-date GSMTAP support that I should be using (and hopefully pre-built for Mac OS X)?

The most up to date one wrt to GSM stuff is :
http://cgit.osmocom.org/cgit/wireshark/

No pre-build version for OSX tough (or any ...)

>?Second, where should I report these suspected bugs?

Mmm, I guess here ...
The wireshark bugtracker could be appropriate as well, but cc'ing this
ml is probably the best way to get it looked at.

Cheers,

    Sylvain



From admin at manateeshome.com  Mon Jan 23 19:33:36 2012
From: admin at manateeshome.com (admin at manateeshome.com)
Date: Mon, 23 Jan 2012 14:33:36 -0500
Subject: openbsc no sound
Message-ID: <2.8f886dee3f127451a328@WIN-AGR1FAS1S10>

hello,
I updated my openbsc to newest git version. and since then I do not get any sounds.
The setup was working just fine before. So I presume that the problem is within openbsc

<000b> osmo_msc.c:72 Assignment complete should not have been reached.
<000b> bsc_api.c:331 Sending ChanModify for speech 0 1
<000b> bsc_api.c:118 Using non speech mode: 0

I think this causes the problem. But I have not changed any configuration files or anything.
Can somebody tell me how to fix it?
I am using a 1900mhz edge nanobts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120123/3328a859/attachment.htm>

From peter at stuge.se  Mon Jan 23 19:00:33 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 23 Jan 2012 20:00:33 +0100
Subject: openbsc no sound
In-Reply-To: <2.8f886dee3f127451a328@WIN-AGR1FAS1S10>
References: <2.8f886dee3f127451a328@WIN-AGR1FAS1S10>
Message-ID: <20120123190033.1309.qmail@stuge.se>

admin at manateeshome.com wrote:
> I updated my openbsc to newest git version.
..
> I have not changed any configuration files

Maybe you need to? You could investigate differences between your old
version and current git.


//Peter



From admin at manateeshome.com  Tue Jan 24 01:59:32 2012
From: admin at manateeshome.com (Seungju Kim)
Date: Tue, 24 Jan 2012 10:59:32 +0900
Subject: openbsc no sound
In-Reply-To: <20120123190033.1309.qmail@stuge.se>
References: <2.8f886dee3f127451a328@WIN-AGR1FAS1S10>
	<20120123190033.1309.qmail@stuge.se>
Message-ID: <AE77D69B-3B28-4C44-BDAC-5E1F6B7A3B8A@manateeshome.com>

Well, I also tried using example configuration files from the git, but it did not help resolving this problem.

Envoy? de mon iPhone

Le Jan 24, 2012 ? 4:00 AM, Peter Stuge <peter at stuge.se> a ?crit :

> admin at manateeshome.com wrote:
>> I updated my openbsc to newest git version.
> ..
>> I have not changed any configuration files
> 
> Maybe you need to? You could investigate differences between your old
> version and current git.
> 
> 
> //Peter
> 




From cleb at defcon-3.net  Wed Jan 25 01:39:34 2012
From: cleb at defcon-3.net (Caleb Pal)
Date: Tue, 24 Jan 2012 19:39:34 -0600
Subject: Racal 6113 For Sale
Message-ID: <000901ccdb02$316b39b0$9441ad10$@net>

All,

 

I have a Racal/Aeroflex 6113 for sale. As most of you probably know, this is
a GSM test set capable of initializing and running certain BTS over an ABIS
link. It has a few handy features such as a power meter, etc. The unit is
out of cal. I have used it to run measurements on an Ericsson RBS 2401,
which is also available. Comes with power cord and a memory card for storing
test sequences and test results. The unit is well loaded with options, as
seen below. To my knowledge all functions of this unit work. Asking price is
$1500 USD + shipping. I am willing to ship overseas, BUT, it is the buyers
responsibility to complete all import/export paperwork needed. Be advised it
is a rather heavy unit, so shipping OCONUS will be more expensive. Any
questions please feel free to contact me off list at cleb at defcon-3.net.

 

Options: 

 

Software Options:

003         PCS1900

008         GSM850

220         Ericsson

235         Siemens

250         Nortel

270         Nokia

285         interWAVE

300         AIME

310         BOSS BTS Rx Measurements

315         AMR for AIME

316         AIME AMR DTX output

319         AMR AIME error forcing

 

Hardware Options:

04F         Frequency Standard

                A-bis Half Rate/32K Signalling

051         A-bis T1 Interface

054         BOSS RF Module

016         Extended BBP Board

008         GSM850/PCS1900 RXTX Module

010         Encryption A5/1, A5/2

 

 

Regards,

 

Caleb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120124/96981b34/attachment.htm>

From jolly at eversberg.eu  Mon Jan 16 08:29:28 2012
From: jolly at eversberg.eu (Andreas Eversberg)
Date: Mon, 16 Jan 2012 09:29:28 +0100
Subject: [PATCH 7/9] Adding traffic forwarding via RTP to remote application
Message-ID: <mailman.98.1641744188.42898.openbsc@lists.osmocom.org>

Instead of forwarding traffic through MNCC interface, traffic can
be forwarded to a given RTP peer directly. A special MNCC message
is used to control the peer's destination. The traffic can still be
forwarded through MNCC interface when this special MNCC message is
not used.

It also works with E1 based BTSs.

In conjunction with LCR's "rtp-bridge" feature, the RTP traffic
can be directly exchanged with a remote SIP endpoint, so that the
traffic is not forwarded by LCR itself. This way the performance
of handling traffic only depends on OpenBSC and the remote SIP
endpoint. Also the traffic is exchanged with the SIP endpoint
without transcoding, to have maximum performance.

Increment MNCC version to 4.
---
 openbsc/include/openbsc/gsm_04_08.h    |   3 +
 openbsc/include/openbsc/mncc.h         |  14 ++-
 openbsc/include/openbsc/rtp_proxy.h    |   7 +-
 openbsc/include/openbsc/transaction.h  |   2 +
 openbsc/src/ipaccess/ipaccess-config.c |   6 ++
 openbsc/src/libbsc/bsc_api.c           |   1 +
 openbsc/src/libbsc/handover_logic.c    |   1 +
 openbsc/src/libmsc/gsm_04_08.c         | 178 ++++++++++++++++++++++++++-------
 openbsc/src/libmsc/mncc_sock.c         |  18 ++++
 openbsc/src/libmsc/transaction.c       |   1 +
 openbsc/src/libtrau/rtp_proxy.c        |  75 ++++++++++----
 openbsc/src/libtrau/trau_mux.c         |  14 ++-
 openbsc/src/utils/bs11_config.c        |   6 ++
 openbsc/tests/abis/abis_test.c         |   6 ++
 openbsc/tests/gbproxy/gbproxy_test.c   |   6 ++
 15 files changed, 279 insertions(+), 59 deletions(-)

diff --git a/openbsc/include/openbsc/gsm_04_08.h b/openbsc/include/openbsc/gsm_04_08.h
index 8df7b73..93348d1 100644
--- a/openbsc/include/openbsc/gsm_04_08.h
+++ b/openbsc/include/openbsc/gsm_04_08.h
@@ -6,6 +6,7 @@
 #include <osmocom/gsm/protocol/gsm_04_08.h>
 
 #include <openbsc/meas_rep.h>
+#include <openbsc/mncc.h>
 
 struct msgb;
 struct gsm_bts;
@@ -75,4 +76,6 @@ void gsm48_lchan2chan_desc(struct gsm48_chan_desc *cd,
 void release_security_operation(struct gsm_subscriber_connection *conn);
 void allocate_security_operation(struct gsm_subscriber_connection *conn);
 
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data);
+
 #endif
diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h
index 48f4f7d..556fd88 100644
--- a/openbsc/include/openbsc/mncc.h
+++ b/openbsc/include/openbsc/mncc.h
@@ -92,6 +92,9 @@ struct gsm_call {
 #define MNCC_FRAME_RECV		0x0201
 #define MNCC_FRAME_DROP		0x0202
 #define MNCC_LCHAN_MODIFY	0x0203
+#define MNCC_RTP_CREATE		0x0204
+#define MNCC_RTP_CONNECT	0x0205
+#define MNCC_RTP_FREE		0x0206
 
 #define GSM_TCHF_FRAME		0x0300
 #define GSM_TCHF_FRAME_EFR	0x0301
@@ -163,7 +166,7 @@ struct gsm_data_frame {
 	unsigned char	data[0];
 };
 
-#define MNCC_SOCK_VERSION	2
+#define MNCC_SOCK_VERSION	4
 struct gsm_mncc_hello {
 	uint32_t	msg_type;
 	uint32_t	version;
@@ -179,6 +182,15 @@ struct gsm_mncc_hello {
 	uint32_t	lchan_type_offset;
 };
 
+struct gsm_mncc_rtp {
+	uint32_t	msg_type;
+	uint32_t	callref;
+	uint32_t	ip;
+	uint16_t	port;
+	uint32_t	payload_type;
+	uint32_t	payload_msg_type;
+};
+
 char *get_mncc_name(int value);
 void mncc_set_cause(struct gsm_mncc *data, int loc, int val);
 void cc_tx_to_mncc(struct gsm_network *net, struct msgb *msg);
diff --git a/openbsc/include/openbsc/rtp_proxy.h b/openbsc/include/openbsc/rtp_proxy.h
index 52ffefd..ae49ca5 100644
--- a/openbsc/include/openbsc/rtp_proxy.h
+++ b/openbsc/include/openbsc/rtp_proxy.h
@@ -40,8 +40,9 @@
 
 enum rtp_rx_action {
 	RTP_NONE,
-	RTP_PROXY,
-	RTP_RECV_UPSTREAM,
+	RTP_PROXY, /* forward from BTS to BTS */
+	RTP_RECV_UPSTREAM, /* forward to L4 application */
+	RTP_RECV_L4, /* receive RTP frames from L4 application */
 };
 
 enum rtp_tx_action {
@@ -73,6 +74,8 @@ struct rtp_socket {
 		struct {
 			struct gsm_network *net;
 			uint32_t callref;
+			uint8_t payload_type; /* dynamic PT */
+			int msg_type; /* message type for dynamic PT */
 		} receive;
 	};
 	enum rtp_tx_action tx_action;
diff --git a/openbsc/include/openbsc/transaction.h b/openbsc/include/openbsc/transaction.h
index b6c859c..6f4258d 100644
--- a/openbsc/include/openbsc/transaction.h
+++ b/openbsc/include/openbsc/transaction.h
@@ -28,6 +28,7 @@ struct gsm_trans {
 
 	/* reference from MNCC or other application */
 	uint32_t callref;
+	uint32_t callref_keep; /* to remember callref, even if it is removed */
 
 	/* if traffic channel receive was requested */
 	int tch_recv;
@@ -46,6 +47,7 @@ struct gsm_trans {
 			int T308_second;	/* used to send release again */
 			struct osmo_timer_list timer;
 			struct gsm_mncc msg;	/* stores setup/disconnect/release message */
+			struct rtp_socket *rs;	/* L4 traffic via RTP */
 		} cc;
 		struct {
 			struct gsm411_smc_inst smc_inst;
diff --git a/openbsc/src/ipaccess/ipaccess-config.c b/openbsc/src/ipaccess/ipaccess-config.c
index c42c7bb..68b9131 100644
--- a/openbsc/src/ipaccess/ipaccess-config.c
+++ b/openbsc/src/ipaccess/ipaccess-config.c
@@ -87,6 +87,12 @@ static uint8_t prim_oml_attr[] = { 0x95, 0x00, 7, 0x88, 192, 168, 100, 11, 0x00,
 static uint8_t unit_id_attr[] = { 0x91, 0x00, 9, '2', '3', '4', '2', '/' , '0', '/', '0', 0x00 };
 */
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	return 0;
+}
+
 extern int ipaccess_fd_cb(struct osmo_fd *bfd, unsigned int what);
 extern struct e1inp_line_ops ipaccess_e1inp_line_ops;
 
diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
index e567038..e6629ff 100644
--- a/openbsc/src/libbsc/bsc_api.c
+++ b/openbsc/src/libbsc/bsc_api.c
@@ -31,6 +31,7 @@
 #include <openbsc/handover.h>
 #include <openbsc/debug.h>
 #include <openbsc/gsm_04_08.h>
+#include <osmocom/abis/trau_frame.h>
 #include <openbsc/trau_mux.h>
 
 #include <osmocom/gsm/protocol/gsm_08_08.h>
diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c
index 36a758b..e20d8f7 100644
--- a/openbsc/src/libbsc/handover_logic.c
+++ b/openbsc/src/libbsc/handover_logic.c
@@ -39,6 +39,7 @@
 #include <openbsc/signal.h>
 #include <osmocom/core/talloc.h>
 #include <openbsc/transaction.h>
+#include <osmocom/abis/trau_frame.h>
 #include <openbsc/trau_mux.h>
 
 struct bsc_handover {
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index e36a142..79300d1 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -1359,8 +1359,15 @@ void _gsm48_cc_trans_free(struct gsm_trans *trans)
 	}
 	if (trans->cc.state != GSM_CSTATE_NULL)
 		new_cc_state(trans, GSM_CSTATE_NULL);
+	/* Be sure to unmap upstream traffic for our callref only. */
 	if (trans->conn)
-		trau_mux_unmap(&trans->conn->lchan->ts->e1_link, trans->callref);
+		trau_mux_unmap(&trans->conn->lchan->ts->e1_link, trans->callref_keep);
+
+	/* free L4 RTP socket */
+	if (trans->cc.rs) {
+		rtp_socket_free(trans->cc.rs);
+		trans->cc.rs = NULL;
+	}
 }
 
 static int gsm48_cc_tx_setup(struct gsm_trans *trans, void *arg);
@@ -1478,6 +1485,7 @@ static int switch_for_handover(struct gsm_lchan *old_lchan,
 		new_rs->receive = old_rs->receive;
 		break;
 	case RTP_NONE:
+	case RTP_RECV_L4:
 		break;
 	}
 
@@ -1695,6 +1703,132 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
 	return 0;
 }
 
+/* handle RTP requests of L4 */
+static int mncc_rtp(struct gsm_network *net, uint32_t callref, struct gsm_mncc_rtp *mncc)
+{
+	struct rtp_socket *rs;
+	struct gsm_trans *trans;
+	int rc;
+
+	/* Find callref */
+	trans = trans_find_by_callref(net, callref);
+	if (!trans) {
+		LOGP(DCC, LOGL_ERROR, "Unknown transaction for callref=%d\n", callref);
+		return -EINVAL;
+	}
+
+	rs = trans->cc.rs;
+
+	switch (mncc->msg_type) {
+	case MNCC_RTP_CREATE:
+		/* use RTP instead of MNCC socket, for traffic
+		 * open L4 RTP socket */
+		if (rs) {
+			LOGP(DCC, LOGL_ERROR, "RTP already created.\n");
+			return -EIO;
+		}
+		rs = trans->cc.rs = rtp_socket_create();
+		if (!rs) {
+			LOGP(DCC, LOGL_ERROR, "RTP socket creation failed.\n");
+			/* reply with IP/port = 0 */
+			mncc->ip = 0;
+			mncc->port = 0;
+			mncc_recvmsg(net, trans, MNCC_RTP_CREATE, (struct gsm_mncc *)mncc);
+			return -EIO;
+		}
+		rs->rx_action = RTP_RECV_L4;
+		rs->receive.net = net;
+		rs->receive.callref = callref;
+		/* reply with bound IP/port */
+		mncc->ip = ntohl(rs->rtp.sin_local.sin_addr.s_addr);
+		mncc->port = ntohs(rs->rtp.sin_local.sin_port);
+		mncc_recvmsg(net, trans, MNCC_RTP_CREATE, (struct gsm_mncc *)mncc);
+		break;
+	case MNCC_RTP_CONNECT:
+		if (!rs) {
+			LOGP(DCC, LOGL_ERROR, "RTP not created.\n");
+			return -EIO;
+		}
+		rc = rtp_socket_connect(trans->cc.rs, mncc->ip, mncc->port);
+		if (rc < 0) {
+			LOGP(DCC, LOGL_ERROR, "RTP socket connect failed.\n");
+			/* reply with IP/port = 0 */
+			mncc->ip = 0;
+			mncc->port = 0;
+			mncc_recvmsg(net, trans, MNCC_RTP_CONNECT, (struct gsm_mncc *)mncc);
+			return -EIO;
+		}
+		rs->receive.msg_type = mncc->payload_msg_type;
+		rs->receive.payload_type = mncc->payload_type;
+		/* reply with local IP/port */
+		mncc->ip = ntohl(rs->rtp.sin_local.sin_addr.s_addr);
+		mncc->port = ntohs(rs->rtp.sin_local.sin_port);
+		mncc_recvmsg(net, trans, MNCC_RTP_CONNECT, (struct gsm_mncc *)mncc);
+		break;
+	case MNCC_RTP_FREE:
+		if (!rs) {
+			LOGP(DCC, LOGL_ERROR, "RTP not created.\n");
+			return -EIO;
+		}
+		rtp_socket_free(trans->cc.rs);
+		trans->cc.rs = NULL;
+		/* reply */
+		mncc_recvmsg(net, trans, MNCC_RTP_FREE, (struct gsm_mncc *)mncc);
+		break;
+	}
+
+	return 0;
+}
+
+/* handle tch frame from L4  */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	struct gsm_trans *trans;
+	struct gsm_bts *bts;
+
+	/* Find callref */
+	trans = trans_find_by_callref(net, data->callref);
+	if (!trans) {
+		LOGP(DMNCC, LOGL_ERROR, "TCH frame for non-existing trans\n");
+		return -EIO;
+	}
+	if (!trans->conn) {
+		LOGP(DMNCC, LOGL_NOTICE, "TCH frame for trans without conn\n");
+		return 0;
+	}
+	if (trans->conn->lchan->type != GSM_LCHAN_TCH_F
+	 && trans->conn->lchan->type != GSM_LCHAN_TCH_H) {
+		/* This should be LOGL_ERROR or NOTICE, but
+		 * unfortuantely it happens for a couple of frames at
+		 * the beginning of every RTP connection */
+		LOGP(DMNCC, LOGL_DEBUG, "TCH frame for lchan != TCH_F/TCH_H\n");
+		return 0;
+	}
+	bts = trans->conn->lchan->ts->trx->bts;
+	switch (bts->type) {
+	case GSM_BTS_TYPE_NANOBTS:
+	case GSM_BTS_TYPE_OSMO_SYSMO:
+		if (!trans->conn->lchan->abis_ip.rtp_socket) {
+			DEBUGP(DMNCC, "TCH frame to lchan without RTP connection\n");
+			return 0;
+		}
+		if (trans->conn->lchan->abis_ip.rtp_socket->receive.callref != callref) {
+			/* Drop frame, if not our callref. This happens, if
+			 * the call is on hold or retrieved by another
+			 * transaction. */
+			return 0;
+		}
+		return rtp_send_frame(trans->conn->lchan->abis_ip.rtp_socket, data);
+	case GSM_BTS_TYPE_BS11:
+	case GSM_BTS_TYPE_RBS2000:
+	case GSM_BTS_TYPE_NOKIA_SITE:
+		return trau_send_frame(trans->conn->lchan, data);
+	default:
+		LOGP(DCC, LOGL_ERROR, "Unknown BTS type %u\n", bts->type);
+	}
+	return -EINVAL;
+}
+
 static int gsm48_cc_rx_status_enq(struct gsm_trans *trans, struct msgb *msg)
 {
 	DEBUGP(DCC, "-> STATUS ENQ\n");
@@ -2930,7 +3064,6 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg)
 	int i, rc = 0;
 	struct gsm_trans *trans = NULL, *transt;
 	struct gsm_subscriber_connection *conn = NULL;
-	struct gsm_bts *bts = NULL;
 	struct gsm_mncc *data = arg, rel;
 
 	DEBUGP(DMNCC, "receive message %s\n", get_mncc_name(msg_type));
@@ -2943,46 +3076,15 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg)
 		return tch_recv_mncc(net, data->callref, 0);
 	case MNCC_FRAME_RECV:
 		return tch_recv_mncc(net, data->callref, 1);
+	case MNCC_RTP_CREATE:
+	case MNCC_RTP_CONNECT:
+	case MNCC_RTP_FREE:
+		return mncc_rtp(net, data->callref, (struct gsm_mncc_rtp *) 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) {
-			LOGP(DMNCC, LOGL_ERROR, "TCH frame for non-existing trans\n");
-			return -EIO;
-		}
-		log_set_context(BSC_CTX_SUBSCR, trans->subscr);
-		if (!trans->conn) {
-			LOGP(DMNCC, LOGL_NOTICE, "TCH frame for trans without conn\n");
-			return 0;
-		}
-		if (trans->conn->lchan->type != GSM_LCHAN_TCH_F
-		 && trans->conn->lchan->type != GSM_LCHAN_TCH_H) {
-			/* This should be LOGL_ERROR or NOTICE, but
-			 * unfortuantely it happens for a couple of frames at
-			 * the beginning of every RTP connection */
-			LOGP(DMNCC, LOGL_DEBUG, "TCH frame for lchan != TCH_F/TCH_H\n");
-			return 0;
-		}
-		bts = trans->conn->lchan->ts->trx->bts;
-		switch (bts->type) {
-		case GSM_BTS_TYPE_NANOBTS:
-		case GSM_BTS_TYPE_OSMO_SYSMO:
-			if (!trans->conn->lchan->abis_ip.rtp_socket) {
-				DEBUGP(DMNCC, "TCH frame to lchan without RTP connection\n");
-				return 0;
-			}
-			return rtp_send_frame(trans->conn->lchan->abis_ip.rtp_socket, arg);
-		case GSM_BTS_TYPE_BS11:
-		case GSM_BTS_TYPE_RBS2000:
-		case GSM_BTS_TYPE_NOKIA_SITE:
-			return trau_send_frame(trans->conn->lchan, arg);
-		default:
-			LOGP(DCC, LOGL_ERROR, "Unknown BTS type %u\n", bts->type);
-		}
-		return -EINVAL;
+		return tch_frame_down(net, data->callref, (struct gsm_data_frame *) arg);
 	}
 
 	memset(&rel, 0, sizeof(struct gsm_mncc));
diff --git a/openbsc/src/libmsc/mncc_sock.c b/openbsc/src/libmsc/mncc_sock.c
index c8cfa6a..5ae9cc4 100644
--- a/openbsc/src/libmsc/mncc_sock.c
+++ b/openbsc/src/libmsc/mncc_sock.c
@@ -37,6 +37,8 @@
 #include <openbsc/debug.h>
 #include <openbsc/mncc.h>
 #include <openbsc/gsm_data.h>
+#include <openbsc/transaction.h>
+#include <openbsc/rtp_proxy.h>
 
 struct mncc_sock_state {
 	struct gsm_network *net;
@@ -50,6 +52,22 @@ int mncc_sock_from_cc(struct gsm_network *net, struct msgb *msg)
 	struct gsm_mncc *mncc_in = (struct gsm_mncc *) msgb_data(msg);
 	int msg_type = mncc_in->msg_type;
 
+	/* L4 uses RTP for this transaction, we send our data via RTP,
+	 * otherwise we send it through MNCC interface */
+	if (msg_type == GSM_TCHF_FRAME
+	 || msg_type == GSM_TCHF_FRAME_EFR
+	 || msg_type == GSM_TCHH_FRAME
+	 || msg_type == GSM_TCH_FRAME_AMR
+	 || msg_type == GSM_BAD_FRAME) {
+		struct gsm_trans *trans = trans_find_by_callref(net, mncc_in->callref);
+
+		if (trans && trans->cc.rs) {
+			rtp_send_frame(trans->cc.rs, (struct gsm_data_frame *) mncc_in);
+			msgb_free(msg);
+			return 0;
+		}
+	}
+
 	/* Check if we currently have a MNCC handler connected */
 	if (net->mncc_state->conn_bfd.fd < 0) {
 		LOGP(DMNCC, LOGL_ERROR, "mncc_sock receives %s for external CC app "
diff --git a/openbsc/src/libmsc/transaction.c b/openbsc/src/libmsc/transaction.c
index e425e67..bdd3d8e 100644
--- a/openbsc/src/libmsc/transaction.c
+++ b/openbsc/src/libmsc/transaction.c
@@ -78,6 +78,7 @@ struct gsm_trans *trans_alloc(struct gsm_subscriber *subscr,
 	trans->protocol = protocol;
 	trans->transaction_id = trans_id;
 	trans->callref = callref;
+	trans->callref_keep = callref;
 
 	llist_add_tail(&trans->entry, &subscr->net->trans_list);
 
diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c
index 86e54e1..2284798 100644
--- a/openbsc/src/libtrau/rtp_proxy.c
+++ b/openbsc/src/libtrau/rtp_proxy.c
@@ -106,7 +106,7 @@ struct rtp_x_hdr {
 #define RTP_VERSION	2
 
 /* decode an rtp frame and create a new buffer with payload */
-static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data)
+static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data, int msg_type)
 {
 	struct msgb *new_msg;
 	struct gsm_data_frame *frame;
@@ -114,7 +114,6 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data)
 	struct rtp_x_hdr *rtpxh;
 	uint8_t *payload;
 	int payload_len;
-	int msg_type;
 	int x_len;
 	int amr = 0;
 
@@ -165,9 +164,31 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data)
 		}
 	}
 
-	switch (rtph->payload_type) {
-	case RTP_PT_GSM_FULL:
-		msg_type = GSM_TCHF_FRAME;
+	/* If no explicit frame type is given, select frame type from
+	 * payload type. */
+	if (!msg_type) {
+		switch (rtph->payload_type) {
+		case RTP_PT_GSM_FULL:
+			msg_type = GSM_TCHF_FRAME;
+			break;
+		case RTP_PT_GSM_EFR:
+			msg_type = GSM_TCHF_FRAME_EFR;
+			break;
+		case RTP_PT_GSM_HALF:
+			msg_type = GSM_TCHH_FRAME;
+			break;
+		case RTP_PT_AMR:
+			msg_type = GSM_TCH_FRAME_AMR;
+			break;
+		default:
+			DEBUGPC(DLMUX, "received RTP frame with unknown "
+				"payload type %d\n", rtph->payload_type);
+			return -EINVAL;
+		}
+	}
+
+	switch (msg_type) {
+	case GSM_TCHF_FRAME:
 		if (payload_len != RTP_LEN_GSM_FULL) {
 			DEBUGPC(DLMUX, "received RTP full rate frame with "
 				"payload length != %d (len = %d)\n",
@@ -175,8 +196,7 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data)
 			return -EINVAL;
 		}
 		break;
-	case RTP_PT_GSM_EFR:
-		msg_type = GSM_TCHF_FRAME_EFR;
+	case GSM_TCHF_FRAME_EFR:
 		if (payload_len != RTP_LEN_GSM_EFR) {
 			DEBUGPC(DLMUX, "received RTP extended full rate frame "
 				"with payload length != %d (len = %d)\n",
@@ -184,8 +204,7 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data)
 			return -EINVAL;
 		}
 		break;
-	case RTP_PT_GSM_HALF:
-		msg_type = GSM_TCHH_FRAME;
+	case GSM_TCHH_FRAME:
 		if (payload_len != RTP_LEN_GSM_HALF) {
 			DEBUGPC(DLMUX, "received RTP half rate frame with "
 				"payload length != %d (len = %d)\n",
@@ -193,12 +212,11 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data)
 			return -EINVAL;
 		}
 		break;
-	case RTP_PT_AMR:
+	case GSM_TCH_FRAME_AMR:
 		amr = 1;
 		break;
 	default:
-		DEBUGPC(DLMUX, "received RTP frame with unknown payload "
-			"type %d\n", rtph->payload_type);
+		DEBUGPC(DLMUX, "Forced message type %x unknown\n", msg_type);
 		return -EINVAL;
 	}
 
@@ -246,6 +264,10 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame)
 	int payload_len;
 	int duration; /* in samples */
 	int amr = 0;
+	uint8_t dynamic_pt = 0;
+
+	if (rs->rx_action == RTP_RECV_L4)
+		dynamic_pt = rs->receive.payload_type;
 
 	if (rs->tx_action != RTP_SEND_DOWNSTREAM) {
 		/* initialize sequences */
@@ -262,17 +284,17 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame)
 		duration = RTP_GSM_DURATION;
 		break;
 	case GSM_TCHF_FRAME_EFR:
-		payload_type = RTP_PT_GSM_EFR;
+		payload_type = (dynamic_pt) ? : RTP_PT_GSM_EFR;
 		payload_len = RTP_LEN_GSM_EFR;
 		duration = RTP_GSM_DURATION;
 		break;
 	case GSM_TCHH_FRAME:
-		payload_type = RTP_PT_GSM_HALF;
+		payload_type = (dynamic_pt) ? : RTP_PT_GSM_HALF;
 		payload_len = RTP_LEN_GSM_HALF;
 		duration = RTP_GSM_DURATION;
 		break;
 	case GSM_TCH_FRAME_AMR:
-		payload_type = RTP_PT_AMR;
+		payload_type = (dynamic_pt) ? : RTP_PT_AMR;
 		payload_len = frame->data[0];
 		duration = RTP_GSM_DURATION;
 		amr = 1;
@@ -470,7 +492,7 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss)
 		other_rss->bfd.when |= BSC_FD_WRITE;
 		break;
 
-	case RTP_RECV_UPSTREAM:
+	case RTP_RECV_UPSTREAM: /* from BTS to application */
 		if (!rs->receive.callref || !rs->receive.net) {
 			rc = -EIO;
 			goto out_free;
@@ -492,13 +514,32 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss)
 			rc = -EINVAL;
 			goto out_free;
 		}
-		rc = rtp_decode(msg, rs->receive.callref, &new_msg);
+		rc = rtp_decode(msg, rs->receive.callref, &new_msg, 0);
 		if (rc < 0)
 			goto out_free;
 		msgb_free(msg);
 		trau_tx_to_mncc(rs->receive.net, new_msg);
 		break;
 
+	case RTP_RECV_L4: /* from L4 */
+		if (!rs->receive.callref || !rs->receive.net) {
+			rc = -EIO;
+			goto out_free;
+		}
+		if (rss->bfd.priv_nr != RTP_PRIV_RTP) {
+			rc = ENOTSUP;
+			goto out_free;
+		}
+		rc = rtp_decode(msg, rs->receive.callref, &new_msg,
+			rs->receive.msg_type);
+		if (rc < 0)
+			goto out_free;
+		msgb_free(msg);
+		tch_frame_down(rs->receive.net, rs->receive.callref,
+			(struct gsm_data_frame *) new_msg->data);
+		msgb_free(new_msg);
+		break;
+
 	case RTP_NONE: /* if socket exists, but disabled by app */
 		msgb_free(msg);
 		break;
diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c
index bb513cc..15a84b0 100644
--- a/openbsc/src/libtrau/trau_mux.c
+++ b/openbsc/src/libtrau/trau_mux.c
@@ -171,7 +171,9 @@ int trau_mux_unmap(const struct gsm_e1_subslot *ss, uint32_t callref)
 			llist_del(&ue->list);
 			return 0;
 		}
-		if (ss && !memcmp(&ue->src, ss, sizeof(*ss))) {
+		/* Only release, if no callref is given. We must ensure that
+		 * only the transaction's upstream is removed, if exists. */
+		if (ss && !callref && !memcmp(&ue->src, ss, sizeof(*ss))) {
 			llist_del(&ue->list);
 			return 0;
 		}
@@ -497,11 +499,21 @@ int trau_send_frame(struct gsm_lchan *lchan, struct gsm_data_frame *frame)
 	uint8_t trau_bits_out[TRAU_FRAME_BITS];
 	struct gsm_e1_subslot *dst_e1_ss = &lchan->ts->e1_link;
 	struct subch_mux *mx;
+	struct upqueue_entry *ue;
 	struct decoded_trau_frame tf;
 
 	mx = e1inp_get_mux(dst_e1_ss->e1_nr, dst_e1_ss->e1_ts);
 	if (!mx)
 		return -EINVAL;
+	if (!(ue = lookup_trau_upqueue(dst_e1_ss))) {
+		/* Call might be on hold, so we drop frames. */
+		return 0;
+	}
+	if (ue->callref != frame->callref) {
+		/* Slot has different transaction, due to
+		 * another call. (Ours is on hold.) */
+		return 0;
+	}
 
 	switch (frame->msg_type) {
 	case GSM_TCHF_FRAME:
diff --git a/openbsc/src/utils/bs11_config.c b/openbsc/src/utils/bs11_config.c
index e8acb46..f459744 100644
--- a/openbsc/src/utils/bs11_config.c
+++ b/openbsc/src/utils/bs11_config.c
@@ -83,6 +83,12 @@ struct osmo_counter *osmo_counter_alloc(const char *name)
 	return NULL;
 }
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	return 0;
+}
+
 int handle_serial_msg(struct msgb *rx_msg);
 
 /* create all objects for an initial configuration */
diff --git a/openbsc/tests/abis/abis_test.c b/openbsc/tests/abis/abis_test.c
index e7e78d2..6bb84cc 100644
--- a/openbsc/tests/abis/abis_test.c
+++ b/openbsc/tests/abis/abis_test.c
@@ -27,6 +27,12 @@
 #include <openbsc/abis_nm.h>
 #include <openbsc/debug.h>
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	return 0;
+}
+
 static const uint8_t simple_config[] = {
 	/*0, 13, */
 	66, 18, 0, 3, 1, 2, 3, 19, 0, 3, 3, 4, 5,
diff --git a/openbsc/tests/gbproxy/gbproxy_test.c b/openbsc/tests/gbproxy/gbproxy_test.c
index d32ac83..69ce58a 100644
--- a/openbsc/tests/gbproxy/gbproxy_test.c
+++ b/openbsc/tests/gbproxy/gbproxy_test.c
@@ -34,6 +34,12 @@
 
 #define SGSN_NSEI 0x0100
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down()
+{
+	return 0;
+}
+
 struct gbproxy_config gbcfg;
 
 static int gprs_process_message(struct gprs_ns_inst *nsi, const char *text,
-- 
1.8.1.5


--------------050908080107090307030308--



From jolly at eversberg.eu  Mon Jan 16 08:29:28 2012
From: jolly at eversberg.eu (Andreas Eversberg)
Date: Mon, 16 Jan 2012 09:29:28 +0100
Subject: [PATCH 6/9] Adding traffic forwarding via RTP to remote application
Message-ID: <mailman.101.1641744188.42898.openbsc@lists.osmocom.org>

Instead of forwarding traffic through MNCC interface, traffic can
be forwarded to a given RTP peer directly. A special MNCC message
is used to control the peer's destination. The traffic can still be
forwarded through MNCC interface when this special MNCC message is
not used.

It also works with E1 based BTSs.

In conjunction with LCR's "rtp-bridge" feature, the RTP traffic
can be directly exchanged with a remote SIP endpoint, so that the
traffic is not forwarded by LCR itself. This way the performance
of handling traffic only depends on OpenBSC and the remote SIP
endpoint. Also the traffic is exchanged with the SIP endpoint
without transcoding, to have maximum performance.

Increment MNCC version to 5.
---
 openbsc/include/openbsc/gsm_04_08.h    |   3 +
 openbsc/include/openbsc/mncc.h         |  12 +-
 openbsc/include/openbsc/rtp_proxy.h    |   5 +-
 openbsc/include/openbsc/transaction.h  |   2 +
 openbsc/src/ipaccess/ipaccess-config.c |   6 +
 openbsc/src/libbsc/bsc_api.c           |   1 +
 openbsc/src/libbsc/handover_logic.c    |   1 +
 openbsc/src/libmsc/gsm_04_08.c         | 199 ++++++++++++++++++++++++++-------
 openbsc/src/libmsc/mncc_sock.c         |  14 +++
 openbsc/src/libmsc/transaction.c       |   1 +
 openbsc/src/libtrau/rtp_proxy.c        |  20 +++-
 openbsc/src/libtrau/trau_mux.c         |  14 ++-
 openbsc/src/utils/bs11_config.c        |   6 +
 openbsc/tests/abis/abis_test.c         |   6 +
 openbsc/tests/gbproxy/gbproxy_test.c   |   6 +
 15 files changed, 253 insertions(+), 43 deletions(-)

diff --git a/openbsc/include/openbsc/gsm_04_08.h b/openbsc/include/openbsc/gsm_04_08.h
index 8df7b73..93348d1 100644
--- a/openbsc/include/openbsc/gsm_04_08.h
+++ b/openbsc/include/openbsc/gsm_04_08.h
@@ -6,6 +6,7 @@
 #include <osmocom/gsm/protocol/gsm_04_08.h>
 
 #include <openbsc/meas_rep.h>
+#include <openbsc/mncc.h>
 
 struct msgb;
 struct gsm_bts;
@@ -75,4 +76,6 @@ void gsm48_lchan2chan_desc(struct gsm48_chan_desc *cd,
 void release_security_operation(struct gsm_subscriber_connection *conn);
 void allocate_security_operation(struct gsm_subscriber_connection *conn);
 
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data);
+
 #endif
diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h
index ffac7fd..32a60e9 100644
--- a/openbsc/include/openbsc/mncc.h
+++ b/openbsc/include/openbsc/mncc.h
@@ -92,6 +92,9 @@ struct gsm_call {
 #define MNCC_FRAME_RECV		0x0201
 #define MNCC_FRAME_DROP		0x0202
 #define MNCC_LCHAN_MODIFY	0x0203
+#define MNCC_RTP_CREATE		0x0204
+#define MNCC_RTP_CONNECT	0x0205
+#define MNCC_RTP_FREE		0x0206
 
 #define GSM_TCHF_FRAME		0x0300
 #define GSM_TCHF_FRAME_EFR	0x0301
@@ -163,7 +166,7 @@ struct gsm_data_frame {
 	unsigned char	data[0];
 };
 
-#define MNCC_SOCK_VERSION	4
+#define MNCC_SOCK_VERSION	5
 struct gsm_mncc_hello {
 	uint32_t	msg_type;
 	uint32_t	version;
@@ -179,6 +182,13 @@ struct gsm_mncc_hello {
 	uint32_t	lchan_type_offset;
 };
 
+struct gsm_mncc_rtp {
+	uint32_t	msg_type;
+	uint32_t	callref;
+	uint32_t	ip;
+	uint16_t	port;
+};
+
 char *get_mncc_name(int value);
 void mncc_set_cause(struct gsm_mncc *data, int loc, int val);
 void cc_tx_to_mncc(struct gsm_network *net, struct msgb *msg);
diff --git a/openbsc/include/openbsc/rtp_proxy.h b/openbsc/include/openbsc/rtp_proxy.h
index 52ffefd..a5f6a2b 100644
--- a/openbsc/include/openbsc/rtp_proxy.h
+++ b/openbsc/include/openbsc/rtp_proxy.h
@@ -40,8 +40,9 @@
 
 enum rtp_rx_action {
 	RTP_NONE,
-	RTP_PROXY,
-	RTP_RECV_UPSTREAM,
+	RTP_PROXY, /* forward from BTS to BTS */
+	RTP_RECV_UPSTREAM, /* forward to application */
+	RTP_RECV_APP, /* receive RTP frames from application */
 };
 
 enum rtp_tx_action {
diff --git a/openbsc/include/openbsc/transaction.h b/openbsc/include/openbsc/transaction.h
index b6c859c..db3a5cf 100644
--- a/openbsc/include/openbsc/transaction.h
+++ b/openbsc/include/openbsc/transaction.h
@@ -28,6 +28,7 @@ struct gsm_trans {
 
 	/* reference from MNCC or other application */
 	uint32_t callref;
+	uint32_t callref_keep; /* to remember callref, even if it is removed */
 
 	/* if traffic channel receive was requested */
 	int tch_recv;
@@ -46,6 +47,7 @@ struct gsm_trans {
 			int T308_second;	/* used to send release again */
 			struct osmo_timer_list timer;
 			struct gsm_mncc msg;	/* stores setup/disconnect/release message */
+			struct rtp_socket *rs;	/* application traffic via RTP */
 		} cc;
 		struct {
 			struct gsm411_smc_inst smc_inst;
diff --git a/openbsc/src/ipaccess/ipaccess-config.c b/openbsc/src/ipaccess/ipaccess-config.c
index c42c7bb..68b9131 100644
--- a/openbsc/src/ipaccess/ipaccess-config.c
+++ b/openbsc/src/ipaccess/ipaccess-config.c
@@ -87,6 +87,12 @@ static uint8_t prim_oml_attr[] = { 0x95, 0x00, 7, 0x88, 192, 168, 100, 11, 0x00,
 static uint8_t unit_id_attr[] = { 0x91, 0x00, 9, '2', '3', '4', '2', '/' , '0', '/', '0', 0x00 };
 */
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	return 0;
+}
+
 extern int ipaccess_fd_cb(struct osmo_fd *bfd, unsigned int what);
 extern struct e1inp_line_ops ipaccess_e1inp_line_ops;
 
diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
index e567038..e6629ff 100644
--- a/openbsc/src/libbsc/bsc_api.c
+++ b/openbsc/src/libbsc/bsc_api.c
@@ -31,6 +31,7 @@
 #include <openbsc/handover.h>
 #include <openbsc/debug.h>
 #include <openbsc/gsm_04_08.h>
+#include <osmocom/abis/trau_frame.h>
 #include <openbsc/trau_mux.h>
 
 #include <osmocom/gsm/protocol/gsm_08_08.h>
diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c
index 36a758b..e20d8f7 100644
--- a/openbsc/src/libbsc/handover_logic.c
+++ b/openbsc/src/libbsc/handover_logic.c
@@ -39,6 +39,7 @@
 #include <openbsc/signal.h>
 #include <osmocom/core/talloc.h>
 #include <openbsc/transaction.h>
+#include <osmocom/abis/trau_frame.h>
 #include <openbsc/trau_mux.h>
 
 struct bsc_handover {
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index 76c47a5..5203b90 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -1359,8 +1359,15 @@ void _gsm48_cc_trans_free(struct gsm_trans *trans)
 	}
 	if (trans->cc.state != GSM_CSTATE_NULL)
 		new_cc_state(trans, GSM_CSTATE_NULL);
+	/* Be sure to unmap upstream traffic for our callref only. */
 	if (trans->conn)
-		trau_mux_unmap(&trans->conn->lchan->ts->e1_link, trans->callref);
+		trau_mux_unmap(&trans->conn->lchan->ts->e1_link, trans->callref_keep);
+
+	/* free application RTP socket */
+	if (trans->cc.rs) {
+		rtp_socket_free(trans->cc.rs);
+		trans->cc.rs = NULL;
+	}
 }
 
 static int gsm48_cc_tx_setup(struct gsm_trans *trans, void *arg);
@@ -1478,6 +1485,7 @@ static int switch_for_handover(struct gsm_lchan *old_lchan,
 		new_rs->receive = old_rs->receive;
 		break;
 	case RTP_NONE:
+	case RTP_RECV_APP:
 		break;
 	}
 
@@ -1702,6 +1710,153 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
 	return 0;
 }
 
+static int mncc_rtp_create(struct gsm_network *net, uint32_t callref,
+	struct gsm_trans *trans, struct rtp_socket *rs,
+	struct gsm_mncc_rtp *mncc)
+{
+	/* use RTP instead of MNCC socket, for traffic
+	 * open application RTP socket */
+	if (rs) {
+		LOGP(DCC, LOGL_ERROR, "RTP already created.\n");
+		return -EIO;
+	}
+	rs = trans->cc.rs = rtp_socket_create();
+	if (!rs) {
+		LOGP(DCC, LOGL_ERROR, "RTP socket creation failed.\n");
+		/* reply with IP/port = 0 */
+		mncc->ip = 0;
+		mncc->port = 0;
+		mncc_recvmsg(net, trans, MNCC_RTP_CREATE,
+			(struct gsm_mncc *)mncc);
+		return -EIO;
+	}
+	rs->rx_action = RTP_RECV_APP;
+	rs->receive.net = net;
+	rs->receive.callref = callref;
+	/* reply with bound IP/port */
+	mncc->ip = ntohl(rs->rtp.sin_local.sin_addr.s_addr);
+	mncc->port = ntohs(rs->rtp.sin_local.sin_port);
+	mncc_recvmsg(net, trans, MNCC_RTP_CREATE, (struct gsm_mncc *)mncc);
+
+	return 0;
+}
+
+static int mncc_rtp_connect(struct gsm_network *net, struct gsm_trans *trans,
+	struct rtp_socket *rs, struct gsm_mncc_rtp *mncc)
+{
+	int rc;
+
+	if (!rs) {
+		LOGP(DCC, LOGL_ERROR, "RTP not created.\n");
+		return -EIO;
+	}
+	rc = rtp_socket_connect(trans->cc.rs, mncc->ip, mncc->port);
+	if (rc < 0) {
+		LOGP(DCC, LOGL_ERROR, "RTP socket connect failed.\n");
+		/* reply with IP/port = 0 */
+		mncc->ip = 0;
+		mncc->port = 0;
+		mncc_recvmsg(net, trans, MNCC_RTP_CONNECT,
+			(struct gsm_mncc *)mncc);
+		return -EIO;
+	}
+	/* reply with local IP/port */
+	mncc->ip = ntohl(rs->rtp.sin_local.sin_addr.s_addr);
+	mncc->port = ntohs(rs->rtp.sin_local.sin_port);
+	mncc_recvmsg(net, trans, MNCC_RTP_CONNECT, (struct gsm_mncc *)mncc);
+
+	return 0;
+}
+
+static int mncc_rtp_free(struct gsm_network *net, struct gsm_trans *trans,
+	struct rtp_socket *rs, struct gsm_mncc_rtp *mncc)
+{
+	if (!rs) {
+		LOGP(DCC, LOGL_ERROR, "RTP not created.\n");
+		return -EIO;
+	}
+	rtp_socket_free(trans->cc.rs);
+	trans->cc.rs = NULL;
+	/* reply */
+	mncc_recvmsg(net, trans, MNCC_RTP_FREE, (struct gsm_mncc *)mncc);
+
+	return 0;
+}
+
+/* handle RTP requests of application */
+static int mncc_rtp(struct gsm_network *net, uint32_t callref,
+	struct gsm_mncc_rtp *mncc)
+{
+	struct rtp_socket *rs;
+	struct gsm_trans *trans;
+	int rc = -EINVAL;
+
+	/* Find callref */
+	trans = trans_find_by_callref(net, callref);
+	if (!trans) {
+		LOGP(DCC, LOGL_ERROR, "Unknown transaction for callref=%d\n",
+			callref);
+		return -EINVAL;
+	}
+
+	rs = trans->cc.rs;
+
+	switch (mncc->msg_type) {
+	case MNCC_RTP_CREATE:
+		rc = mncc_rtp_create(net, callref, trans, rs, mncc);
+		break;
+	case MNCC_RTP_CONNECT:
+		rc = mncc_rtp_connect(net, trans, rs, mncc);
+		break;
+	case MNCC_RTP_FREE:
+		rc = mncc_rtp_free(net, trans, rs, mncc);
+		break;
+	}
+
+	return rc;
+}
+
+/* handle tch frame from application */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	struct gsm_trans *trans;
+	struct gsm_bts *bts;
+
+	/* Find callref */
+	trans = trans_find_by_callref(net, data->callref);
+	if (!trans) {
+		LOGP(DMNCC, LOGL_ERROR, "TCH frame for non-existing trans\n");
+		return -EIO;
+	}
+	if (!trans->conn) {
+		LOGP(DMNCC, LOGL_NOTICE, "TCH frame for trans without conn\n");
+		return 0;
+	}
+	if (trans->conn->lchan->type != GSM_LCHAN_TCH_F
+	 && trans->conn->lchan->type != GSM_LCHAN_TCH_H) {
+		/* This should be LOGL_ERROR or NOTICE, but
+		 * unfortuantely it happens for a couple of frames at
+		 * the beginning of every RTP connection */
+		LOGP(DMNCC, LOGL_DEBUG, "TCH frame for lchan != TCH_F/TCH_H\n");
+		return 0;
+	}
+	bts = trans->conn->lchan->ts->trx->bts;
+	if (!is_e1_bts(bts)) {
+		if (!trans->conn->lchan->abis_ip.rtp_socket) {
+			DEBUGP(DMNCC, "TCH frame to lchan without RTP connection\n");
+			return 0;
+		}
+		if (trans->conn->lchan->abis_ip.rtp_socket->receive.callref != callref) {
+			/* Drop frame, if not our callref. This happens, if
+			 * the call is on hold or retrieved by another
+			 * transaction. */
+			return 0;
+		}
+		return rtp_send_frame(trans->conn->lchan->abis_ip.rtp_socket, data);
+	} else
+		return trau_send_frame(trans->conn->lchan, data);
+}
+
 static int gsm48_cc_rx_status_enq(struct gsm_trans *trans, struct msgb *msg)
 {
 	DEBUGP(DCC, "-> STATUS ENQ\n");
@@ -2937,7 +3092,6 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg)
 	int i, rc = 0;
 	struct gsm_trans *trans = NULL, *transt;
 	struct gsm_subscriber_connection *conn = NULL;
-	struct gsm_bts *bts = NULL;
 	struct gsm_mncc *data = arg, rel;
 
 	DEBUGP(DMNCC, "receive message %s\n", get_mncc_name(msg_type));
@@ -2950,46 +3104,15 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg)
 		return tch_recv_mncc(net, data->callref, 0);
 	case MNCC_FRAME_RECV:
 		return tch_recv_mncc(net, data->callref, 1);
+	case MNCC_RTP_CREATE:
+	case MNCC_RTP_CONNECT:
+	case MNCC_RTP_FREE:
+		return mncc_rtp(net, data->callref, (struct gsm_mncc_rtp *) 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) {
-			LOGP(DMNCC, LOGL_ERROR, "TCH frame for non-existing trans\n");
-			return -EIO;
-		}
-		log_set_context(BSC_CTX_SUBSCR, trans->subscr);
-		if (!trans->conn) {
-			LOGP(DMNCC, LOGL_NOTICE, "TCH frame for trans without conn\n");
-			return 0;
-		}
-		if (trans->conn->lchan->type != GSM_LCHAN_TCH_F
-		 && trans->conn->lchan->type != GSM_LCHAN_TCH_H) {
-			/* This should be LOGL_ERROR or NOTICE, but
-			 * unfortuantely it happens for a couple of frames at
-			 * the beginning of every RTP connection */
-			LOGP(DMNCC, LOGL_DEBUG, "TCH frame for lchan != TCH_F/TCH_H\n");
-			return 0;
-		}
-		bts = trans->conn->lchan->ts->trx->bts;
-		switch (bts->type) {
-		case GSM_BTS_TYPE_NANOBTS:
-		case GSM_BTS_TYPE_OSMO_SYSMO:
-			if (!trans->conn->lchan->abis_ip.rtp_socket) {
-				DEBUGP(DMNCC, "TCH frame to lchan without RTP connection\n");
-				return 0;
-			}
-			return rtp_send_frame(trans->conn->lchan->abis_ip.rtp_socket, arg);
-		case GSM_BTS_TYPE_BS11:
-		case GSM_BTS_TYPE_RBS2000:
-		case GSM_BTS_TYPE_NOKIA_SITE:
-			return trau_send_frame(trans->conn->lchan, arg);
-		default:
-			LOGP(DCC, LOGL_ERROR, "Unknown BTS type %u\n", bts->type);
-		}
-		return -EINVAL;
+		return tch_frame_down(net, data->callref, (struct gsm_data_frame *) arg);
 	}
 
 	memset(&rel, 0, sizeof(struct gsm_mncc));
diff --git a/openbsc/src/libmsc/mncc_sock.c b/openbsc/src/libmsc/mncc_sock.c
index dd0a44f..adb56fc 100644
--- a/openbsc/src/libmsc/mncc_sock.c
+++ b/openbsc/src/libmsc/mncc_sock.c
@@ -37,6 +37,8 @@
 #include <openbsc/debug.h>
 #include <openbsc/mncc.h>
 #include <openbsc/gsm_data.h>
+#include <openbsc/transaction.h>
+#include <openbsc/rtp_proxy.h>
 
 struct mncc_sock_state {
 	struct gsm_network *net;
@@ -50,6 +52,18 @@ int mncc_sock_from_cc(struct gsm_network *net, struct msgb *msg)
 	struct gsm_mncc *mncc_in = (struct gsm_mncc *) msgb_data(msg);
 	int msg_type = mncc_in->msg_type;
 
+	/* application uses RTP for this transaction, we send our data via RTP,
+	 * otherwise we send it through MNCC interface */
+	if (mncc_is_data_frame(msg_type)) {
+		struct gsm_trans *trans = trans_find_by_callref(net, mncc_in->callref);
+
+		if (trans && trans->cc.rs) {
+			rtp_send_frame(trans->cc.rs, (struct gsm_data_frame *) mncc_in);
+			msgb_free(msg);
+			return 0;
+		}
+	}
+
 	/* Check if we currently have a MNCC handler connected */
 	if (net->mncc_state->conn_bfd.fd < 0) {
 		LOGP(DMNCC, LOGL_ERROR, "mncc_sock receives %s for external CC app "
diff --git a/openbsc/src/libmsc/transaction.c b/openbsc/src/libmsc/transaction.c
index e425e67..bdd3d8e 100644
--- a/openbsc/src/libmsc/transaction.c
+++ b/openbsc/src/libmsc/transaction.c
@@ -78,6 +78,7 @@ struct gsm_trans *trans_alloc(struct gsm_subscriber *subscr,
 	trans->protocol = protocol;
 	trans->transaction_id = trans_id;
 	trans->callref = callref;
+	trans->callref_keep = callref;
 
 	llist_add_tail(&trans->entry, &subscr->net->trans_list);
 
diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c
index b2ac4bb..8571a1a 100644
--- a/openbsc/src/libtrau/rtp_proxy.c
+++ b/openbsc/src/libtrau/rtp_proxy.c
@@ -471,7 +471,7 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss)
 		other_rss->bfd.when |= BSC_FD_WRITE;
 		break;
 
-	case RTP_RECV_UPSTREAM:
+	case RTP_RECV_UPSTREAM: /* from BTS to application */
 		if (!rs->receive.callref || !rs->receive.net) {
 			rc = -EIO;
 			goto out_free;
@@ -500,6 +500,24 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss)
 		trau_tx_to_mncc(rs->receive.net, new_msg);
 		break;
 
+	case RTP_RECV_APP: /* from remote application */
+		if (!rs->receive.callref || !rs->receive.net) {
+			rc = -EIO;
+			goto out_free;
+		}
+		if (rss->bfd.priv_nr != RTP_PRIV_RTP) {
+			rc = ENOTSUP;
+			goto out_free;
+		}
+		rc = rtp_decode(msg, rs->receive.callref, &new_msg);
+		if (rc < 0)
+			goto out_free;
+		msgb_free(msg);
+		tch_frame_down(rs->receive.net, rs->receive.callref,
+			(struct gsm_data_frame *) new_msg->data);
+		msgb_free(new_msg);
+		break;
+
 	case RTP_NONE: /* if socket exists, but disabled by app */
 		msgb_free(msg);
 		break;
diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c
index bb513cc..15a84b0 100644
--- a/openbsc/src/libtrau/trau_mux.c
+++ b/openbsc/src/libtrau/trau_mux.c
@@ -171,7 +171,9 @@ int trau_mux_unmap(const struct gsm_e1_subslot *ss, uint32_t callref)
 			llist_del(&ue->list);
 			return 0;
 		}
-		if (ss && !memcmp(&ue->src, ss, sizeof(*ss))) {
+		/* Only release, if no callref is given. We must ensure that
+		 * only the transaction's upstream is removed, if exists. */
+		if (ss && !callref && !memcmp(&ue->src, ss, sizeof(*ss))) {
 			llist_del(&ue->list);
 			return 0;
 		}
@@ -497,11 +499,21 @@ int trau_send_frame(struct gsm_lchan *lchan, struct gsm_data_frame *frame)
 	uint8_t trau_bits_out[TRAU_FRAME_BITS];
 	struct gsm_e1_subslot *dst_e1_ss = &lchan->ts->e1_link;
 	struct subch_mux *mx;
+	struct upqueue_entry *ue;
 	struct decoded_trau_frame tf;
 
 	mx = e1inp_get_mux(dst_e1_ss->e1_nr, dst_e1_ss->e1_ts);
 	if (!mx)
 		return -EINVAL;
+	if (!(ue = lookup_trau_upqueue(dst_e1_ss))) {
+		/* Call might be on hold, so we drop frames. */
+		return 0;
+	}
+	if (ue->callref != frame->callref) {
+		/* Slot has different transaction, due to
+		 * another call. (Ours is on hold.) */
+		return 0;
+	}
 
 	switch (frame->msg_type) {
 	case GSM_TCHF_FRAME:
diff --git a/openbsc/src/utils/bs11_config.c b/openbsc/src/utils/bs11_config.c
index e8acb46..f459744 100644
--- a/openbsc/src/utils/bs11_config.c
+++ b/openbsc/src/utils/bs11_config.c
@@ -83,6 +83,12 @@ struct osmo_counter *osmo_counter_alloc(const char *name)
 	return NULL;
 }
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	return 0;
+}
+
 int handle_serial_msg(struct msgb *rx_msg);
 
 /* create all objects for an initial configuration */
diff --git a/openbsc/tests/abis/abis_test.c b/openbsc/tests/abis/abis_test.c
index e7e78d2..6bb84cc 100644
--- a/openbsc/tests/abis/abis_test.c
+++ b/openbsc/tests/abis/abis_test.c
@@ -27,6 +27,12 @@
 #include <openbsc/abis_nm.h>
 #include <openbsc/debug.h>
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down(struct gsm_network *net, uint32_t callref, struct gsm_data_frame *data)
+{
+	return 0;
+}
+
 static const uint8_t simple_config[] = {
 	/*0, 13, */
 	66, 18, 0, 3, 1, 2, 3, 19, 0, 3, 3, 4, 5,
diff --git a/openbsc/tests/gbproxy/gbproxy_test.c b/openbsc/tests/gbproxy/gbproxy_test.c
index d32ac83..69ce58a 100644
--- a/openbsc/tests/gbproxy/gbproxy_test.c
+++ b/openbsc/tests/gbproxy/gbproxy_test.c
@@ -34,6 +34,12 @@
 
 #define SGSN_NSEI 0x0100
 
+/* dummy function to keep rtp_proxy.c happy */
+int tch_frame_down()
+{
+	return 0;
+}
+
 struct gbproxy_config gbcfg;
 
 static int gprs_process_message(struct gprs_ns_inst *nsi, const char *text,
-- 
1.8.1.5


--------------060708050209070502020504--