Feature #3429

idea: auto-cleanup endpoints after long period of inactivity?

Added by neels 4 months ago. Updated 18 days ago.

Target version:
Start date:
Due date:
% Done:



To avoid a scenario where osmo-mgw maintains open endpoints for a voice stream that long ceased without the mgw being told, we might want to automatically close down rtpbridge/* endpoints if we have seen no MGCP message and also not a single RTP package for a long time. A long time could be 10 minutes, or also as low as half a minute.

What happens when osmo-bsc or osmo-msc crash hard with RTP streams open? Do osmo-bsc / osmo-mgw send a wildcard DLCX for all endpoints? Maybe not a good idea in case several osmo-bsc and/or osmo-msc share the same MGW?

(Inspired by an IRC question about osmo-mgw saying "Not able to find a free endpoint")

Related issues

Related to OsmoMGW - Feature #3507: allow shorter Connection Identifier 'I:'Resolved2018-08-28

Related to OsmoMGW - Feature #3508: compare Connection Identifier 'I:' case insensitivelyResolved2018-08-28

Related to OsmoMGW - Feature #3509: match MGCP "I:" Connection ID also when leading zeros are omittedResolved2018-08-29


#1 Updated by neels 3 months ago

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.

#2 Updated by neels 3 months ago

  • Related to Feature #3507: allow shorter Connection Identifier 'I:' added

#3 Updated by neels 3 months ago

  • Related to Feature #3508: compare Connection Identifier 'I:' case insensitively added

#4 Updated by neels 3 months ago

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

#5 Updated by neels 3 months ago

  • Related to Feature #3509: match MGCP "I:" Connection ID also when leading zeros are omitted added

#6 Updated by laforge 18 days ago

  • Assignee set to osmith

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)