<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2>hi,</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>here is the patch to
support audio exchange between application interface and
nanoBTS.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>here is the format
as defined by RFC: (just fyi)</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>first byte has
the magic value of 0xd0 plus four upper bits of the LARc[0] element as
lower bits.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>third byte has the
lower four bits of LARc[1] element as upper bits and so
on...</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>this format can
directly be transcoded with the open source lossy gsm codec.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>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())</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>as soon as the patch is applied, i will also
check in linux-call-router modification for the new audio frame
format.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2>regards,</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2>andreas</FONT></SPAN></DIV>
<DIV><SPAN class=625055818-03102009><FONT face=Arial
size=2></FONT></SPAN> </DIV></BODY></HTML>