Today I checked the new AoIP core network using an old Nokia 1100 handset, which confronted me with codecs.
The Nokia 1100 says it is capable of FR2, FR1, HR1:
Channel Type - (Speech) Element ID: 0x0b Length: 5 0000 .... = Spare bit(s): 0x00 .... 0001 = Speech/Data Indicator: Speech (1) Channel Rate and Type: Full rate TCH channel Bm. Prefer full rate TCH (8) 1... .... = Extension: Additional Octet .001 0001 = Permitted speech version indication: GSM speech full rate version 2 (GSM EFR) (0x11) 1... .... = Extension: Additional Octet .000 0001 = Permitted speech version indication: GSM speech full rate version 1 (GSM FR) (0x01) 0... .... = Extension: Last Octet .000 0101 = Permitted speech version indication: GSM speech half rate version 1 (GSM HR) (0x05)
The "stock" osmo-bsc.cfg I was using so far had only HR3 configured. So I naively thought, let's do:
codec-list hr3 fr2 hr1
But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is that a hard limitation? I'm not at all familiar with the reasons. Will we never be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist?
Then I picked:
codec-list hr3 hr1
That worked, but no audio: the Samsung Galaxy got HR3 and the Nokia HR1 (the BTS was configured for only TCH/F channels, so instead the Nokia actually got assigned an FR1 channel). The call was established but no audio worked. I believe in the OsmoNITB we used to complain in the log that we don't transcode in such a situation, and the call was aborted...
When I pick codec-list hr1 then the call works between the handsets. Again both get assigned FR1 on TCH/F; if I configure the BTS to use TCH/H instead, both indeed get assigned HR1 as expected.
All in all an interesting situation, which appears to mean that we practically can't allow the newer codecs alone because older handsets would not work, and we can't allow both because each side may pick a different one.
Should we wait until we know both sides' codecs and consolidate with each other to pick matching ones before assigning? Is that a "late assignment" as in issue "avoid mismatching TCH/F vs TCH/H pchan types"? https://osmocom.org/issues/1778 But what if no match can be found? only MGW transcoding will solve all situations I guess. Are we planning to do that, also with IuUP in mind? https://osmocom.org/issues/1936 https://osmocom.org/issues/1937
~N
Hi Neels,
On Mon, Jul 17, 2017 at 10:09:27PM +0200, Neels Hofmeyr wrote:
Today I checked the new AoIP core network using an old Nokia 1100 handset, which confronted me with codecs.
what you are observing is the de-facto situation for the NITB for many years. Unfortunately nobody has investigated this thoroughly and implemented a solution.
In classic/commercial GSM networks a call is always transcoded, so basically at the level between MSCs there is PCM audio, and somewhere (typically already at the BSC) the voice is transcoded for each of the two call legs.
There's a convoluted mechanism called "tandem free operation" (TFO) in which the two transcoders can use the LSB of the PCM audio samples to implement a "covert channel" by which they can detect their presence and simultaneously switch both transcoders off. This is to avoid the speech quality degradation that happens by transcoding twice, particularly with HRv1.
None of the above is implemented, as we take a "we don't transcode in OsmoNITB" attitude. The problem (or rather difficulty) with that is that in a mobile-to-mobile call, we don't yet know the least common denominator of the codecs supported by both the MO call leg and the MT call leg until very late (after having paged the subscriber, authenticated him and performed the first couple of CC message exchange). Please note that we actually need to take the codec restrictions of all elements into consideration, i.e. * capabilities of the phone(s) * capabilities of the BTS(s) * capabilities + policy of the BSC(s) * capabilities + policy of the MSC(s)
Where it becomes even more interesting in the new post-NITB world is once we have calls between two subscribers at different MSCs, where the codec capabilities / negotiation will have to be forwarded between them e.g. by means of SIP :)
"It just needs to be implemented" There should be open tickets about this for about a decade now. Sadly it seems nobody has had a significant enough interest or need to actually get it done.
But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is that a hard limitation? I'm not at all familiar with the reasons. Will we never be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist?
I'm not sure why the BSC would ever say something like that. The BSC normally simply picks a codec from the codecs that the MSC permits for the given call. The MSC should be in charge of requesting a specific codec if it wants a specific one.
On Tue, Jul 18, 2017 at 09:48:01AM +0200, Harald Welte wrote:
But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is that a hard limitation? I'm not at all familiar with the reasons. Will we never be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist?
I'm not sure why the BSC would ever say something like that. The BSC normally simply picks a codec from the codecs that the MSC permits for the given call. The MSC should be in charge of requesting a specific codec if it wants a specific one.
Been there since late in 2010: http://git.osmocom.org/openbsc/commit/?id=7bf66c5a6ee085bb84e5f1de12725d7006...
It sounds a bit like this belongs in the MSC instead. So far it's in the BSC config's 'msc' item, i.e. telling the BSC the remote MSC's config.
~N
On Tue, Jul 18, 2017 at 11:58:58AM +0200, Neels Hofmeyr wrote:
On Tue, Jul 18, 2017 at 09:48:01AM +0200, Harald Welte wrote:
But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is that a hard limitation? I'm not at all familiar with the reasons. Will we never be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist?
I'm not sure why the BSC would ever say something like that. The BSC normally simply picks a codec from the codecs that the MSC permits for the given call. The MSC should be in charge of requesting a specific codec if it wants a specific one.
Been there since late in 2010: http://git.osmocom.org/openbsc/commit/?id=7bf66c5a6ee085bb84e5f1de12725d7006...
It sounds a bit like this belongs in the MSC instead. So far it's in the BSC config's 'msc' item, i.e. telling the BSC the remote MSC's config.
I completely understand that there is a point to having a policy that can be configured at the BSC to restrict its supported codecs for whatever local policy/configuration reason. This makes complete sense.
I however don't understand why we should enforce that this policy does not include both a restriction for which codecs to use on TCH/H and also which codecs to use on TCH/F.
Holger, do you remember?
On 18. Jul 2017, at 12:05, Harald Welte laforge@gnumonks.org wrote:
Hey!
I completely understand that there is a point to having a policy that can be configured at the BSC to restrict its supported codecs for whatever local policy/configuration reason. This makes complete sense.
I however don't understand why we should enforce that this policy does not include both a restriction for which codecs to use on TCH/H and also which codecs to use on TCH/F.
It was just the easiest path forward. The customer that paid for the development of the BSC didn't have a mixed TCH/H and TCH/F network, we didn't have much tools to verify these things and it greatly reduced the effort to test it (as I think all untested code is likely to be broken).
Looking at bssmap_handle_assignm_req we would support a mixed hr/fr list right now.
holger
-
Harald Welte -
Holger Freyther -
Neels Hofmeyr