Cellular Network Infrastructure » OsmoMGW

We could delay exit() of the osmo-mgw process during SIGINT, to transmit RestartInProgress to all active endpoints, so that the call agent (bsc, msc, etc.) knows it has to terminate the calls.
This could perhaps even be used by Call agent to keep calls working by signalling peer BSC/BTS/MSC/etc. to change to another MGW if there's an MGW pool with more available MGW, providing higher reliability?

This could also be used to signal disconnect or temporary unavailability to E1 timeslots, etc.

https://datatracker.ietf.org/doc/html/rfc3435#section-2.3.12
https://datatracker.ietf.org/doc/html/rfc3435#section-3.3.8
https://datatracker.ietf.org/doc/html/rfc3435#appendix-F.10

   * The Gateway can use the RestartInProgress command to notify the
     Call Agent that a group of endpoints managed by the gateway is
     being taken out-of-service or is being placed back in-service.

2.3.12 RestartInProgress

   The RestartInProgress command is used by the gateway to signal that
   an endpoint, or a group of endpoints, is put in-service or out-of-
   service.

Gateways SHOULD send a "graceful" or "forced" RestartInProgress
   message (for the relevant endpoints) as a courtesy to the Call Agent
   when they are taken out-of-service, e.g., by being shutdown, or taken
   out-of-service by a network management system, however the Call Agent
   cannot rely on always receiving such a message.  Gateways MUST send a
   "restart" RestartInProgress message (for the relevant endpoints) with
   a null delay to their Call Agent when they are back in-service
   according to the restart procedure specified in Section 4.4.6 - Call
   Agents can rely on receiving this message.  Also, gateways MUST send
   a "disconnected" RestartInProgress message (for the relevant
   endpoints) to their current "notified entity" according to the
   "disconnected" procedure specified in Section 4.4.7.

The RestartInProgress message will be sent to the current "notified
   entity" for the EndpointId in question.  It is expected that a
   default Call Agent, i.e., "notified entity", has been provisioned so
   that after a reboot/restart, the default Call Agent will always be
   the "notified entity" for the endpoint.  Gateways SHOULD take full
   advantage of wild-carding to minimize the number of RestartInProgress
   messages generated when multiple endpoints in a gateway restart and
   the endpoints are managed by the same Call Agent.

   8) RestartInProgress MUST always be the first command sent by an
      endpoint as defined by the restart procedure.  Any other command
      or non-restart response (see Section 4.4.6), except for responses
      to auditing, MUST be delivered after this RestartInProgress
      command (piggybacking allowed).

In some cases, many gateways may decide to restart operation at the
   same time.  This may occur, for example, if an area loses power or
   transmission capability during an earthquake or an ice storm.  When
   power and transmission are reestablished, many gateways may decide to
   send "RestartInProgress" commands simultaneously, leading to very
   unstable operation.

   A virtual endpoint may be created as the result of using the "any of" 
   wildcard.  Similarly, a virtual endpoint may cease to exist once the
   last connection on the virtual endpoint is deleted.  The definition
   of the virtual endpoint MUST detail both of these aspects.

   When a <virtual-endpoint-type> creates and deletes virtual endpoints
   automatically, there will be cases where no virtual endpoints exist
   at the time a RestartInProgress command is to be issued.  In such
   cases, the gateway SHOULD simply use the "all of" wildcard in lieu of
   any specific <endpoint-#> as in, e.g.:

     ann/*@mygateway.whatever.net

   If the RestartInProgress command refers to all endpoints in the
   gateway (virtual or not), the <virtual-endpoint-id> can be omitted as
   in, e.g.:

     *@mygateway.whatever.net

It seems we must also be sending that message for each available endpoint at startup AFAIU (or 1 with wildcard "*"). We seem to be missing a "default Call Agent" in osmo-mgw though":

It is expected that a
   default Call Agent, i.e., "notified entity", has been provisioned so
   that after a reboot/restart, the default Call Agent will always be
   the "notified entity" for the endpoint.
....
   Note that as mentioned earlier, the default "notified entity" is
   provisioned and may include both domain name and port.  For small
   gateways, provisioning may be done on a per endpoint basis.  For much
   larger gateways, a single provisioning element may be provided for
   multiple endpoints or even for the entire gateway itself.  In either
   case, once the gateway powers up, each endpoint MUST have its own
   "notified entity", so provisioned values for an aggregation of
   endpoints MUST be copied to the "notified entity" for each endpoint
   in the aggregation before operation proceeds.  Where possible, the
   RestartInProgress command on restart SHOULD be sent to the
   provisioned "notified entity" based on an aggregation that allows the
   "all of" wild-card to be used.  This will reduce the number of
   RestartInProgress messages.