Re: First successful voice calls

Hi David, hope you don't mind me Cc'in the list, as other people might find this information useful. On Tue, Feb 17, 2009 at 08:31:53PM -0800, David A. Burgess wrote: thanks! yes, it is the most simple option. commit the TCH early and you don't have to do conflict resolval in the middle of the call setup if you first only have a SDCCH and then want to switch to a TCH but don't have a free one. I was pretty clear that I have to do CHANNEL MODE MODIFY on GSM 04.08 to tell the MS to switch to voice mode. However, what is a bit weird is that in addition you have to send a MODE MODIFY REQUEST (08.58) packet to the BTS. Plus, the actual channel mode values for EFR are different on 04.08 and 08.58 ;) Why is it weird? Because typically in a case like this, you would send one 08.58 packet to the BTS, with the payload for the 04.08 packet. The BTS would then do the local state change, and send the 04.08 packet over the air to cause the MS state change. This is how it works with many other operations, you almost never have to explicitly talk to both sides separately. I was aware of that, but then you need another channel assignment and a more complex resource management, at least that's what I think. So I went for very early assingment for now. No, I'm not transcoding. But in order to route TRAU frames from one TCH to the other, you already need to do quite a bit of parsing and re-encoding. It's just how they stuff the bits in the TRAU frames, not actually touching any of the voice processing. I think what is useful is to 'outsource' this TRAU frame processing into a separate process. Apart from simple commands like 'map this sub-channel to another sub-channel' it doesn't need much interaction with the actual signalling part. In fact, the relatively high data rates clog the debug log and make it hard to strace OpenBSC for further work on the signalling side. On the ip.access nanoBTS it's even easier. You can directly feed the RTP streams over the loopback device on the BTS, so the voice data naver even has to go to the BTS (unless you want to route between multiple BTS, which I haven't done yet but is very easy with nanoBTS too, in fact the code _should_ already work. What will be interesting is to figure out the actual RTP payload of the ip.access. I've already seen they use RTP payload type 127 and the size of the packets looks like it is one 40-byte TRAU frame per RTP packet. If that is true, I would probably work on E1-to-RTP interworking to route calls between traditional E1-based BTS and IP-based ones. Cheers, -- - 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)