Change in osmo-bsc[master]: osmo_bsc_main: integrate MGW pooling into osmo-bsc

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at

dexter gerrit-no-reply at
Wed Aug 25 12:10:18 UTC 2021

dexter has posted comments on this change. ( )

Change subject: osmo_bsc_main: integrate MGW pooling into osmo-bsc

Patch Set 11:


I have fixed the manual. Unfortunately it is not possible to give the single mgcp client (MSC node) the same "rights" as the mgcp_client members in the pool would have. The single mgcp client is a fixed mgcp client that cannot be restarted/freed etc. It also has its very own VTY node. The fact that one can add a single mgcp client as fallback to the pool does not mean that it becomes a real pool member. This is only to maintain backward compatibility. While the application internally always accesses the pool the user has the impression that he can configure either an MGW under the MSC node or if necessary a pool of MGWs under the network node. 
File doc/manuals/chapters/mgwpool.adoc: 
PS10, Line 7: machnies. Until osmo-mgw includes multithreading support, it may also be used ot
> to
PS10, Line 7: machnies
> machines
PS10, Line 7: ot
> to
PS10, Line 8: scale-out to multiple cores on a single host."
> Remove character: "
PS10, Line 11: the pool will automatically assign the call to the MGW with the lowest load.
> hint/idea: It may make sense to defie some "maximum call load" config or similar to vty, so one can  […]
I don't know if this is possible here. In fact osmo-bsc does not know anything about the MGW capabilities. It assumes that all MGWs in the pool have the same number of endpoints and it just distrubutes the load evenly as it counts the number of active calls for each MGW. This is simple but effective. In theory it would be possible to audit the MGW capabilities via MGCP but that would require a lot of effort. 
PS10, Line 41: local host ip-addresses or different ports. When OsmoMGW is installed from
> IP addresses
PS10, Line 64: each MGW must be different. Otherwise it won't be possible to distinguish the
> should be
PS10, Line 72: calls.
> do we have a vty command to avoid establishing new calls on a mgw node? (EDIT) Self-answer: yes. […]
PS10, Line 76: The VTY implenets a 'show mgw-pool' command that lists the currently configured
> implements
File include/osmocom/bsc/gsm_data.h: 
PS10, Line 1363: 		/* Single MGCP client configuration under msc node (also required for
> I would avoid maintaining different structs from previous versions. […]
I thought about doing this, but it would not work. That is due to the need for compatibility with legacy configuration. Even though the mgcp_client_conf for the single mgcp client can be registered to the pool as backup in case no members are in the pool it has not the same properties as a real pool member would have. 
File src/osmo-bsc/osmo_bsc_main.c: 
PS10, Line 890:         mgcp_client_single = mgcp_client_init(bsc_gsmnet, bsc_gsmnet->mgw.conf);
> AS I said, let's rather fill the pool always from the VTY? […]
This is technically not possible due to legacy compatibility (see other comment). The pool is indeed filled from the VTY, but the normal osmo_mgcp_client does not support this.

To view, visit
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d
Gerrit-Change-Number: 25123
Gerrit-PatchSet: 11
Gerrit-Owner: dexter <pmaier at>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann at>
Gerrit-Reviewer: laforge <laforge at>
Gerrit-Reviewer: osmith <osmith at>
Gerrit-CC: pespin <pespin at>
Gerrit-Comment-Date: Wed, 25 Aug 2021 12:10:18 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: osmith <osmith at>
Comment-In-Reply-To: pespin <pespin at>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list