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
Mon Nov 20 10:08:47 UTC 2017


On Mon, Nov 20, 2017 at 10:41:16AM +0100, Pau Espin Pedrol wrote:
> I guess this also simplifies the code in osmo-mgw clients (osmo-bsc,
> osmo-msc) as they don't require to manage specific ranges anymore, right? Or
> do we still want to maintain that possibility?

For osmo-bsc, we have to anticipate:

1 3GPP AoIP, at which point he MGCP between osmo-bsc and osmo-mgw
  is entirely private and we can avoid any management of specific
  ranges for RTP.

2 3GPP AoIP after re-introducing E1/T1 BTS support.  Here,
  specific endpoints will have to be supported:  Here, there's a
  1:1 relationship between allocating a given radio channel (TCH)
  and the respective E1 line/timeslot/sub-slot.  So basically,
  the endpoint name will be a property of the lchan, and that
  configuration is part of the vty/config.

3 IPA SCCPlite.  Here we receive the MGCP from the (non-osmocom) MSC, in
  the format like 1 at mgw where 1 is the CIC.  What we could do is to
  receive + mangle that MGCP inside osmo-bsc:
  * use number in front of @ to resolve subscriber_conn
  * rewrite "1 at mgw" to "rtpbridge/*@mgw" or the like and forward it

  From that point onwards it should be identical to case '1' above
  with 3GPP AoIP

For osmo-msc, any signaling between the msc-local MGW and the MSC itself
is again private and not exposed to any other (possibly non-osmocom)
network elements, so no management of ranges/pools in the client.

So I guess the answer to your question is: Yes, we can remvoe any
management of endpoint ranges from the client library.  Either we
let the MGW choose an endpoint within a certain class (like
"rtpbridge/*@mgw") or we already know the endpoint (E1 BTS) from the
lchan and will hence be able to ask explicitly for something like
"dahdi/S0/P1/T3/SS2 at mgw" which is "dahdi driver, slot 0, port 1,
timeslot 3, sub-slot 2.  No resource managemen is required in the mgcp
client, as the resource management/allocation is done by lchan allocator
already.

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