Hello Harald,
On Wed, 29 Jul 2009 14:43:12 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> If you're interested, you can certainly try for yourself with your nanoBTS...
>
You are joking, right ? How should it work on my Windows machine if it
does not work on Linux ;-) ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Nordin,
On Wed, 29 Jul 2009 11:51:59 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> I can't find a good link about how several MSs on one ARFCN can send and
> receive speech data.
Have a look at the following, the first is a general introduction with
good references to the GSM specification, the second is about speech
coding:
http://en.wikipedia.org/wiki/Um_Interfacehttp://www.gsmfordummies.com/encoding/encoding.shtml
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Wed, 29 Jul 2009 12:33:59 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
> page, like the EFR capture before. I hope this helps you to decode the voice
> samples.
Decoding with Toast would work fine but there is the same problem, lots
of missing packets. If I look at the capture timestamps, there seem to
miss about 0.8 seconds of data at regular intervals (the first disruption
is at packet number 681, the next at 710, 742, ...). These are also the
positions where the Wireshark RTP analysis complains about wrong sequence
numbers.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Tue, 28 Jul 2009 20:58:46 CEST, "Dieter Spaar" <spaar(a)mirider.augusta.de> wrote:
>
> I just took a quick look at the dump with Wireshark, its possible to
> safe the raw RTP payload from within Wireshark and it looks OK (31-byte
> EFR packages starting with 0xC in the high nibble). However I have
> no ready-made EFR decoder available so I can't decode the speech.
I did play a little bit with the EFR reference implementation from
GSM 06.35. Its possible to convert the data and I can understand a few
words (a "Yes" at the beginning and a "Bye" at the end). However it seems
that several RTP packages are missing, also the RTP Analysis Tool of
Wireshark says so (according to it more than 80% is missing). Anyway,
basically EFR decoding seems to work as expected.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi guys,
I read Goller's documentation "About the GSM-Dm-Channels", but I'm a bit
confused about something.
I understand that one TDMA frame has a period of 4.615 ms and consists
of 8 Time slots, each of a period of 576.9 us. When a MS registers to
the BTS, it gets one Time-slot, but how is speech transfered? Normally
the Fs (samplefrequency) is 8 KHz, this means every 128 us one byte
sample. If I have one timeslot of let's say 577 us , than there is a gap
of 7 other timeslots, which makes a 4 ms gap. Also the speech data is
compressed. How is that damn speech data multiplexed with other MSs and
finally received on the other side as 8 bit samplevalue at a rate of 128
us (8 KHz).
It gets fuzzy to me, cause I wrote a microcontroller project which,
among other things, samples audio and than transfered to a GSM module.
This is done at 8 KHz samplerate, so how is that done when I have only
one TimeSlot of 577 us every 4 ms period?
I can't find a good link about how several MSs on one ARFCN can send and
receive speech data.
Thank you.
Hi!
Using git version 58ca5b7ae70365c1285b2ea0cb3c3370a8f108a9 of openbsc,
plus the patch from the attachment, I was able to do a V1 (FR) call,
not only EFR.
The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
page, like the EFR capture before. I hope this helps you to decode the voice
samples.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> If everything works fine at HAR, we can do the bigger/better version
at 26C3,
> at least if we can somehow find more than the 2-3 nanoBTS1800 that we
currently
> have - at least for a couple of days.
hi harald,
i am looking forward to be at 26C3. i doubt that we can get a frequency
for a test network on the 900 band, because all frequencies are assigned
to GSM operators. therefore only nanoBTS1800 can be run legaly with a
test license of "bundesnetzagentur". currently the application interface
does not support audio streams of the nanoBTS, so other networks
(ISDN/DECT/SIP) cannot be connected yet. i would like to finish audio
processing for nanoBTS. can you provide me with some pcap files? a short
complete call (few seconds) of one rtp session (including setup, some
spoken words, and termination) would help. also the call must be made
with full rate codec, so i can test the playload on the GSM codec i
have. (not the enhanced full rate codec)
regards,
andreas
Hi!
For those who are planning to attend HAR2009 (http://har2009.org/):
We have just received regulatory approval for four ARFCN in the GSM900 band
during HAR2009. The Power on each ARFCN for BTS and MS is restricted to 100mW.
There are also some GSM1800 ARFCN's that we can use with up to 200mW, though
I don't yet know their values and how many.
I have created a wiki page at https://wiki.har2009.org/page/GSM
for further coordination of GSM related activities at HAR2009.
It would be great to know which other OpenBSC users/hackers will be present
at the event. As there are multiple things that I'm planning to do at HAR2009,
I would be happy about any help that I might get from you guys.
Basically there will be
* A 'stable' GSM network with BS-11 and OpenBSC for people to test
their phone interoperability with OpenBSC by making/receiving calls and
SMS.
* A nanoBTS1800 for use by OpenBSC hackers only to test/fix OpenBSC stuff
before putting it on the BS-11 'stable' network
* work on airprobe.
Especially for the 'stable' network, there is a lot of help required, among
others:
* physical setup of the BS-11
* registration of mobile phones into the network. It would probably be good
to have a setup where people can plug their SIM into a SIM card reader
(or phone that can read the IMSI). We can then create the SQL entry with
their IMSI and extension.
* making sure the network runs and OpenBSC / hfcmulti gets restarted in case
something hangs.
Please just respond to this mail if you want to help in any way.
Regards,
--
- 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)
Hello Harald,
On Tue, 28 Jul 2009 19:18:52 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Using this mode, I have created a pcap file with OML+RSL bringup, followed by
> one call between two MS (extn. 1005 calls 1003) where all RTP/RTCP packets are
> visible. The call uses EFR, since that is hardcoded in many places all over
> OpenBSC at the moment.
>
> The pcap file is available from
> http://bs11-abis.gnumonks.org/trac/attachment/wiki/nanoBTS/ipaccess-startup…
I just took a quick look at the dump with Wireshark, its possible to
safe the raw RTP payload from within Wireshark and it looks OK (31-byte
EFR packages starting with 0xC in the high nibble). However I have
no ready-made EFR decoder available so I can't decode the speech.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
While writing the RTP proxy, I've been playing with the ip.access RTP related
code for quite a bit. This is as far as I have understood it so far:
Setting up a voice call (for one MS)
* sending IPACCESS_BIND via RSL, specifying
* the GSM channel number IE
* the IP speech mode IE, indicating
* 0x1- : uni-directional, rx-only
* 0x-1 : EFR (0: FR, 2: AMR)
* receiving IPACCESS_BIND_ACK via RSL, specifying
* the GSM channel number IE
* the ip.access connection identifier
* the locally-bound UDP port for RTP
* the locally-bound IP address for RTP
* optionally: the RTP payload type
* sending IPACCESS_CONNECT via RSL, specifying
* the GSM channel number IE
* the ip.access connection identifier (from BIND_ACK)
* the remote UDP port number for RTP
* the remote IP address for RTP
* the IP speech mode IE, indicating
* 0x0-: bi-directional
* 0x-1: EFR (0: FR, 2: AMR)
* optionally: the RTP payload type, if BIND_CAK specified it
Misc observations:
* if BIND is called with IP speech mode IE 0x10 (uni-directional FR), then no
RTP payload type is returned in BIND_ACK. Instead, the standard type for GSM
06.10 (0x03) is used in the packets.
* I'm not sure which RTP payload type (and IP speech mode) is which, i.e. if
the payload type of BIND/BIND_ACK specifies "expect this payload type for
incoming packets" or "use this payload type for all RTP packets originated by
this side"
--
- 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)
