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/.
Sipos Csaba dchardware at gmail.comHey Peter, > I'd suggest to make LCR use SIP for communcation with Asterisk. See > http://stuge.se/lcr.txt for a minimal example of LCR configuration. Do you have some more example configuration files for the Asterisk end of the SIP trunk? > Since you're using bridging you might also want to try rtp-bridge > between GSM and SIP, which could allow GSM phones and SIP phones to > negotiate codec directly, avoiding any transcoding. (But maybe it > only works with Abis over IP and not over ISDN? I'm not sure.) I am almost sure that RTP bridge can only be used with IP based BTSes which I don't have. My units are connecting via E1 dahdi. > You can of course continue to debug the LCR-Asterisk module but I > would suggest moving to SIP since I think working with SIP on both > legs makes debugging a bit easier. My problem is that I made test calls an analyzed the logs at both LCR and Asterisk end, and there is no difference between a good and a half sided call. First, I forced the GSM phones to use TCH/F FR only, then I forced LCR and Asterisk SIP clients to use Alaw only (SIP clients are not supporting any GSM codec). Transcoding obviously happens between TCH/F FR and Alaw, but how on earth is possible that the direction of the call can affect that this transcoding is going to be a success or not? If its a transcoding failure it shouldn't work in any direction. If its a call routing problem, then the call shouldn't make its way to the called party. But none of this is what happens. So I really don't know where to look, or how to debug this problem. BR, Csaba