audio support for application interface with nanoBTS

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/.

Andreas.Eversberg Andreas.Eversberg at versatel.de
Sat Oct 3 19:23:52 UTC 2009


hi,
 
here is the patch to support audio exchange between application
interface and nanoBTS.
 
the patch changes the audio format from TRAU frame format to RTP payload
format on the application interface. also the BS11 TRAU frame is
converted to/from RTP payload format (inside trau_mux.c), so an
application does not have to care about what BTS is used.
 
here is the format as defined by RFC: (just fyi)
first byte has the magic value of 0xd0 plus four upper bits of the
LARc[0] element as lower bits.
second byte has the lower two bits of the LARc[0] element as upper bits
and the upper bits of LARc[1] element as lower bits.
third byte has the lower four bits of LARc[1] element as upper bits and
so on...
 
this format can directly be transcoded with the open source lossy gsm
codec.
 
the rtp_proxy.c now parses RTP frames and generates them. for easier
code, i just mirrored the received RTCP frames back to the nanoBTS,
mangled of yourse. (oops, maybe i need to change some synchronization
source identifiers.) i think there is no problem with that right now.
because RFC requires special synchronization source (ssrc) generation, i
added md5 code and the (funny) random number generator. (see rtp_proxy.c
random32())
 
as soon as the patch is applied, i will also check in linux-call-router
modification for the new audio frame format.
 
note that this code is just quickly tested, it works with both BS11 and
nanoBTS and should not crash on corrupt or extended RTP data.
the delay of audio data sent to nanoBTS was > 0.5 seconds. i think this
is too much. maybe it is because i seamlessly increment the timestamp
value in the RTP frame, even if the application dropps (delays) frames.
 
regards,
 
andreas
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20091003/ac460b3b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtp.patch
Type: application/octet-stream
Size: 21809 bytes
Desc: rtp.patch
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20091003/ac460b3b/attachment.obj>


More information about the OpenBSC mailing list