osmo-mgw endpoint allocation

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 https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sat Nov 18 19:56:27 UTC 2017


Hi all,

we recently had some (verbal) discussions on how to handle endpoint
allocations in a scenario where a single osmo-mgw shall be used by both
osmo-bsc and osmo-msc (in a "NITB style" setup).

There was some thinking about whether we should somehow divide fixed
ranges of the rtp-bridge endpoints between the BSC and the MSC and how
to avoid having to manually configure those.

I think I now found the proper solution for this: The call agent must
not even fully qualify the endpoint, but it can ask the MGW to allocate
one!  To quote from the MGCP RFC:

   EndpointId is the identifier for the connection endpoint in the
   gateway where CreateConnection executes.  The EndpointId can be
   fully-specified by assigning a value to the parameter EndpointId in
   the function call or it may be under-specified by using the "any of"
   wildcard convention.  If the endpoint is underspecified, the endpoint
   identifier SHALL be assigned by the gateway and its complete value
   returned in the SpecificEndPointId parameter of the response.  When
   the "any of" wildcard is used, the endpoint assigned MUST be in-
   service and MUST NOT already have any connections on it.  If no such
   endpoint is available, error code 410 (no endpoint available) SHOULD
   be returned.  The "all of" wildcard MUST NOT be used.

So in our concrete example, the BSC (or MSC) could simply ask for
"rtpbridge/*@mgw" as end-point name in CRCX, and the MGW would then
dynamically allocate a suitable free rtpbridge endpoint type and return
it in the call agent in the BSC (or MSC).  No shared knowledge about
endpoint number allocations / ranges or the like required.

Now we only need to implement this in osmo-mgw ;)

Related: https://osmocom.org/issues/2631

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list