hello
I run the mobile app, but the error occur:
What about the cause of the error,and how to solve it? Thanks！
LOSS counter for ACCH 31
Dropping frame with 86 bit errors
Dropping frame with 84 bit errors
Dropping frame with 79 bit errors
LOSS counter for ACCH 30
Dropping frame with 82 bit errors
Dropping frame with 82 bit errors
Dropping frame with 89 bit errors
LOSS counter for ACCH 29
Dropping frame with 86 bit errors
Dropping frame with 76 bit errors
Dropping frame with 70 bit errors
LOSS counter for ACCH 28
Dropping frame with 88 bit errors
Dropping frame with 79 bit errors
Dropping frame with 70 bit errors
LOSS counter for ACCH 27
Hi,
I have been just wondering... would it be possible to use your project
as a base for DIY encrypted cellphone? My idea is that if I could get
hold to output data after voice is encoded by GSM EFR codec, I might
just easily encrypt this digital stream using AES128 and build trully
encrypted cellphone.
Where does actual "analog voice from microphone to digital data"
conversion happends? In a layer1 that runs in a chip, or layer23 that
runs on a PC? If it would be in layer23, encrypting a data stream with
AES 128 whould be doable, am I missing something?
Thanks Marek
--
S pozdravem / Best regards
Marek Stopka
Kontakty / Contacts
Mobil/Cell phone:+420 608 149 955
WEB: www.stopkaconsulting.eu
I hear what you are saying, and we are working to support inter-BTS
meshing for OpenBTS and OpenBSC.
However, there is also value in getting the phones to mesh, if only
because there are plenty situations where you might not be able to get
a BTS, or be able to use any BTS that is around.
Kristen Eisenberg
Billige Flüge
Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33)
5310967
Email:
utebachmeier at
gmail.com
Site:
http://flug.airego.de
- Billige Flüge vergleichen
hi,
i just collected all my patches together that i would have merged:
1. i added two patches to jolly/battery branch of osmocombb. it will add
a font with symbols and display them at rssi. since i did not receive a
reply about that from christian, i pushed it in this seperate branch so
far. christian, if you find the time, just look at it.
2. there are several patches in my "testing" branch at jolly/ui of
osmocombb. these patches are tested and work quite well. the are not
related to the ui. i think they could me mergend:
commit 66c21b3b7d30db205202d46893032ae2a73992a2
layer23: Send SIM APDUs via GSMTAP
Usefull to trace SIM messages together with Um messages.
commit b9ff5044a5fcbd07e6a295d75e14c7c504259914
layer23: Be sure to close mncc socket on exit of mobile instance
commit e30e351d66f07e6effee768412a9d8f31202b4ed
layer1: Retry fist power measurement, if it seems to fail
In some cases (e.g. after a call with TCH) the first power measurement
after a full reset will always return 0 (-110dbm). In this case the
measurment is repeated once again.
This is just a workarround, and it will not fix the actual cause.
3. there are several additions and fixes at jolly/rtpmux branch of openbsc.
commit db3a7dd357bd7cd842a80655e734a1b4afdb6f7c and commit
872c6c002add0a741514aa505df9379a6fcdb955 allow to exchange traffic via
rtp with a given rtp endpoint. the destination can be controlled via
mncc interface. the result is that the traffic is not routed via mncc
interface, but directly exchanged with the given rtp endpoint. lcr
supports that, so traffic between sip and openbsc is directly forwarded
and not routed through lcr and mncc interface.
commit 3d407e7c8e5c4e01dc07a530f910d29fac687809 and commit
f47d13e55888576c9201a3a7fee04fc58f98ff66 will handle bad frames from e1
bts. if a frame is bad, the rtp packet is dropped (if forwarded via
rtp). if the bad frame is received by lcr via mncc interface, lcr will
extrapolate the missing audio by repeating last valid frame with reduced
value. instead of having a distrorted sound, the audio stream will now
be clear, even if some frames are bad.
commit 0193b8a76824cdce9d9da3f7374a928efac6f96c allows dynamic payload
types when forwarding rtp traffic to a given rtp endpoint. (used for
EFR/AMR/HR)
commit ea724c6af9e1a5b6df8d0e5965f357896834d3ce and commit
a22e598c0a93f88433c6a00bd2acdde5c2f496d5 will fix the problems with
delay and loosing audio at nanobts. it uses system clock as a basis to
correct timestamp and sequence number of frames transmitted to the bts.
commit bf14b25358f7ceb021e2397e90c2fb9484245b7b fixes problem with
interruption of traffic, if packet transmission via rtp fails in the
beginning.
the result of all these patches is a reliable audio stream. the call
waiting works, as well as hold/retrieve of calls without audio
interruption or increasing/high delay. (even if database access makes
openbsc stop for some time.) in conjuction with lcr, a sip gateway can
directly exchange audio traffic with openbsc. the codec to be used is
negotiated between SIP gateway and MS. (depending on support and preference)
4. long time ago i extraced the sms protocols "smc" and "smr" (TS 11.11)
from openbsc and added a state machines. they are now part of
libosmocore and are used for sending/receiving sms via osmocombb. i
removed all that code from openbsc and use libosmocore instead. see
jolly/sms for the 4 patches.
i hope that was not too much at a time :)
regards,
andreas
hello
1.if a cell has multiple TRX, and the CCCH number >1,then can the
phone request channel on other timeslot but timeslot 0 in the uplink;
how does a real phone deal with it?
2.how to mitigate the RACH DOS in the GSM network?
anyone can help me?
Hi,
is it technically possible to sniff the air traffic (for example with
ccch_scan from the osmocombb burst_ind branch) and correlate the
relationship between a burst and a paging request (which contains the
tmsi of the mobile) ?
Basically: What are the steps to determine which tmsi (mobile) did which
burst ?
Thank you for your information!
cheers,
Simian
