https://www.osmocom.org/https://www.osmocom.org/favicon.ico?16647414092019-07-18T05:05:10ZOpen Source Mobile CommunicationsOsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=151992019-07-18T05:05:10Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-3 priority-high3 closed" href="/issues/3260">Bug #3260</a>: Implement libosmo-abis input for new E1 interface</i> added</li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=152032019-07-18T05:08:13Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed behind-schedule" href="/issues/2547">Feature #2547</a>: Add E1/T1 endpoint type to osmo-mgw</i> added</li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=153282019-07-18T06:15:48Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>laforge</i></li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=153292019-07-18T06:15:56Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=158042019-09-04T09:06:43Zlaforge
<ul></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=181692020-05-05T19:03:32Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>dexter</i></li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=183462020-05-15T16:44:41Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=183732020-05-18T18:59:15Zdexter
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>I am currently cleaning up the source around the endpoint / trunk management. I have basically eliminated the integer based endpoint access. Also there is a better evaluation of the trunk prefix. For the virtual trunk things are fine, for E1 I have not done much yet. I still see that there osmo-mgw still requires a lot of cleanup. For example there is a lot of endpoint/trunk allocation related stuff in protocol.c, even though this has nothing to do with the protocol at all. I am about the get this cleaned up.</p>
<p>See also <a class="issue tracker-2 status-3 priority-3 priority-high3 closed behind-schedule" title="Feature: Add E1/T1 endpoint type to osmo-mgw (Resolved)" href="https://www.osmocom.org/issues/2547">#2547</a></p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=183752020-05-19T07:40:15Zlaforge
<ul></ul><p>On Mon, May 18, 2020 at 06:59:15PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>For E1, I need to know if the following makes sense:</p>
<p>The spec suggests the following for the selection of an E1 (digital) endpoint:<br />ds/<unit-type1>-<unit #>/<unit-type2>-<unit #>/.../<channel #></p>
<p>I understand this recommendation like this: <br />ds/e1-0/s-2/su-1/0 => digital-trunk/e1-card number 0/timeslot 1/subslot 0/channel 0</p>
<p>For the "channel" I am not sure.</p>
</blockquote>
<p>Neither am I.</p>
To keep it generic, we need to be able to express/address the following in the naming:
<ul>
<li>a full 64k timeslot</li>
<li>a 32k sub-slot (up to 2 in one timeslot)</li>
<li>a 16k sub-slot (up to 4 in one timeslot)</li>
<li>a 8k sub-slot (up to 8 in one timeslot)</li>
</ul>
<p>To make things more interesting, they can be mixed, e.g. you can have two 16k sub-slots<br />and 4 8k sub-slots within one timeslot.</p>
<p>so rather than 'su-1' (which doesn't state which sub-channel) I would suggest something like</p>
<p>su32-0 (bit 0..3)<br />su32-4 (bit 4..7)</p>
<p>su16-0 (bit 0..1)<br />su16-2 (bit 2..3)<br />su16-4 (bit 4..5)<br />su16-6 (bit 6..7)</p>
<p>su8-0 (bit 0)<br />su8-1 (bit 0)<br />su8-2 (bit 0)<br />su8-3 (bit 0)<br />su8-4 (bit 0)<br />su8-5 (bit 0)<br />su8-6 (bit 0)<br />su8-7 (bit 0)</p>
<p>This way the naming is very clear, i.e. it specifies unambigously which bits of each 64k timeslot byte<br />a given sub-channel is to use. One could then have combinations (simultaneously active sub-channels) like</p>
<p>su32-0 + su16-4 + su8-6 + su8-7</p>
<p>Feel free to make better proposals regarding the naming, but the semantics of identifying both<br />the sub-slot type and its bit offset in the byte are required.</p>
<p>Combinations with overlapping bit allocations are of course invalid, i.e. su16-0 + su8-1 would be illegal.</p>
<blockquote>
<p>As far as I know the E1 timeslots are assigned to the air interface timeslot in a fixed way. Basically one E1 subslot maps on one UM timeslot.</p>
</blockquote>
<p>The fact whether they are allocated fixed or not to Um interface timeslots does not matter<br />to the MGW. The MGW has no knowledge about GSM, and how the BSC and the BTS map Um timeslots<br />to E1 sub-slots should not matter to the MGW. All the MGW sees is a CRCX for some endpoint name,<br />and from that information it must be able to deduce all relevant details.</p>
<blockquote>
<p>Now I am not sure how half-rate channels would end up on the E1. Where does the demuxing take place (libosmo-abis)? Does my endpoint addressing model make sense?</p>
</blockquote>
HR can be mapped on 16k sub-slots but also on 8k sub-slots. I am currently working on implementing<br />the full processing chain in libosmo-*, that is
<ul>
<li>I.460 demultiplex from 64k to any combination of sub-slots</li>
<li>TRAU frame synchronization / alignment</li>
<li>generic TRAU frame parsing</li>
<li>payload-specific TRAU frame to RTP payload conversion (and vice versa)</li>
</ul>
<p>How this will be integrated with the mgw is not clear at this point yet. My main<br />goal is to create something the MGW can be tested/developed against at this point.</p>
<p>In any case, the actual functionality will be in libosmocore + libosmo-trau (part of libosmo-abis).</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=183772020-05-19T15:34:07Zdexter
<ul></ul><p>I think the naming scheme you suggest is fine.</p>
<p>The combinations above would than result into the following endpoint names (assuming e1 card #0, TS1):</p>
<p>ds/e1-0/s-1/su32-0<br />ds/e1-0/s-1/su32-4</p>
<p>ds/e1-0/s-1/su16-0<br />ds/e1-0/s-1/su16-2<br />ds/e1-0/s-1/su16-4<br />ds/e1-0/s-1/su16-6</p>
<p>ds/e1-0/s-1/su8-0<br />ds/e1-0/s-1/su8-1<br />ds/e1-0/s-1/su8-2<br />ds/e1-0/s-1/su8-3<br />ds/e1-0/s-1/su8-4<br />ds/e1-0/s-1/su8-5<br />ds/e1-0/s-1/su8-6<br />ds/e1-0/s-1/su8-7</p>
<p>Is this list complete, or could we also have something like this?</p>
<p>su16-0 su32-2 su16-6 (16k + 32k + 16k)</p>
<p>The reason why I am asking this is because I see a problem with the modeling inside osmo-mgw. At the moment we allocate the entire trunk with all its endpoints once on startup and never free it. We also keep per endpoint counters, which I believe are not reset when a call ends. So basically we model the endpoints as a fixed resource. In the case of the virtual-trunk this is fine, we set up N endpoints and the system runs with it. Each endpoint has its fixed name that unambiguously identifies it.</p>
<p>I wonder how this would work out for an E1 trunk. It looks simple in the first place. The E1 trunk has limited resources, and a very specified way how they are allocated but how one timeslot is used is very dynamic. If the list above is complete I would say this is no problem, we could still move on with the statically allocated endpoints, all we would need is some logic that makes sure no illegal combination of endpoints is picked but if we can combine the various subslot types arbitrary like (e.g. 16k + 32k + 16k) the overhead would get to much I think.</p>
<p>I mean we could move on with a dynamic allocation for trunk endpoints but then we would loose the counter states each time a call ends. What do you think?</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=183782020-05-19T18:38:47Ztnt
<ul></ul><p>The list is complete you can't have 32k channel starting on bit 2. They are "aligned".</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=183792020-05-20T11:08:21Zlaforge
<ul></ul><p>On Tue, May 19, 2020 at 03:34:07PM +0000, dexter [REDMINE] wrote:</p>
<blockquote>
<p>The combinations above would than result into the following endpoint names (assuming e1 card #0, TS1):</p>
</blockquote>
<blockquote>
<p>Is this list complete, or could we also have something like this?</p>
</blockquote>
<p>I think it is</p>
<blockquote>
<p>su16-0 su32-2 su16-6 (16k + 32k + 16k)</p>
</blockquote>
<p>I believe I.460 does not support such a layout. A 32 sub-slot will always start either at bit 0 or 4.</p>
<p>So you can have 32+16+16 or 16+16+32, but not the combination you outlined above.</p>
<blockquote>
<p>I mean we could move on with a dynamic allocation for trunk endpoints but then we would loose the counter states each time a call ends. What do you think?</p>
</blockquote>
<p>I think an E1 line has a fixed number of timeslots, and there is a fixed nubmer of sub-slots possible<br />on each of them. Resourecs are not dynamic, even more than for the virtual trunk. So I'm against<br />dynamic allocation.</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=187222020-06-15T14:11:06Zdexter
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>get rid of endpoint integers and replace it with string (e.g. in log messages)</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>implement endpoint name matching based on endpoint class prefix like 'rtpbridge/'</i> set to Done</li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=187232020-06-15T14:13:44Zdexter
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>70</i></li></ul><p>Major changes to the architecture are done, however we are not there yet. The following patches are in review:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/18831">https://gerrit.osmocom.org/c/osmo-mgw/+/18831</a> cosmetic: remove excess space<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/18590">https://gerrit.osmocom.org/c/osmo-mgw/+/18590</a> trunk: get rid of virt_trunk pointer<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/18745">https://gerrit.osmocom.org/c/osmo-mgw/+/18745</a> endp: add name generator function for E1 endpoints<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/18752">https://gerrit.osmocom.org/c/osmo-mgw/+/18752</a> trunk: parse E1 trunk number<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/18754">https://gerrit.osmocom.org/c/osmo-mgw/+/18754</a> endp: move endpoint name generation into mgcp_endp.c</p>
<p>(<a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/18755">https://gerrit.osmocom.org/c/osmo-mgw/+/18755</a> is still work in progress, lets focus on getting the pending patches as soon as possible)</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=188702020-06-22T09:35:01Zdexter
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>dispatch messages like CRCX/MDCX to endpoint class specific operations after message decodin</i> set to Done</li></ul><p>We now have everything together to support E1 as our first "different" endpoint type. Endpoint names are strings and are also resolved as strings as well.</p>
<p>However, I think the way we currently resolve the trunks needs some re thinking. One problem is that the trunk number currently is the array index in the array of trunks. We probably should find a way to have a bit more freedom here. Also at the moment all additional trunks that are added by the user can only be E1 trunks. This limitation is more due to the way how VTY configuration works rather than it is a true limitation in the current architecture.</p>
<p>I have set the checkbox to the "dispatch messages like CRCX..." because there are no limitations here. The MGCP layer does not care about the endpoint time. It just uses the name as reference and the right endpoint from the right trunk is picked. So I think this is fine now. The RTP side is also already detached I think because we have callback functions that are picked depending on the endpoint type as well.</p>
<p>The audio playback endpoint is waht is still missing from the list. I think that such an endpoint would need a separate trunk with endpoint names like "playback/filename@mgw". However, this requires to revise the VTY config first.</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=188812020-06-22T15:57:34Zlaforge
<ul><li><b>Checklist item</b> deleted (<strike><i>implement a simple "audio file playback" endpoint endpoint class to verify abstraction is complete</i></strike>)</li></ul> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=189822020-06-30T07:42:14Zdexter
<ul><li><strong>% Done</strong> changed from <i>70</i> to <i>100</i></li></ul><p>Some of the patches above are still in review, lets keep this open until the patches are merged.</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=190562020-07-06T17:31:43Zdexter
<ul><li><strong>% Done</strong> changed from <i>100</i> to <i>90</i></li></ul><p>While integrating the E1 support I see that there is still quite a bit to refactor:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/19163">https://gerrit.osmocom.org/c/osmo-mgw/+/19163</a> mgcp_conn: move struct mgcp_conn mgcp_conn.h<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/19164">https://gerrit.osmocom.org/c/osmo-mgw/+/19164</a> mgcp_internal: remove forward declaration struct mgcp_endpoint_type<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/19102">https://gerrit.osmocom.org/c/osmo-mgw/+/19102</a> mgcp_trunk: pick trunk by number and type<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/19103">https://gerrit.osmocom.org/c/osmo-mgw/+/19103</a> mgcp_vty: be more specific about E1 trunks<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/19120">https://gerrit.osmocom.org/c/osmo-mgw/+/19120</a> mgcp_test: do not access endpoint array elements directly<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/19165">https://gerrit.osmocom.org/c/osmo-mgw/+/19165</a> mgcp_test: remove trunk2 from unit-test<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/19166">https://gerrit.osmocom.org/c/osmo-mgw/+/19166</a> mgcp_endp: add function to claim an endpoint</p>
<p>Maybe it is wise to report the not directly E1 related changes here. Unfortunately it is a problem to see every bit that needs to be changed in advance. I expect that when E1 support is done there needs to go one final run of refactoring to round everything up.</p> OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typeshttps://www.osmocom.org/issues/2659?journal_id=194162020-08-18T19:27:18Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul>