https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-09-04T17:39:13ZOpen Source Mobile Communicationsosmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=111382018-09-04T17:39:13Zfixeria
<ul></ul><p>It would be great to have some protocol traces (*.pcap) and some logs of the other MNCC side (i.e. OsmoMSC or OpenBSC) attached.</p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=111622018-09-06T07:28:31Zkeith
<ul></ul><p>Hi Vadim!</p>
<p>Yes. traces, of course would be useful. <br />[EDIT: On seconds thoughts, possibly not so useful, at least not for anyone familiar with what's happening on the other side of the MNCC socket (nitb/msc) ]</p>
<p>Unfortunately, I have to divert attention to something else right now, but rather than let the noted issue leak out of my (grey-matter) memory I made this note of the problem.</p>
<p>Seeing as how (as I said), it is 100% reproducible, maybe somebody else might get around to adding said trace. ;-)</p>
<p>That said, I have a sneaky feeling that the problem is <em>probably</em> visible even with static analysis.</p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=118342018-10-02T11:25:32Zkeith
<ul></ul><p>Static Analysis:</p>
<p>It appears we are getting MNCC_RTP_CREATE after MNCC_DISC_IND (this was observed with osmo-nitb)</p>
<p>On receipt of MNCC_RTP_CREATE, check_rtp_create() calls stop_cmd_timer() which complains and returns, and then we go ahead with continue_call() anyway, ultimateley resulting in the setup of the B-leg, even though the A leg is gone.</p>
<p>So we need to check someplace for the continuing validity of the A-leg.</p>
<p>Also this would appear to reveal a bug on the MSC side, in that somehow we are getting this MNCC_RTP_CREATE from the MNCC socket (in this case, I repeat, osmo-nitb) <strong>after</strong> we got the MNCC_DISC_IND.</p>
<p>Note to self: Maybe that's because we didn't send back some response to MNCC_DISC_IND yet?</p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=118542018-10-02T15:37:43Zlaforge
<ul></ul> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=128492018-12-06T10:49:07Zkeith
<ul></ul><p>Adding link to possible workaround patch here:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-sip-connector/+/11194/">https://gerrit.osmocom.org/#/c/osmo-sip-connector/+/11194/</a></p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=140572019-04-18T21:52:04Zrafael2k
<ul></ul><p>keith wrote:</p>
<blockquote>
<p>Adding link to possible workaround patch here:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-sip-connector/+/11194/">https://gerrit.osmocom.org/#/c/osmo-sip-connector/+/11194/</a></p>
</blockquote>
<p>Another possible fix here, in libmsc:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/openbsc/+/13703/">https://gerrit.osmocom.org/#/c/openbsc/+/13703/</a></p>
<p>ps: I plan to do the same with osmo-msc's libmsc.</p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=140582019-04-19T06:40:10Zlaforge
<ul></ul><p>Can we please have a regression test case in SIP_Tests.ttcn which reproduces<br />the problem? It should be as simple as to send three messages to MNCC, right?</p>
<p>This way we can avoid the problem from ever re-appearing again.</p>
<p>I do believe that the fix in osmo-sip-connector published in<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-sip-connector/+/11194/">https://gerrit.osmocom.org/#/c/osmo-sip-connector/+/11194/</a><br />is correct. There's no use of accepting any other commands for a given call<br />after we received a DISC_IND.</p>
<p>Having said this, it's of course also wrong for the MSC/NITB to send such messages<br />in the first place. The use of proper state machines should prevent something like<br />that, and I wonder if neels/ho (which introduces lots more osmo_fsm into the MSC)<br />already adresses this "by accident"</p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=140592019-04-19T07:41:22Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>Testcase is now in <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13705">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13705</a></p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=141182019-04-24T08:39:07Zkeith
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>60</i></li></ul><p>Patch to osmo-sip-connector to deal with the case is now merged. Lingering B leg not possible anymore.</p>
<p>@rafael2k's patch to legacy openbsc is also merged, so nitb should no longer cause this error (might be nice for anybody still running nitb/lcr)</p>
<p>TODO: Verify if the osmo-msc still exhibits this behaviour, now that the code there hardly resembles legacy libmsc.</p> osmo-sip-connector - Bug #3518: Rapid SETUP followed DISC results in lingering B-leghttps://osmocom.org/issues/3518?journal_id=228952021-11-04T18:25:56Zkeith
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul><p>Closing as too old.</p>