Project

General

Profile

Feature #2631

allow arbitrary endpoint names, be more dynamic in allocation and iteration

Added by neels 10 days ago. Updated about 8 hours ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
11/10/2017
Due date:
% Done:

0%


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

Related to OsmoMGW - Bug #2632: osmo-mgw's VTY config modifies the length used for internal endpoints array without reallocating the array In Progress 11/10/2017
Related to OsmoMGW - Bug #2633: 'N@mgw' number translation uses base-16 which will break for decimal endpoint IDs near the number of reserved endpoints In Progress 11/10/2017

History

#1 Updated by neels 10 days ago

  • Related to Bug #2632: osmo-mgw's VTY config modifies the length used for internal endpoints array without reallocating the array added

#2 Updated by neels 10 days 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.

#3 Updated by neels 10 days 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

#4 Updated by laforge 10 days 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 "" 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?

#5 Updated by laforge about 22 hours 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 ;)

#6 Updated by neels about 8 hours ago

laforge wrote:

"rtpbridge/*@mgw"

nice!

Also available in: Atom PDF