Feature #2631
closedallow arbitrary endpoint names, be more dynamic in allocation and iteration
100%
Description
Break that direct link between '23@mgw' endpoint name and the 23rd item in an array of endpoints.
A client should be able to name their endpoints arbitrarily, say the MSC has "1@msc" and the BSC has "1@bsc" or even something completely random and/or not related to integer digits. Upon CRCX, we create an endpoint in an llist, manage it by whichever name the client gave it, by looking up the name in the llist.
(Optimizations applied (later) might be to have some fixed size of unused endpoints instead of allocating single llist items, and to use a hashed list for faster endpoint lookup. But for starters, allocating the few endpoints we will be using one by one and iterating all of them to find a given name is far sufficient.)
A practical example is MSC and BSC using the same OsmoMGW in a network-in-the-box installation. In the current osmo-mgw, I want to tell the MSC to use a given range of endpoints, and the BSC to use another range, so that they don't accidentally claim the same endpoints for separate purposes. But how to pick the ranges? Say I am ambitious and just to be future compatible, I pick 1..1024 for the MSC and 1025..2048 for the BSC. Now the MGW would maintain 2k unused endpoint structs, regardless of how many are actually in use, out of a cosmetic choice of identifier tokens. The MGW would allocate all of these unused endpoints and iterate over all of them during every mgcp_keepalive_cb().
This is a leftover from osmo-bsc_mgcp's tactics of immediately binding all of the RTP ports, where it indeed makes sense to also have all of them allocated; and of that "port magic" where the endpoint ID directly corresponds to a specific port number. Let's move away from that.
Related issues
Updated by neels over 6 years ago
- Related to Bug #2632: osmo-mgw's VTY config modifies the length used for internal endpoints array without reallocating the array added
Updated by neels over 6 years ago
In a related note, osmo-mgw wants to treat "1" as the first endpoint, not zero, and hence allocates one more endpoint struct. It reads as
/* + 1 as we start counting at one */ g_cfg->trunk.number_endpoints = atoi(argv[0]) + 1;
This is ugly. number_endpoints should reflect the number of items, no matter what, and the translation from "1" to index=0 should be wherever that "1" is being parsed into an array index. Of course, if we implement a dynamic list of arbitrary endpoint names, this side issue will go away for free.
Updated by neels over 6 years ago
- Related to Bug #2633: 'N@mgw' number translation uses base-16 which will break for decimal endpoint IDs near the number of reserved endpoints added
Updated by laforge over 6 years ago
On Fri, Nov 10, 2017 at 01:37:59AM +0000, neels [REDMINE] wrote:
Break that direct link between '23@mgw' endpoint name and the 23rd item in an array of endpoints.
ACK.
A client should be able to name their endpoints arbitrarily, say the MSC has "1@msc" and the BSC has "1@bsc" or even something completely random and/or not related to integer digits.
I don't agree that the client should name "their" endpoints arbitrarily.
Endpoints are resources at a media gateway, not at the call agent (BSC,
MSC)!
Endpoint names are defined by the media gateway. The local part (in our
case of "1@mgw" that's "1") should have a naming scheme that indicates
the type of the endpoint as well as it's instance. See e.g.
https://www.cisco.com/c/en/us/support/docs/voice/media-gateway-control-protocol-mgcp/44130-understanding-mgcp.html#topic2
for some examples on how endpoint names are structured on Cisco devices.
The host part after the @ should identify the hostname of the media gateway.
So the MGW has to provide a certain schema for the naming of endpoints
like "RTPBRIDGE/%u@host.na.me" for RTP bridge endpoints, and the call
agent must have a matching understanding of the endpoint names. By
having a fixed scheme in osmo-mgw and a configurable scheme in
libosmo-mgcp-client (which defaults to the same used on osmo-mgw) we
should have a configuration that will work both with our osmo-mgw out of
the box but also work with other media gateways.
Starting the endpoint schema with the type of the endpoint allows us to
extend with E1 endpoints and other endpoint types like play-out, etc.
Upon CRCX, we create an endpoint in an llist, manage it by whichever name the client gave it, by looking up the name in the llist.
I'm not entirely sure if this is the best strategy.
A classic MGW has physical resources (E1 timeslots, PSTN ports, ...) and
thus nothing dynamic. A RTP bridge MGW could have many endpoints, but
is in the end also limited by number of UDP ports, CPU resources, etc.
Statically allocating all [memory] resources required at runtime has
a very deterministic behavior: If your program ever starts, it will
continue to run. You don't have to worry about memory allocation
failures at runtime killing your program. Also, static allocation
avoids any issues with memory fragmentation even if you're not using
a fixed-object-size pool allocator.
So there are many reasons why static pre-allocation of all objects at
startup has some advantages, particularly in resource-constrained
[embedded] systems.
I'm not saying that we cannot use dynamic allocation, but I'm merely
saying that this particular concept in the old implementation is not
necessarily bad/wrong.
(Optimizations applied (later) might be to have some fixed size of unused endpoints instead of allocating single llist items, and to use a hashed list for faster endpoint lookup. But for starters, allocating the few endpoints we will be using one by one and iterating all of them to find a given name is far sufficient.)
I don't think endpoint lookup speed is relevant in any way. The only
performance-critical part in a MGW are the RTP media flows, where you
want to avoid any expensive operation on each RTP packet. Operations on
the MGCP protocol side are very infrequent, right?
Updated by laforge over 6 years ago
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 ;)
Updated by dexter over 6 years ago
Sounds great, this also eases the problems we might have with stuck endpoints. Also the client would no longer have to track which endpoints it used and which ones are still unused. Also we are no longer required to specify the endpoint range via VTY.
Updated by laforge over 6 years ago
On Mon, Nov 20, 2017 at 10:17:53AM +0000, dexter [REDMINE] wrote:
Sounds great, this also eases the problems we might have with stuck endpoints.
Not sure exactly what you mean by that.
Please note that in the TTCN-3 tests, I do a DLCX on the endpoint
without call-id and without connection-id, which according to spec
should delete all connections on the endpoint and thus puts it into
a "known sane" state.
I'm not arguing we should do this all the time in normal operation,
I just wanted to make sure we're all aware that this is a valid and
spec-conforming way to react to endpoints that are in weird state.
Updated by dexter over 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 30
Since our latest thoughts on how the FSM (msc and bsc) that controls the media gateway should look like we need this feature. Otherwise we would end up with a workaround in the client that uses the FSM, which is not nice.
Its actually not too difficult to check on a "*" in the endpoint name and then just to pick a free endpoint. Its currently reacting on "*@mgw", which can also be changed at anytime (The * is important here). I also changed the client a bit so that it is able to parse the response that then contains the endpoint name.
The change is not complete yet. It does not interfere with the current implementation in osmo-bsc and osmo-msc. However, the unit-tests are now messed up again of course. Also we might want to decide to remove the endpoint bookkeeping in the client completely. At the moment it is at least optional.
Updated by laforge over 6 years ago
On Fri, Jan 12, 2018 at 05:30:55PM +0000, dexter [REDMINE] wrote:
Its actually not too difficult to check on a "*" in the endpoint name and then just to pick a free endpoint. Its currently reacting on "*@mgw", which can also be changed at anytime (The * is important here). I also changed the client a bit so that it is able to parse the response that then contains the endpoint name.
Please don't go for "*@mgw" but something like "rtpbridge/*@mgw" and make sure that the hostname part ("mgw") is configurable via VTY if it isn't yet. I've mentioned this notation several times before, it's about time that we start to make use of it. It's also the precondition to re-introducing E1/T1 support.
Updated by dexter about 6 years ago
The hostname (domain name) is now configurable, see also patch: https://gerrit.osmocom.org/#/c/5878/ (already merged)
For wildcard CRCX see the following patch, it does not introduce the prefix yet
https://gerrit.osmocom.org/#/c/5879/
The prefix is introduced with this patch, so now one can do rtpbridge/*@mgw. *@mgw is still accepted, but I thin we should remove this as soon as we patched bsc/msc so that there is no confusion about this. We might also decide to have the prefix for the virual trunk configurable. Then the defult would be just an empty string making *@mgw the default.
https://gerrit.osmocom.org/#/c/5880/
Updated by dexter about 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 60 to 100
All three patches are merged now. We now can do wildcarded CRCX. I think we should close this now and add new task in case we want to elaborate the current features.
