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