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
Thanks a lot, Andreas.
I will review this ASAP, though it might take until tuesday until I can actually play with it and test it, due to travel reasons.
One thing I noted immediately: The newly-introduced md5c.c file is missing from your diff. Can you please re-submit with that file? Thanks.
(in case you work with git, first 'git add' the file, then 'git diff HEAD', if all your changes are not yet committed)
Regards,
one further note on the missing md5 file:
As it seems it is only used to generate a pseudo-random 32bit value for use in the SSRC: I'd rather not introduce a copy of MD5 for that.
There are two options to take:
1) simply use the same [not very random] method as we use for the TMSI
2) introduce a dependency to openssl and use that. Given that nanoBTS also support OML/RSL over SSL/TLS, I think sooner or later we will have to add that dependency anyway.
Regards,
On Sunday 04 October 2009 13:51:29 Harald Welte wrote:
one further note on the missing md5 file:
As it seems it is only used to generate a pseudo-random 32bit value for use in the SSRC: I'd rather not introduce a copy of MD5 for that.
There are two options to take:
simply use the same [not very random] method as we use for the TMSI
introduce a dependency to openssl and use that. Given that nanoBTS also support OML/RSL over SSL/TLS, I think sooner or later we will have to add that dependency anyway.
Are you sure you want to introduce code that is using SSL? This would mean we have to check if someone from the US sends us a SSL patch and reject it based on the region. The other issue with OpenSSL is that the license is considered to not be GPL compatible and that the GNUtls replacement is not there yet....
z.
On Sun, Oct 04, 2009 at 03:15:26PM +0200, Holger Freyther wrote:
On Sunday 04 October 2009 13:51:29 Harald Welte wrote:
one further note on the missing md5 file:
As it seems it is only used to generate a pseudo-random 32bit value for use in the SSRC: I'd rather not introduce a copy of MD5 for that.
There are two options to take:
simply use the same [not very random] method as we use for the TMSI
introduce a dependency to openssl and use that. Given that nanoBTS also support OML/RSL over SSL/TLS, I think sooner or later we will have to add that dependency anyway.
Are you sure you want to introduce code that is using SSL?
sure, SSL is a pretty standard thing.
This would mean we have to check if someone from the US sends us a SSL patch and reject it based on the region.
I think you're living in the past if you think that US crypto export regualtions are still in place... or am I missing something?
The other issue with OpenSSL is that the license is considered to not be GPL compatible and that the GNUtls replacement is not there yet....
gnutls is not there in what sense? Sure, it tends to behave different than one expected and it appearst to have interesting bugs here and there, but when it comes to the core/key functionality of simply handling a single TLS/SSL stream, I don't think there will be much of a problem with it. Debian is using + shipping it as the standard library for SSL/TLS for quite some time now, and I'm using it heavily on many systems...
-
Andreas.Eversberg -
Harald Welte -
Holger Freyther