https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092017-11-10T01:41:54ZOpen Source Mobile CommunicationsOsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=61882017-11-10T01:41:54Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-high2 closed" href="/issues/2632">Bug #2632</a>: osmo-mgw's VTY config modifies the length used for internal endpoints array without reallocating the array</i> added</li></ul> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=61892017-11-10T01:48:37Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>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</p>
<pre>
/* + 1 as we start counting at one */
g_cfg->trunk.number_endpoints = atoi(argv[0]) + 1;
</pre>
<p>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.</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=61912017-11-10T02:02:04Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/2633">Bug #2633</a>: 'N@mgw' number translation uses base-16 which will break for decimal endpoint IDs near the number of reserved endpoints</i> added</li></ul> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=61952017-11-10T04:20:23Zlaforge
<ul></ul><p>On Fri, Nov 10, 2017 at 01:37:59AM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>Break that direct link between '23@mgw' endpoint name and the 23rd item in an array of endpoints.</p>
</blockquote>
<p>ACK.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>I don't agree that the client should name "their" endpoints arbitrarily.<br />Endpoints are resources at a media gateway, not at the call agent (BSC,<br />MSC)!</p>
<p>Endpoint names are defined by the media gateway. The local part (in our<br />case of "1@mgw" that's "1") should have a naming scheme that indicates<br />the type of the endpoint as well as it's instance. See e.g.<br /><a class="external" href="https://www.cisco.com/c/en/us/support/docs/voice/media-gateway-control-protocol-mgcp/44130-understanding-mgcp.html#topic2">https://www.cisco.com/c/en/us/support/docs/voice/media-gateway-control-protocol-mgcp/44130-understanding-mgcp.html#topic2</a><br />for some examples on how endpoint names are structured on Cisco devices.</p>
<p>The host part after the @ should identify the hostname of the media gateway.</p>
<p>So the MGW has to provide a certain schema for the naming of endpoints<br />like "<a class="email" href="mailto:RTPBRIDGE/%u@host.na.me">RTPBRIDGE/%u@host.na.me</a>" for RTP bridge endpoints, and the call<br />agent must have a matching understanding of the endpoint names. By<br />having a fixed scheme in osmo-mgw and a configurable scheme in<br />libosmo-mgcp-client (which defaults to the same used on osmo-mgw) we<br />should have a configuration that will work both with our osmo-mgw out of<br />the box but also work with other media gateways.</p>
<p>Starting the endpoint schema with the type of the endpoint allows us to<br />extend with E1 endpoints and other endpoint types like play-out, etc.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>I'm not entirely sure if this is the best strategy.</p>
<p>A classic MGW has physical resources (E1 timeslots, PSTN ports, ...) and<br />thus nothing dynamic. A RTP bridge MGW could have many endpoints, but<br />is in the end also limited by number of UDP ports, CPU resources, etc.</p>
<p>Statically allocating all [memory] resources required at runtime has<br />a very deterministic behavior: If your program ever starts, it will<br />continue to run. You don't have to worry about memory allocation<br />failures at runtime killing your program. Also, static allocation<br />avoids any issues with memory fragmentation even if you're not using<br />a fixed-object-size pool allocator.</p>
<p>So there are many reasons why static pre-allocation of all objects at<br />startup has some advantages, particularly in resource-constrained<br />[embedded] systems.</p>
<p>I'm not saying that we cannot use dynamic allocation, but I'm merely<br />saying that this particular concept in the old implementation is not<br />necessarily bad/wrong.</p>
<blockquote>
<p>(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.)</p>
</blockquote>
<p>I don't think endpoint lookup speed is relevant in any way. The only<br />performance-critical part in a MGW are the RTP media flows, where you<br />want to avoid any expensive operation on each RTP packet. Operations on<br />the MGCP protocol side are very infrequent, right?</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=62672017-11-18T19:57:17Zlaforge
<ul></ul><p>I think I now found the proper solution for this: The call agent must<br />not even fully qualify the endpoint, but it can ask the MGW to allocate<br />one! To quote from the MGCP RFC:<br /><pre>
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.
</pre><br />So in our concrete example, the BSC (or MSC) could simply ask for<br />"rtpbridge/*@mgw" as end-point name in CRCX, and the MGW would then<br />dynamically allocate a suitable free rtpbridge endpoint type and return<br />it in the call agent in the BSC (or MSC). No shared knowledge about<br />endpoint number allocations / ranges or the like required.</p>
<p>Now we only need to implement this in osmo-mgw ;)</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=62762017-11-19T10:30:07Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>"rtpbridge/*@mgw"</p>
</blockquote>
<p>nice!</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=62832017-11-20T10:17:53Zdexter
<ul></ul><p>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.</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=62852017-11-20T10:50:09Zlaforge
<ul></ul><p>On Mon, Nov 20, 2017 at 10:17:53AM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>Sounds great, this also eases the problems we might have with stuck endpoints.</p>
</blockquote>
<p>Not sure exactly what you mean by that.</p>
<p>Please note that in the TTCN-3 tests, I do a DLCX on the endpoint<br /><strong>without call-id and without connection-id</strong>, which according to spec<br />should delete all connections on the endpoint and thus puts it into<br />a "known sane" state.</p>
<p>I'm not arguing we should do this all the time in normal operation,<br />I just wanted to make sure we're all aware that this is a valid and<br />spec-conforming way to react to endpoints that are in weird state.</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=62882017-11-20T11:53:15Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/6288/diff?detail_id=9758">diff</a>)</li></ul> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=71302018-01-12T17:30:55Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>30</i></li></ul><p>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.</p>
<p>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.</p>
<p>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.</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=71352018-01-13T19:20:09Zlaforge
<ul></ul><p>On Fri, Jan 12, 2018 at 05:30:55PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=72502018-01-22T21:15:03Zdexter
<ul></ul><p>The hostname (domain name) is now configurable, see also patch: <a class="external" href="https://gerrit.osmocom.org/#/c/5878/">https://gerrit.osmocom.org/#/c/5878/</a> (already merged)</p>
<p>For wildcard CRCX see the following patch, it does not introduce the prefix yet<br /><a class="external" href="https://gerrit.osmocom.org/#/c/5879/">https://gerrit.osmocom.org/#/c/5879/</a></p>
<p>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.<br /><a class="external" href="https://gerrit.osmocom.org/#/c/5880/">https://gerrit.osmocom.org/#/c/5880/</a></p> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=73332018-01-29T20:46:16Zdexter
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>60</i></li></ul> OsmoMGW - Feature #2631: allow arbitrary endpoint names, be more dynamic in allocation and iterationhttps://projects.osmocom.org/issues/2631?journal_id=74082018-02-05T21:38:58Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>60</i> to <i>100</i></li></ul><p>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.</p>