https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-07-21T16:56:56ZOpen Source Mobile CommunicationsOsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=18872016-07-21T16:56:56Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-high2 closed" href="/issues/1776">Feature #1776</a>: Implement fully dynamic TCH/F + TCH/H + PDCH switching</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=18882016-07-21T16:58:23Zneelsnhofmeyr@sysmocom.de
<ul></ul><p><a class="external" href="http://lists.osmocom.org/pipermail/openbsc/2016-July/009538.html">http://lists.osmocom.org/pipermail/openbsc/2016-July/009538.html</a></p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=19012016-07-25T08:23:04Zmsuraev
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-3 priority-high3 closed" href="/issues/1663">Bug #1663</a>: don't connect channels of incompatible voice codec</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=19082016-07-26T13:00:24Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> set to <i>laforge</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Urgent</i></li></ul><p>In the light of one sponsor's desire to have full TCH/F and TCH/H dynamic<br />capabilities and <a class="external" href="https://gerrit.osmocom.org/603">https://gerrit.osmocom.org/603</a> , how urgent would you<br />mark this issue?</p>
<p>(Setting to "Urgent" like <a class="issue tracker-2 status-5 priority-4 priority-high2 closed" title="Feature: Implement fully dynamic TCH/F + TCH/H + PDCH switching (Closed)" href="https://osmocom.org/issues/1776">#1776</a>, pending feedback.)</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=19342016-07-28T14:28:51Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I've taken a look at the chain of actions.<br />Here are some details (with some log messages added that are not in master).</p>
<p>MS 1 exten 46180, IMSI: ..0038<br />MS 2 exten 47828, IMSI: ..0012</p>
<ul>
<li>MS 1: Channel Requested, type = TCH/H<br /><pre>
20160728154822906 DRR <0003> gsm_04_08_utils.c:190 chreq_type_neci1[5] = TCH_H
20160728154822906 DRLL <0000> chan_alloc.c:379 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH as PDCH) Allocating lchan=0 as TCH_H
20160728154823380 DRR <0003> bsc_api.c:502 CLASSMARK CHANGE CM2(len=3) CM3(len=6)
20160728154823777 DRR <0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
20160728154823777 DRR <0003> gsm_04_08.c:1281 MSC: Unimplemented GSM 04.08 RR msg type 0x60
20160728154823979 DRR <0003> bsc_api.c:590 GRPS SUSPEND REQUEST
20160728154824178 DCC <0001> gsm_04_08.c:3600 (bts 0 trx 0 ts 2 ti 8 sub 46180) Received 'SETUP' from MS in state 0 (NULL)
20160728154824178 DCC <0001> gsm_04_08.c:3605 Unknown transaction ID 8, creating new trans.
20160728154824178 DCC <0001> transaction.c:71 subscr=0x80dea0, net=0x7dd210
20160728154824178 DCC <0001> gsm_04_08.c:1323 new state NULL -> INITIATED
20160728154824178 DCC <0001> gsm_04_08.c:2003 Subscriber 901990000000038 (46180) sends SETUP to 47828
20160728154824178 DCC <0001> gsm_04_08.c:1384 (bts 0 trx 0 ts 2 ti 8 sub 46180) Sending 'MNCC_SETUP_IND' to MNCC.
20160728154824178 DMNCC <0006> mncc_builtin.c:346 (call 80000001) Call created.
20160728154824178 DMNCC <0006> mncc_builtin.c:355 (call 80000001) Received message MNCC_SETUP_IND
20160728154824178 DMNCC <0006> mncc_builtin.c:125 (call 80000001) Creating new remote instance 1.
20160728154824178 DMNCC <0006> mncc_builtin.c:134 (call 80000001) Accepting call.
20160728154824178 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_CALL_PROC_REQ (lchan_type 0 NONE)
20160728154824178 DCC <0001> gsm_04_08.c:3507 (bts 0 trx 0 ts 2 ti 08 sub 46180) Received 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED)
20160728154824178 DCC <0001> gsm_04_08.c:1323 new state INITIATED -> MO_CALL_PROC
20160728154824178 DCC <0001> gsm_04_08.c:142 (bts 0 trx 0 ts 2 ti 80) Sending 'CALL_PROC' to MS.
20160728154824178 DMNCC <0006> mncc_builtin.c:142 (call 80000001) Modify channel mode: SPEECH_V1
20160728154824178 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_LCHAN_MODIFY (lchan_type 0 NONE)
20160728154824178 DCC <0001> gsm_04_08.c:3507 (bts 0 trx 0 ts 2 ti 08 sub 46180) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 3 (MO_CALL_PROC)
20160728154824178 DMSC <000a> bsc_api.c:402 Sending ChanModify for speech: SPEECH_V1 on channel TCH_H
20160728154824178 DRR <0003> gsm_04_08_utils.c:502 -> CHANNEL MODE MODIFY mode=0x01
20160728154824178 DMNCC <0006> mncc_builtin.c:150 (call 80000001,lchan 3 TCH_H) Forwarding SETUP to remote.
</pre></li>
</ul>
<ul>
<li>mncc_tx_to_cc receives SETUP REQ with lchan_type still explicitly known.<br /><pre>
20160728154824178 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_SETUP_REQ (lchan_type 3 TCH_H)
20160728154824179 DCC <0001> transaction.c:71 subscr=0x81d3d0, net=0x7dd210
20160728154824179 DCC <0001> gsm_04_08.c:3431 274018000000012 created transaction
20160728154824179 DCC <0001> gsm_04_08.c:3459 274018000000012 paging with rsl_channeed=3
20160728154824179 DPAG <0007> paging.c:291 Start paging of subscriber 19 on bts 0.
20160728154824617 DRR <0003> gsm_04_08_utils.c:527 CHANNEL MODE MODIFY ACK
20160728154824617 DRR <0003> osmo_msc.c:76 MSC assign complete (do nothing).
</pre></li>
</ul>
<ul>
<li>In the paging command going to MS 2, we would always send RSL_CHANNEED_TCH_F,<br /> I changed to RSL_CHANNEED_TCH_ForH, but no effect.<br /> There is no RSL_CHANNEED_TCH_H (TS 08.05 9.3.40)<br /><pre>
20160728154824679 DPAG <0007> paging.c:83 Going to send paging commands: imsi: '274018000000012' tmsi: '0xbb01b012'
20160728154825179 DPAG <0007> paging.c:83 Going to send paging commands: imsi: '274018000000012' tmsi: '0xbb01b012'
</pre></li>
</ul>
<ul>
<li>MS 2 answers with Channel Requested, as TCH/F type [1]<br /><pre>
20160728154825280 DRR <0003> gsm_04_08_utils.c:190 chreq_type_neci1[11] = TCH_F
</pre></li>
</ul>
<ul>
<li>lchan_alloc() allocates a TCH/F [2]<br /><pre>
20160728154825280 DRLL <0000> chan_alloc.c:379 (bts=0,trx=0,ts=3,pchan=TCH/F_TCH/H_PDCH as PDCH) Allocating lchan=0 as TCH_F
20160728154825484 DRR <0003> gsm_04_08.c:1216 PAGING RESPONSE: MI(TMSI)=3137450002
20160728154825484 DRR <0003> gsm_04_08.c:1236 <- Channel was requested by 274018000000012
20160728154825489 DPAG <0007> paging.c:379 Stop paging on bts 0, calling cbfn.
20160728154825489 DCC <0001> gsm_04_08.c:1454 Paging subscr 47828 succeeded!
20160728154825489 DCC <0001> gsm_04_08.c:1925 starting timer T303 with 30 seconds
20160728154825489 DCC <0001> gsm_04_08.c:1323 new state NULL -> CALL_PRESENT
20160728154825489 DCC <0001> gsm_04_08.c:142 (bts 0 trx 0 ts 3 ti 00) Sending 'SETUP' to MS.
20160728154825623 DRR <0003> bsc_api.c:502 CLASSMARK CHANGE CM2(len=3) CM3(len=11)
20160728154826182 DRR <0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
20160728154826182 DRR <0003> gsm_04_08.c:1281 MSC: Unimplemented GSM 04.08 RR msg type 0x60
20160728154826325 DRR <0003> bsc_api.c:590 GRPS SUSPEND REQUEST
20160728154826463 DCC <0001> gsm_04_08.c:3600 (bts 0 trx 0 ts 3 ti 0 sub 47828) Received 'CALL_CONF' from MS in state 6 (CALL_PRESENT)
20160728154826463 DCC <0001> gsm_04_08.c:1364 stopping pending timer T303
20160728154826463 DCC <0001> gsm_04_08.c:1925 starting timer T310 with 180 seconds
20160728154826463 DCC <0001> gsm_04_08.c:1323 new state CALL_PRESENT -> MO_TERM_CALL_CONF
20160728154826463 DCC <0001> gsm_04_08.c:1384 (bts 0 trx 0 ts 3 ti 0 sub 47828) Sending 'MNCC_CALL_CONF_IND' to MNCC.
20160728154826463 DMNCC <0006> mncc_builtin.c:355 (call 1) Received message MNCC_CALL_CONF_IND
20160728154826463 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_LCHAN_MODIFY (lchan_type 2 TCH_F)
20160728154826463 DCC <0001> gsm_04_08.c:3507 (bts 0 trx 0 ts 3 ti 00 sub 47828) Received 'MNCC_LCHAN_MODIFY' from MNCC in state 9 (MO_TERM_CALL_CONF)
20160728154826463 DMSC <000a> bsc_api.c:402 Sending ChanModify for speech: SPEECH_V1 on channel TCH_F
20160728154826463 DRR <0003> gsm_04_08_utils.c:502 -> CHANNEL MODE MODIFY mode=0x01
20160728154826644 DRR <0003> gsm_04_08_utils.c:527 CHANNEL MODE MODIFY ACK
20160728154826644 DRR <0003> osmo_msc.c:76 MSC assign complete (do nothing).
20160728154826781 DCC <0001> gsm_04_08.c:3600 (bts 0 trx 0 ts 3 ti 0 sub 47828) Received 'ALERTING' from MS in state 9 (MO_TERM_CALL_CONF)
20160728154826781 DCC <0001> gsm_04_08.c:1364 stopping pending timer T310
20160728154826781 DCC <0001> gsm_04_08.c:1925 starting timer T301 with 180 seconds
20160728154826781 DCC <0001> gsm_04_08.c:1323 new state MO_TERM_CALL_CONF -> CALL_RECEIVED
20160728154826781 DCC <0001> gsm_04_08.c:1384 (bts 0 trx 0 ts 3 ti 0 sub 47828) Sending 'MNCC_ALERT_IND' to MNCC.
20160728154826781 DMNCC <0006> mncc_builtin.c:355 (call 1) Received message MNCC_ALERT_IND
20160728154826781 DMNCC <0006> mncc_builtin.c:168 (call 1) Forwarding ALERT to remote.
20160728154826781 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_ALERT_REQ (lchan_type 0 NONE)
20160728154826781 DCC <0001> gsm_04_08.c:3507 (bts 0 trx 0 ts 2 ti 08 sub 46180) Received 'MNCC_ALERT_REQ' from MNCC in state 3 (MO_CALL_PROC)
20160728154826781 DCC <0001> gsm_04_08.c:1323 new state MO_CALL_PROC -> CALL_DELIVERED
20160728154826781 DCC <0001> gsm_04_08.c:142 (bts 0 trx 0 ts 2 ti 80) Sending 'ALERTING' to MS.
20160728154829403 DCC <0001> gsm_04_08.c:3600 (bts 0 trx 0 ts 3 ti 0 sub 47828) Received 'CONNECT' from MS in state 7 (CALL_RECEIVED)
20160728154829403 DCC <0001> gsm_04_08.c:1364 stopping pending timer T301
20160728154829403 DCC <0001> gsm_04_08.c:1323 new state CALL_RECEIVED -> CONNECT_REQUEST
20160728154829403 DCC <0001> gsm_04_08.c:1384 (bts 0 trx 0 ts 3 ti 0 sub 47828) Sending 'MNCC_SETUP_CNF' to MNCC.
20160728154829403 DMNCC <0006> mncc_builtin.c:355 (call 1) Received message MNCC_SETUP_CNF
20160728154829403 DMNCC <0006> mncc_builtin.c:196 (call 1) Acknowledge SETUP.
20160728154829403 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_SETUP_COMPL_REQ (lchan_type 0 NONE)
20160728154829403 DCC <0001> gsm_04_08.c:3507 (bts 0 trx 0 ts 3 ti 00 sub 47828) Received 'MNCC_SETUP_COMPL_REQ' from MNCC in state 8 (CONNECT_REQUEST)
20160728154829403 DCC <0001> gsm_04_08.c:1323 new state CONNECT_REQUEST -> ACTIVE
20160728154829403 DCC <0001> gsm_04_08.c:142 (bts 0 trx 0 ts 3 ti 00) Sending 'CONNECT_ACK' to MS.
20160728154829403 DMNCC <0006> mncc_builtin.c:203 (call 1) Sending CONNECT to remote.
20160728154829403 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_SETUP_RSP (lchan_type 0 NONE)
20160728154829403 DCC <0001> gsm_04_08.c:3507 (bts 0 trx 0 ts 2 ti 08 sub 46180) Received 'MNCC_SETUP_RSP' from MNCC in state 4 (CALL_DELIVERED)
20160728154829403 DCC <0001> gsm_04_08.c:1925 starting timer T313 with 30 seconds
20160728154829403 DCC <0001> gsm_04_08.c:1323 new state CALL_DELIVERED -> CONNECT_IND
20160728154829403 DCC <0001> gsm_04_08.c:142 (bts 0 trx 0 ts 2 ti 80) Sending 'CONNECT' to MS.
20160728154829403 DMNCC <0006> mncc_builtin.c:209 (call 1) Bridging with remote.
20160728154829403 DMNCC <0006> gsm_04_08.c:3290 receive message MNCC_BRIDGE (lchan_type 0 NONE)
</pre></li>
</ul>
<ul>
<li>bridge is completed, but pchans mismatch<br /><pre>
20160728154829403 DCC <0001> gsm_04_08.c:1638 Setting up TCH map between (bts=0,trx=0,ts=3,TCH_F) and (bts=0,trx=0,ts=2,TCH_H)
20160728154829403 DCC <0001> gsm_04_08.c:1649 Cannot patch through call with different channel types: local = TCH_F, remote = TCH_H
</pre></li>
</ul>
<p>how to solve?</p>
<p>It would be nice to see a Channel Requested from MS 2 coming in as TCH/H already, at [1].<br />Q: Who decides for TCH/F there? Is osmo-bts somehow telling the MS to do TCH/F?</p>
<p>Even though a TCH/F request has come in, lchan_alloc() could still decide to allocate TCH/H anyway at [2].<br />Q: can rsl_rx_chan_rqd() in abis_rsl.c feasibly find out the transaction the channel is requested for?<br />Then we could look up the first channel's lchan type and ask lchan_alloc() for the same.<br /><pre>
static int rsl_rx_chan_rqd(struct msgb *msg)
{
[...]
trans = trans_find_by_callref(bts->network, callref);
if (!trans)
return -EIO;
if (!trans->conn)
return 0;
</pre><br />So, can we find out the callref in rsl_rx_chan_rqd()?</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=19352016-07-28T14:32:52Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>It would be nice to see a Channel Requested from MS 2 coming in as TCH/H already, at [1].<br />Q: Who decides for TCH/F there? Is osmo-bts somehow telling the MS to do TCH/F?</p>
</blockquote>
<p>It does not seem to be the MS choosing TCH/F, because it's the same if I swap the phones<br />from caller to callee: The caller always picks TCH/H, and the callee then responds to the<br />paging with TCH/F.</p>
<p>So it's not like the Sony phone simply prefers TCH/F. The Samsung replies to the paging<br />with TCH/F just the same.</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=19492016-07-28T15:54:44Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>workaround that disables TCH/F for dyn TS in <a class="external" href="https://gerrit.osmocom.org/603">https://gerrit.osmocom.org/603</a></p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=19602016-07-29T17:27:55Zlaforge
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>New</i></li><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>4368</i></li><li><strong>Priority</strong> changed from <i>Urgent</i> to <i>Normal</i></li></ul><p>The work-around is ok for now, but let's leave the ticket open until we have a proper fix. Probably after the BSC/MSC split.</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=22402016-10-14T11:36:19Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Stalled</i></li></ul><p>Status update:</p>
<ul>
<li>GSM 04.08 Version 5.3.0, 10.5.2.8 "Channel Needed" (page 318)<br />It is not possible to ask the mobile specifically for a TCH_H or a TCH_F, We can ask for TCH_F explicitly, but not for TCH_H. Here we can only ask for "TCH_F or TCH_H". Apart from that the channel needed flag is only a "recomendation" to the mobile. The mobile may ask for a different channel than it was asked for</li>
</ul>
<ul>
<li>Experiment:<br />It is possible to allocate an arbitrary channel type to the mobile, this means we can freely choose between TCH_H and TCH_F during the channel assignment. I checked this with an experiment and it works. However, it is not possible to recognize the mobile when the rach request occours. So we do not know early enough which mobile is requesting the channel, so we can not assign the right channel type.</li>
</ul>
<ul>
<li>Possible solution:<br />It may be possible to solve the problem by assigning a new traffic channel when we detect that the channel types to not match up. This means the problem is more difficult than I thought. It is probably not that easy to assign a new channel and close the old one. This probably requires the implementation of a state machine.</li>
</ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=23392016-11-03T13:32:25Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>dexter wrote:</p>
<blockquote>
<ul>
<li>Possible solution:<br />It may be possible to solve the problem by assigning a new traffic channel when we detect that the channel types to not match up. This means the problem is more difficult than I thought. It is probably not that easy to assign a new channel and close the old one. This probably requires the implementation of a state machine.</li>
</ul>
</blockquote>
<p>'handover' could be the right keyword here.</p>
<p>In openbsc branch neels/dyn_pdch_defrag there are some patches from jolly that use handover<br />to defragment lchan usage within the same BTS. Possibly a similar mechanism could be<br />used to change TCH/F to TCH/H?</p>
<p><a class="external" href="https://git.osmocom.org/openbsc/log/?h=neels/dyn_pdch_defrag">https://git.osmocom.org/openbsc/log/?h=neels/dyn_pdch_defrag</a><br />originally: <a class="external" href="https://git.osmocom.org/openbsc/log/?h=jolly/dyn_pdch">https://git.osmocom.org/openbsc/log/?h=jolly/dyn_pdch</a></p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=23502016-11-05T18:29:35Zlaforge
<ul></ul><p>On Thu, Nov 03, 2016 at 01:32:25PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>'handover' could be the right keyword here.</p>
</blockquote>
<p>It is simply a 'late assignment', one of the most normal procedures in<br />every GSM network: Phone sends RACH, networka assigns SDCCH (to save<br />bandwidth/resources), phone sends SETUP, network then check if the<br />callee is available. If it is, network ASSIGNS (not IMM. ASSIGN!) the<br />TCH/F or TCH/H channel. We already do late assignment in OsmoBSC,<br />AFAIK. It is only OsmoNITB which for historical reasons is still doing<br />very early assignment (immediate TCH/F or TCH/H assignment in response<br />to RACH).</p>
<p>-- <br />- Harald Welte <<a class="email" href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a class="external" href="http://laforge.gnumonks.org/">http://laforge.gnumonks.org/</a>
============================================================================<br />"Privacy in residential applications is a desirable marketing option." <br />(ETSI EN 300 175-7 Ch. A6)</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=24602016-11-15T01:41:00Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>For the record: We have this workaround in place to disable use of TCH/F in<br />osmo-nitb only: <a class="external" href="https://gerrit.osmocom.org/603">https://gerrit.osmocom.org/603</a> . It is planned to add a config<br />item to leave the choice up to the user. Due to implementation details, I'm waiting <br />for <a class="external" href="https://gerrit.osmocom.org/1140">https://gerrit.osmocom.org/1140</a> before adding the config item -- until then <br />one could patch the nitb code and set 'bsc_gsmnet->dyn_ts_allow_tch_f = true;'<br />near line 313 of openbsc/src/osmo-nitb/bsc_hack.c. This would of course almost<br />certainly cause this issue to re-appear.</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=25692016-12-07T13:27:07Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>gerrit patch 1140 is now merged to master, so we could now add a VTY config for<br />osmo-nitb to allow/disallow TCH/F on dynamic TCH/F_TCH/H_PDCH timeslots.<br />(My attention is with the VLR though.)</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=31932017-02-28T17:59:31Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>neels</i></li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=41912017-05-31T08:53:21Zmsuraev
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-2 priority-default closed" href="/issues/1865">Bug #1865</a>: TCH/F_PDCH is not working as TCH/F channel for CS voice call in USRP B210 board ( osmo-trx)</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=41942017-05-31T08:57:26Zmsuraev
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/1853">Bug #1853</a>: validate dynamic TCH/PDCH support in osmo-bts-trx</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=42012017-05-31T10:09:07Zmsuraev
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/1853">Bug #1853</a>: validate dynamic TCH/PDCH support in osmo-bts-trx</i>)</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=42022017-05-31T10:09:08Zmsuraev
<ul><li><strong>Blocks</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/1853">Bug #1853</a>: validate dynamic TCH/PDCH support in osmo-bts-trx</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=56382017-10-09T14:45:51Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-2 priority-default closed" href="/issues/1971">Bug #1971</a>: TCH/F_TCH/H_PDCH: BSC doesn't allocate TCH/F</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=56392017-10-09T14:49:34Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li><li><strong>% Done</strong> changed from <i>100</i> to <i>0</i></li></ul><p>having <a class="issue tracker-1 status-6 priority-2 priority-default closed" title="Bug: TCH/F_TCH/H_PDCH: BSC doesn't allocate TCH/F (Rejected)" href="https://osmocom.org/issues/1971">#1971</a> as subtask and resolving that despite nothing being fixed made this %-done jump to 100 in error. Go back to 0.</p>
<p>Note that in the new split way, separate MSC and BSC talking via SCCP/M3UA, RTP will be routed via the new osmo-mgw, and the plan is to resolve any codec mismatches via transcoding there. Hence, we will most probably not spend any effort on fixing such situations for OsmoNITB.</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=63652017-11-27T14:59:09Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/1606">Feature #1606</a>: hand-over for load distribution among BTSs</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=63672017-11-27T14:59:19Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-3 priority-high3 closed" href="/issues/1608">Feature #1608</a>: various handover improvements, meta-issue</i> added</li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=63692017-11-27T15:02:35Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>the handover code I'm looking at now could provide a solution to this too, it has a Late Assignment mechanism. Remains to be seen whether we have a sane way to tell the BSC that the other call leg is of a different codec ... so actually the transcoding in MGW would be the most general solution.</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=63802017-11-27T19:42:00Zlaforge
<ul></ul><p>On Mon, Nov 27, 2017 at 03:02:35PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>the handover code I'm looking at now could provide a solution to this<br />too, it has a Late Assignment mechanism. Remains to be seen whether we<br />have a sane way to tell the BSC that the other call leg is of a<br />different codec ...</p>
</blockquote>
<p>I think the MSC can send at any time during a call a new "ASSIGNMENT<br />COMMAND" over the A interface, and that can contain different channel<br />type / codec information than the previous channel.</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=66752017-12-10T20:01:24Zlaforge
<ul><li><strong>Project</strong> changed from <i>OpenBSC</i> to <i>OsmoMSC</i></li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=69512017-12-23T17:49:18Zlaforge
<ul><li><strong>Category</strong> set to <i>A interface (general)</i></li></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=111192018-09-03T17:21:18Zlaforge
<ul></ul><p>ping? Is this now solved after the extenal handover code was merged?</p> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=111202018-09-03T17:21:41Zlaforge
<ul></ul> OsmoMSC - Feature #1778: avoid mismatching TCH/F vs TCH/H pchan typeshttps://osmocom.org/issues/1778?journal_id=113042018-09-12T14:12:02Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>Hey, what? I already answered to this one a week ago. Somehow must have forgotten to click "Submit"...</p>
<p>The root reason why we ran into mismatching channel types was that we did not do late assignment:</p>
<ul>
<li>phone sends a Channel Request for a TCH/F channel</li>
<li>we used to accept that and assign a TCH/F</li>
<li>call gets established, second call leg answers to paging</li>
<li>second call leg gets assigned a voice channel according to codec choices, likely ending up as TCH/H</li>
<li>mismatch.</li>
</ul>
<p>Since we do late assignment, we always assign an SDCCH first.<br />We also more accurately select a voice type by the MSC, BSC and MS supported codec types.<br />So we will pick our own most desired channel type instead of sticking with the initial Immediate Assignment one.<br />Also, <strong>if</strong> we did end up assigning a TCH/* for initial Channel Request and its chan mode mismatches the one we picked, we will assign a different channel now.</p>
<p>It is still possible to end up with mismatching channel types,<br />thinking: one MS has no TCH/H capability thus gets TCH/F, and the core net config prefers TCH/H so the second phone gets TCH/H,<br />but this is far less likely than it used to be.</p>
<p>Bottom line is, we need transcoding to deal with all of the above issues,<br />and for now we're doing the best we can to avoid mismatches in osmo-bsc.git.</p>
<p>Note: old osmo-nitb still has this problem, since it doesn't do late assignment.</p>