[PATCH 1/4] Each BTS can be configured for speech support (other than GSM full rate)

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

Labs rp.labs at gmx.ch
Mon Jan 13 00:34:26 UTC 2014


Hello,

On 01/09/2014 11:13 AM, Andreas Eversberg wrote:
> my question is: how does the MSC in a real network knows what codecs are
> supported by BTS, so it can skip unsupported codecs when negotiating
> with the other end?
>

My understanding is that the BTS is not involved at all in this 
negotiation. Only MS, BSC and MSC. BTS just passes the messages between 
MS and BSC.

In the initial call setup procedure the MS is sending to MSC the 
supported codecs list. Information is sent in an L3 DTAP message through 
BSC but BSC is not involved this time. MSC is building after that a list 
of supported codecs by both ends and is sending the list to the BSC. If 
the codec chosen by BSC is supported by both ends than you have a 
transcoder free operation. All elements involved needs to support TrFO 
to work. More in 23.153 and 45.009.

In case of A over TDM you can not have TrFO working, just for A over IP.

I looked over the code (I'm not a programmer) and I cannot see where you 
specify the bit rate for AMR codec. In 45.009 3.4.3 you can check the 
rules for initial codec mode and cases when the bit rate can change.

In real networks I saw most of the time AMR used and I also saw same 
BSCs overwriting the ICM by selecting the highest bitrate when message 
is sent through Abis interface to MS. Normal behavior is to follow the 
rules in 3.4.3.

In TrFO the bitrate will not be signalled by MSC in L3 messages (this 
function is not even implemented from what I saw) because there are 
cases when MSC is not involved like intra-BSC handover with a local MS.

I hope I wrote everything correctly.

Regards,
R.




More information about the OpenBSC mailing list