OpenBSC

openbsc@lists.osmocom.org

6 participants
4179 discussions

Re: ip.access RTP capture using Version 1 (FR) codec
by Dieter Spaar 29 Jul '09

29 Jul '09

Hello Harald, On Wed, 29 Jul 2009 16:55:23 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > Great! can you please provide one FR and one EFR pcap file for Andreas > Eversberg? It's probably best to replace the two corrupted files that I've > attached to the nanoBTS wiki-page. I am not sure if my two FR and EFR cpatures are good examples for the Wiki, the call is from one person only (me) counting numbers and saying "Hello Test" or similar things and you hear the voice on both channels because the two phones are close to each other. Of course they are good enough as an example for implementing the RTP media feature. So let me know if I shall provide them to Andreas only (Andreas, shall I send them to you as email, they are about 240 KByte as ZIP file ?). > You do have a wiki account, I assume. I don't think so, at least I have not yet requested an account. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: ip.access RTP capture using Version 1 (FR) codec
by Dieter Spaar 29 Jul '09

29 Jul '09

Hello Harald, On Wed, 29 Jul 2009 15:48:32 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > I'm telling you, OpenBSC's RTP proxy works fine. I've just made another call > and there are no drop-outs of .8 seconds or anything like that. I am sure that the proxy is working, I never doubt that. I guess for some reason Wireshark is just missing the data. I was joking about Windows versus Linux performance, but maybe this was not clear enough. > As all it uses is the sockets API, i.e. the very same calls that the > input/ipaccess.c module already uses, I think it should be very easy to make it > build using the posix compatibility of cygwin. I tried it in the meantime. No problem at all. The git version works as expected and Wireshark does not miss any packets here, each call is about 30 seconds. I tried it with EFR and FR, Wireshark can save the RTP payload, for EFR I had to convert the data first so that they fit to the GSM 06.35 reference implementation (they use a strange format which stores every bit into two bytes). For FR, Toast can convert the payload immediately. Tested on Windows XP and cygwin, Wireshark and bsc_hack running on the same machine. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

OpenBSC should now have full support for BS-11 with two TRX
by Harald Welte 29 Jul '09

29 Jul '09

Hi! Please note: =========================== commit d46299da00f923b24043aa37fa2bae17ffcc1ff7 make channel allocator policy multi-TRX aware For now, we assume that TRX1 (and higher) all have a TCH/F configuration on all of their timeslots commit 67b4c30a9de972d199830bba5535e934bd47ac0f complete TRX1 support for BS11 * remove old HAVE_TRX1 definition, replace it with '-1' commandline argument * make sure we actually configure the OML TRX attributes with a different ARFCN than TRX0 * make sure we configure timeslot 0 of TRX1 also in TCH/F mode This code is untested, but if you have a dual-trx BS-11, and the second TRX is activated, you should be able to run bsc_hack with the -1 option to enable and use the second trx. It works like this: * TRX1 shares E1 timeslot 0 for signalling * TRX1 RSL link uses TEI2 (TRX0 uses 1) * TRX1 on ARFCN+2, i.e. if you have TRX0 on 122, TRX1 will be 124 =========================== I'm very happy if somebody wans to test this. First of all, it is important to see if there are any error messages during OML and RSL brigup, and if the TEI2 link is actually established from mISDN. If you want to actually use the second TRX, you will either have to make sure all TCH/H on TRX0 are used (establish sufficient simultaneous calls), or hack chan_alloc.c to give a preference to TRX1, or to do round-robin or whatever :) 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)

1 0

Re: ip.access RTP capture using Version 1 (FR) codec
by Dieter Spaar 29 Jul '09

29 Jul '09

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

3 2

Re: TDMA frame, Time slot and speech data transfer confusion.
by Dieter Spaar 29 Jul '09

29 Jul '09

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_Interface http://www.gsmfordummies.com/encoding/encoding.shtml Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: ip.access RTP capture using Version 1 (FR) codec
by Dieter Spaar 29 Jul '09

29 Jul '09

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

2 1

Re: application TCH support for nanoBTS
by Dieter Spaar 29 Jul '09

29 Jul '09

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

1 0

TDMA frame, Time slot and speech data transfer confusion.
by Nordin 29 Jul '09

29 Jul '09

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.

2 1

ip.access RTP capture using Version 1 (FR) codec
by Harald Welte 29 Jul '09

29 Jul '09

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)

1 0

AW: HAR2009 TODO list
by Andreas.Eversberg 29 Jul '09

29 Jul '09

> 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

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC