Cellular Network Infrastructure » OsmoMGW

Seeing issues like #3507 and #3508, 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.

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.

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.
To be very conservative, I guess three minutes of permitted inactivity could be a good default configuration.

RFC3435

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.

Hah, I did say 3 minutes, didn't I, even though for a slightly different aim.

Status update:

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).

So far I've implemented a watchdog for mgcp_conn. Next up is implementing another watchdog for mgcp_endpoint.

While implementing this we've got to make sure it doesn't break BTS-variant of LCLS.
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.

Hm, I didn't consider LCLS keeping inactive endpoints open for a long period of time.
Keeping unused endpoints open is still a bit of a problem, we need some sort of sanity there in the MGW.

msuraev laforge Can LCLS tear down unused MGW endpoints, i.e., on breaking LCLS, can it re-create endpoints and transmit a new RTP port?

We could also tell the MGW that the endpoint is still in use by sending no-op MDCX to the MGW once a minute;
or investigate for some other keep-alive message in MGCP.

osmith btw, for me, having the inter-MSC GSUP messages is more urgent that this feature.

I had already created a patch, but forgot to post it here and update the status:

https://gerrit.osmocom.org/#/c/osmo-mgw/+/12730/

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.

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.

It is already implemented like this in the patch, receiving MDCX will update the guard timer too.

We could also tell the MGW that the endpoint is still in use by sending no-op MDCX to the MGW once a minute;
or investigate for some other keep-alive message in MGCP.

Sounds like a good solution to me, how about I create a new issue for that?

I think this issue is done when the patch gets its second +1.