On Mon, Nov 20, 2017 at 10:41:16AM +0100, Pau Espin Pedrol wrote: 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@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@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@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(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)