fixes for mncc-harald branch

historical

Hi Andreas,

On Sun, Jun 14, 2009 at 02:20:39PM +0200, Andreas.Eversberg wrote:

> finally i ported linux-call-router to new mncc api. this is quite easy,
> because only data types changed. 

thanks!

> i don't care about change of mncc api from time to time, because openbsc does
> not have that much applications yet. 

thanks, that's good to hear.  We should probably introduce an API version
number somewhere to make it fail gracefully if something changes [but still
compiles/links].

> i think that trau frames don't have anything todo with mncc api and
> should be use own interface in the future (hopefully with ipaccess).

ipaccess is very different from traditional TRAU frames.  To be honest, I have
not yet fully reverse engineered the RTP payload that it sends.  Initially I
assumed that it would just send the raw GSM FR/EFR/AMR data, but unfortunately
that seems not the case, as the RTP payload is too short for that.

Right now I didn't worry about it, since when we switch calls between a nanoBTS
and another nanoBTS (or the same nanoBTS), we can instruct the BTS' to send the
RTP/RTCP streams directly to each other.

In the mid-term we probably need to come up with a dedicated media gateway.
That could and should be a totally separate program, but able to bind to E1
timeslots and receive/multiplex TRAU frames, as well as receive and
interpret/switch the RTP payload as used by the nanoBTS.

If anyone wants to look further into this, I'm happy to record some PCAP files
with some example RTP/RTCP dumps.  If you want, even combined with the
TCP connection to the BSC, so you have a correct timeline and know what the BSC
told the BTS when, and how the BTS reacted to that.

> i tested openbsc with linux-call-router. everything worked fine after
> adding some fixes. now, the mncc-harald includes every work i made,
> except the installation of library and include files.

ok, thanks.  I think I'll merge mncc-harald into the master branch within
the next couple of days.

> fix 1: i use this workarround to allow my mobile to get a traffic
> channel. the mobile reqests a sdcch channel, but currently openbsc is
> not able to switch channel. (this should be possible in the future for
> handover.) also it checks if there is actually a traffic channel
> currently in use, when making a call.

I'll look at this in more detail.  I'm not sure if I want to merge your
hack.  I had some old patches for early / very early and OCASU assignment,
making it a configurable feature.

Based on my experience testing with various phones, we _might_ actually need
something like a blacklist based on the IMEI, where we make sure to use
a certain assignment method based on the particular phone model.

I think in reality nobody does the early or very early assignment, since
it needs more network resources even if the call cannot be established -
which is probably quite often the case.  I don't have any statistics, but
if it's 30-50% of all initiaded calls, it's definitely worth optimizing for it.

> fix 2: not actually a fix: adding imsi to gsm_mncc_number allows to
> notify application about calling/connected imsi. also it is possible to
> dial a subscriber with no extension assigned, just by using imsi. maybe
> it is wiser to put imsi string into gsm_mncc, because it is only used
> only once in a message.

yes, can you please provide a patch that adds it to gsm_mncc, rather than gsm_mncc_number?

> fix 3: while detaching, we don't hold a ressource (we don't call
> lchan_use), so we don't need to "lchan_put".
>
> fix 4: the given cause value and location parameters are used in
> mncc_release_ind function, rather than hardcoded. the plain cause
> numbers are replaced by the definitions from header file.

I've applied those two to my tree, will push it in the next minutes.

Cheers from Taipei Airport,
-- 
- 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)