https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-12-16T12:04:33ZOpen Source Mobile CommunicationsOsmoBSC - Bug #2763: OsmoBSC refuses configuration with both FR and HR codecshttps://osmocom.org/issues/2763?journal_id=68392017-12-16T12:04:33Zzecke
<ul></ul><p>There is no limit from the GSM specification point of view. When I implemented osmo-bsc there was no budget/time to make the end-to-chain work with mixed codecs. To reduce possibilities of creating configs that are reasonable but would not work, I tried to reject a mixed mode.</p>
<p>Full mixed mode would probably need to take used resources into account, classmarks of the device. E.g. when on a SDCCH.. go to fullrate or halfrate? Make it depend on load? Maybe another dynpdch mode to go from TCH/F to TCH/H on load. Luckily the first step is (almost)/was taken to have MGCP GW and BSC communicate with each other.</p> OsmoBSC - Bug #2763: OsmoBSC refuses configuration with both FR and HR codecshttps://osmocom.org/issues/2763?journal_id=68442017-12-17T13:10:11Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I also noticed/hit this before. AFAICT the only restriction is the VTY configuration condition preventing multiple codecs. I think in the osmo-nitb we even allowed that already; at least I remember that I managed to get mixed calls (one HR and one FR trying to talk to each other) which I guess will only work with both codecs allowed. The lchan_alloc function is quite adept at picking lchans of various types, and OsmoBSC uses the same one OsmoNITB had.</p>
<p>So I think we should just lift the restriction in the VTY and test it, chances are it will just work.</p>
<p>The restriction is in 'codec-list .LIST' in osmo-bsc/src/osmo-bsc/osmo_bsc_vty.c,<br />it is the setting for bsc_msc_data->audio_support.</p>
<pre>
if (saw_hr && saw_fr) {
vty_out(vty, "Can not have full-rate and half-rate codec.%s",
VTY_NEWLINE);
return CMD_ERR_INCOMPLETE;
}
</pre>
<p>I note in bsc_vty.c, there is a different set of commands to set bts->codec:</p>
<pre>
codec-support fr (hr|efr|amr) (hr|efr|amr) (hr|efr|amr) (hr|efr|amr)
</pre>
<p>I'm not entirely familiar with the semantic differences between the two. Looks like one says what codecs the BTS supports and what codecs the MSC allows? So why would the BSC want to limit the codecs that the MSC supports?</p>
<p>Loosely related: the load based handover that's in the pipeline does some advanced lchan picking, choosing TCH/F or TCH/H depending on config preferences.</p> OsmoBSC - Bug #2763: OsmoBSC refuses configuration with both FR and HR codecshttps://osmocom.org/issues/2763?journal_id=68452017-12-17T14:00:14Zlaforge
<ul></ul><p>Hi Neels,</p>
<p>On Sun, Dec 17, 2017 at 01:10:11PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>So I think we should just lift the restriction in the VTY and test it, chances are it will just work.</p>
</blockquote>
<p>ok, I cold help with some automatic test cases, at least to ensure that<br />the signalling on the A and Abis side are consistent for each of the<br />supported/enabled codecs.</p>
<blockquote>
<p>I note in bsc_vty.c, there is a different set of commands to set bts->codec:</p>
<pre>
> codec-support fr (hr|efr|amr) (hr|efr|amr) (hr|efr|amr) (hr|efr|amr)
> </pre>
<p>I'm not entirely familiar with the semantic differences between the<br />two. Looks like one says what codecs the BTS supports and what codecs<br />the MSC allows?</p>
</blockquote>
<p>The per-BTS configuration is mainly due to the fact that we don't have<br />extensive compiled-in tables for different BTS models. Even for<br />OsmoBTS, we still are not signalling codec capabilities over A-bis OML<br />in a way that would allow the BSC to automatically pick up which codecs<br />are suppored by a given BTS. So here we are normally configuring the<br />actual capabilities of the BTS hardware used.</p>
<p>On the BSC side, the codec configuration is mostly about policy. It<br /><strong>could</strong> also be a restriction of what the media gateway (which may not<br />always have to be osmo-mgw) supports.</p>
<blockquote>
<p>So why would the BSC want to limit the codecs that the MSC supports?</p>
</blockquote>
<ul>
<li>only the BSC knows its MGW (or is supposed to know) and its<br />capabilities</li>
<li>only the BSC knows the details of the A-bis transport, which may be<br />RTP or E1/T1 based</li>
</ul>
<p>What I find a bit odd is the different syntax between the codec-support<br />on the per-BTS level. It's odd that on the BTS side we call it<br />hr/efr/amr, while on the BSC/MSC level we call it hr1/fr2/...</p>
<p>This syntax should probably be unified to avoid confusion</p> OsmoBSC - Bug #2763: OsmoBSC refuses configuration with both FR and HR codecshttps://osmocom.org/issues/2763?journal_id=70292018-01-04T10:58:37Zlaforge
<ul><li><strong>Due date</strong> set to <i>01/05/2018</i></li><li><strong>Start date</strong> changed from <i>12/15/2017</i> to <i>01/05/2018</i></li><li><strong>Follows</strong> <i><a class="issue tracker-2 status-3 priority-4 priority-high2 closed" href="/issues/2817">Feature #2817</a>: extend TTCN-3 test with testing of each different voice codec</i> added</li></ul> OsmoBSC - Bug #2763: OsmoBSC refuses configuration with both FR and HR codecshttps://osmocom.org/issues/2763?journal_id=85522018-03-27T13:45:52Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>this is meanwhile fully supported, and we have TTCN-3 tests to verify assignment with all 5 codec types.</p>