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