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
Hey, good news to hear that.
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?
Regards, Pau
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 -
Pau Espin Pedrol