This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Neels, thanks for looking into this. On Wed, Oct 10, 2018 at 01:18:39PM +0200, Neels Hofmeyr wrote: > So I think there's still some fundamental concept that I'm lacking. Is there > anyone more familiar with AMR and/or the way 3G encodes audio, and whether > there's a simple way to make them match? Where should I read on? The fundamental part that you're lacking is the fact that the codec payload for 3G and 2G is completely different. You will need lots of bit re-shuffling in order to make this work. >From the MGW point of view, IuUP and the 3G-style codec payload should be seen as a different codec, and an endpoint with two connections of two different codec requires "transcoding". The only difference here is that in case of AMR on both the IuUP and the 2G side, you don't actually transcode to PCM and re-encode, but you're really just shuffling around the bits. > Would a call router like we use in the C3 POC be able to transcode when the > IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP > with GSM.) Nobody outside a 3G network will have any idea what IuUP is. Even more so, I think nobody on the planet will be able to process codec payload that is in IuUP payload format without the IuUP header. Basically either a) you have IuUP and the related payload format, or b) you have no IuUP and native RTP [AMR] payload format Going in between by just removing the IuUP header you would create yet another derivative that doesn't exist so far. > I've noticed the laforge/iu_up branch in libosmocore only later, It would have been great to first catch up about this, before investing time on an implementation. I had mentioned this branch in http://osmocom.org/issues/1936 when I wrote it close to a year ago. > which includes an FSM that apparently does only state transitions so far. It does a bit more, such as both header and payload CRC computation / verification and should actually implement pretty much everything between the TNL and the RNL SAP and implement all primitives on both sides. It hasn't been tested yet, though. To do that, I first implemented RTP source/sink in TTCN3 and then IuUP in TTCN3, but then got distracted before putting the full setup together and write actual test cases against the libosmocore iu_up impementation. You should be able to * feed primitives from the transport layer (RTP) up into it using osmo_iuup_tnl_prim_up() * feed primitives from the upper layer down into it using osmo_iuup_rnl_prim_down() The transformations are done inside the FSM using tnl_to_rnl_data() as well as rnl_to_tnl_data(). Only SMpSDU mode is implemented, which is what's used in our case. > My patch has no FSM yet, since all I see on the wire is Init->InitAck, > then Data PDUs, and maybe an occasional error report. Do those FSM > states convey a secret of making 3G encoding readable by 2G? The state machines are required as soon as you actually have changes between the AMR codec rates, i.e. the actual *adaptive* part of AMR. Also, once you are actually re-ordering ("transcoding") the payload bits, you will have to recompute the CRC. I do think the FSM should be used, rather than some other approach. -- - 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)