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.orgOn 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)