https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-08-28T18:05:15ZOpen Source Mobile CommunicationsOsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=110402018-08-28T18:05:15Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Seeing issues like <a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: allow shorter Connection Identifier 'I:' (Resolved)" href="https://osmocom.org/issues/3507">#3507</a> and <a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: compare Connection Identifier 'I:' case insensitively (Resolved)" href="https://osmocom.org/issues/3508">#3508</a>, where an MGCP client fails to clean up its own endpoint connections due to Connection Identifier mismatches (due to size limits or case insensitivity) makes me return to this issue. I see this as an important sanity feature, especially when the osmo-mgw is a long running entity serving various clients. At first this was only about clients failing to send DLCX messages, but also seeing us failing to accept DLCX that weren't forgotten at all makes me think that it is rather important that we magically clean up unused endpoint connections.</p>
<p>If endpoints that failed to be cleaned pile up, it will eventually exhaust all of the ports or the permitted number of endpoints, besides leaving unused state in osmo-mgw's memory.</p>
<p>I still think something like one minute of neither RTP nor MGCP messages received for a given endpoint connection is a sane limit to discard a connection automatically.<br />To be very conservative, I guess three minutes of permitted inactivity could be a good default configuration.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=110412018-08-28T18:05:27Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/3507">Feature #3507</a>: allow shorter Connection Identifier 'I:'</i> added</li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=110432018-08-28T18:05:33Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/3508">Feature #3508</a>: compare Connection Identifier 'I:' case insensitively</i> added</li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=110452018-08-28T18:17:49Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>RFC3435<br /><pre>
2.1.3.2 Names of Connections
Connection identifiers are created by the gateway when it is
requested to create a connection. They identify the connection
within the context of an endpoint. Connection identifiers are
treated in MGCP as hexadecimal strings. The gateway MUST make sure
that a proper waiting period, at least 3 minutes, elapses between the
end of a connection that used this identifier and its use in a new
connection for the same endpoint (gateways MAY decide to use
identifiers that are unique within the context of the gateway). The
maximum length of a connection identifier is 32 characters.
</pre></p>
<p>Hah, I did say 3 minutes, didn't I, even though for a slightly different aim.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=110532018-08-29T00:11:25Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/3509">Feature #3509</a>: match MGCP "I:" Connection ID also when leading zeros are omitted</i> added</li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=126512018-11-22T11:04:11Zlaforge
<ul><li><strong>Assignee</strong> set to <i>osmith</i></li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=131092019-01-22T15:00:29Zosmith
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=131202019-01-24T10:26:57Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/3655">Feature #3655</a>: Introduce self-destruction timer for SS/USSD connections</i> added</li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=131802019-01-29T15:30:51Zosmith
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>20</i></li></ul><p>Status update:</p>
<p>One osmo-mgw can have multiple endpoints (mgcp_endpoint), and each endpoint can have multiple connections (mgcp_conn, always RTP at this point, possibly other protocols in the future).</p>
<p>So far I've implemented a watchdog for mgcp_conn. Next up is implementing another watchdog for mgcp_endpoint.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=131882019-01-31T09:32:28Zmsuraev
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-7 priority-3 priority-high3" href="/issues/3659">Feature #3659</a>: handover during LCLS directly between BTSs</i> added</li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=131902019-01-31T09:34:24Zmsuraev
<ul></ul><p>While implementing this we've got to make sure it doesn't break BTS-variant of LCLS.<br />I'm not sure if we can determine LCLS status in MGW so this should be optional feature off by default which can be enabled via vty with corresponding notice regarding LCLS incompatibility.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=131912019-01-31T16:27:18Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Hm, I didn't consider LCLS keeping inactive endpoints open for a long period of time.<br />Keeping unused endpoints open is still a bit of a problem, we need some sort of sanity there in the MGW.</p>
<p><a class="user active" href="https://osmocom.org/users/119">msuraev</a> <a class="user active" href="https://osmocom.org/users/7">laforge</a> Can LCLS tear down unused MGW endpoints, i.e., on breaking LCLS, can it re-create endpoints and transmit a new RTP port?</p>
<p>We could also tell the MGW that the endpoint is still in use by sending no-op MDCX to the MGW once a minute;<br />or investigate for some other keep-alive message in MGCP.</p>
<p><a class="user active" href="https://osmocom.org/users/301771">osmith</a> btw, for me, having the inter-MSC GSUP messages is more urgent that this feature.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=132002019-01-31T18:10:07Zlaforge
<ul></ul><p>On Thu, Jan 31, 2019 at 04:27:19PM +0000, <a class="email" href="mailto:redmine@lists.osmocom.org">redmine@lists.osmocom.org</a> wrote:</p>
<blockquote>
<p><a class="user active" href="https://osmocom.org/users/119">msuraev</a> <a class="user active" href="https://osmocom.org/users/7">laforge</a> Can LCLS tear down unused MGW endpoints, i.e., on breaking LCLS, can it re-create endpoints and transmit a new RTP port?</p>
</blockquote>
<p>in theory one could write the LCLS code to do that, but of course it comes at a lot of extra<br />complexity.</p>
<p>The "easy" solution would be ..</p>
<blockquote>
<p>We could also tell the MGW that the endpoint is still in use by sending no-op MDCX to the MGW once a minute;<br />or investigate for some other keep-alive message in MGCP.</p>
</blockquote>
<p>exactly my thinking. The guard timer of the MGCP connect (not endpoint,<br />right?) would be re-freshed not only by RTP but by any MGCP message<br />related to that connection.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=132012019-01-31T18:20:20Zlaforge
<ul></ul><p>Also, LCLS explicitly defines that the media path/plane remains active but is simply not<br />used until LCLS instructs any of the network elements to do otherwise.</p>
<p>So definitely, all resources/ports/etc. should be allocated so that with no additional<br />latency in response to only a single LCLS message the media can be re-activated.</p>
<p>Also, keep in mind that there are LCLS configurations that support "locally switched<br />call until a RTP packet arrives again from the core netowrk" at which point the <br />local RTP will be dropped in favor of the RTP from the core.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=132182019-02-01T09:34:25Zosmith
<ul><li><strong>% Done</strong> changed from <i>20</i> to <i>90</i></li></ul><p>I had already created a patch, but forgot to post it here and update the status:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-mgw/+/12730/">https://gerrit.osmocom.org/#/c/osmo-mgw/+/12730/</a></p>
<p>In the current state, this patch disables the timeout by default and notes that it should not be enabled together with LCLS in the VTY config.</p>
<blockquote>
<p>The guard timer of the MGCP connect (not endpoint, right?) would be re-freshed not only by RTP but by any MGCP message related to that connection.</p>
</blockquote>
<p>It is already implemented like this in the patch, receiving MDCX will update the guard timer too.</p>
<blockquote>
<p>We could also tell the MGW that the endpoint is still in use by sending no-op MDCX to the MGW once a minute;<br />or investigate for some other keep-alive message in MGCP.</p>
</blockquote>
<p>Sounds like a good solution to me, how about I create a new issue for that?</p>
<p>I think this issue is done when the patch gets its second +1.</p> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=132492019-02-06T12:49:50Zosmith
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/3783">Feature #3783</a>: Make conn-timeout compatible with LCLS</i> added</li></ul> OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?https://osmocom.org/issues/3429?journal_id=132512019-02-06T12:50:19Zosmith
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul>