https://osmocom.org/https://osmocom.org/favicon.ico?16647414092021-09-15T10:11:57ZOpen Source Mobile CommunicationsOsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=225582021-09-15T10:11:57Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-7 priority-1 priority-lowest" href="/issues/2545">Feature #2545</a>: OsmoBSCNAT misses 3GPP AoIP</i> added</li></ul> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=225592021-09-15T10:12:12Zlaforge
<ul><li><strong>Assignee</strong> set to <i>4368</i></li></ul> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=230552021-11-18T11:00:46Zdaniel
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> changed from <i>4368</i> to <i>daniel</i></li></ul><p>I will be working on this with <a class="user active" href="https://osmocom.org/users/15">dexter</a>.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=230792021-11-23T17:59:04Zdexter
<ul><li><strong>File</strong> <a href="/attachments/4744">3g_call_23112021.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4744/3g_call_23112021.pcapng">3g_call_23112021.pcapng</a> added</li><li><strong>File</strong> <a href="/attachments/4745">2g_call_23112021.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4745/2g_call_23112021.pcapng">2g_call_23112021.pcapng</a> added</li><li><strong>File</strong> <a href="/attachments/4746">hnb_cs_mo_call_with_mgcp.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4746/hnb_cs_mo_call_with_mgcp.png">hnb_cs_mo_call_with_mgcp.png</a> added</li><li><strong>File</strong> <a href="/attachments/4748">hnb_cs_mo_call_with_mgcp.msc</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4748/hnb_cs_mo_call_with_mgcp.msc">hnb_cs_mo_call_with_mgcp.msc</a> added</li></ul><p>After some difficulties I have my testnet now up and running again. I have made two traces. One on the 3g network and one on the 2g network for reference. From that I have derived a ladder diagram (i have left all security related messages away.) I made it so that it matches the behavior we see on osmo-bsc. My idea is to reuse the FSMs from libosmo-mgcp-client.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=231372021-11-30T10:32:54Zlaforge
<ul></ul><p>In case that is not obvious: I think as part of this project we also need to get towards a decent test coverage for osmo-hnbgw itself. Now that <a class="user active" href="https://osmocom.org/users/30187">pespin</a> has been creating Iuh related components in TTCN3 for testing osmo-hnodeb, there should be some infrastructure that can also be used to test osmo-hnbgw.</p>
<p>In the end, a osmo-hnbgw testsuite would have to talk Iuh on the one side and IuCS+IuPS on the other side. Once the tests include RAB assignment test cases, one can develop the RTP/MGW integration on the hnbgw step-by-step with the test suite (which would then have to include emulating a MGW towards the MGCP-speaking hnbgw).</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=231472021-12-03T17:37:53Zdexter
<ul></ul><p>So far my Idea is to set up the mgcp_fsm when the RAB-AssignmentRequest is seen and terminate it when the respective IU-ReleaseCommand is seen. But before we can start implementing the FSM we need tools to decode the RAB-AssignmentRequest to extract the transport layer address and to re-encode it with the changed transport layer address. Unfortunately this is not very simple. There are 3 layers of ASN.1 we need to dig through. So far I have figured out the decoding. I get meaningful results. The next step is to make proper decoder/encoder functions out of this. So far I have done a decoder that encodes/decodes the RAB-AssignmentRequest down to its request IEs, which is the first two layers of ASN.1.</p>
<p>What makes me wonder a bit is that in theory it is possible to assign multiple RABs at a time. Its also possible to have multiple "protocol container pairs". I wonder if this plays a role in practice or if it is just one element there anyways. I guess multiple RABs are for conference calls or similar applications.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=231562021-12-06T08:30:21Zlaforge
<ul></ul><p>On Fri, Dec 03, 2021 at 05:37:53PM +0000, dexter wrote:</p>
<blockquote>
<p>Unfortunately this is not very simple. There are 3 layers of ASN.1 we need to dig through. So far I have figured out the decoding. I get meaningful results. The next step is to make proper decoder/encoder functions out of this. So far I have done a decoder that encodes/decodes the RAB-AssignmentRequest down to its request IEs, which is the first two layers of ASN.1.</p>
</blockquote>
<p>we should have those RANAP-level decoders all in place in both the MSC and the SGSN,<br />as they both need to decode those very same messages for the exact same<br />purpose of accessing all those details. Please make sure we don't<br />duplicate code that may already exist.</p>
<blockquote>
<p>What makes me wonder a bit is that in theory it is possible to assign multiple RABs at a time. Its also possible to have multiple "protocol container pairs". I wonder if this plays a role in practice or if it is just one element there anyways. I guess multiple RABs are for conference calls or similar applications.</p>
</blockquote>
<p>I could imagine multiple RABs might happen in circuit-switched UMTS<br />video calls, I'm not sure. One would probably have to look at some<br />real-world traces. It would also make sense to inquire with the primary<br />customer whether or not UMTS video calls are something they wish to<br />support at all.</p>
<p>In the PS domain IMS over UTRAN also likely would use multiple RABs<br />(like different QCI in LTE) - but to the best of my knowledge, nobody<br />has deployed IMS over UTRAN; they all use circuit-switched telephony<br />on 3G and IMS only over 4G/5G.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=232112021-12-10T18:00:52Zdexter
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>30</i></li></ul><p>I have now working decoders for the RAB AsssigmentRequest and for the RAB AssignmentResponse that give me the port/ip address of the RAB that is assigned. I am currently working on the functions that do the replacing. For the RAB AssignmentRequest am done for the most part. The function works fine, but has a memory leak that I still need to figure out. I guess RAB AssignmentResponse will be easier then since it is very similar to RAB AssignmentRequest. Once I am done with the ASN.1 part I can start working on the FSM part.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=232262021-12-13T15:40:22Zdexter
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>40</i></li></ul><p>I am now done with the ASN.1 part. The next thing I will continue with will be the MGCP part.<br />See also branch: pmaier/mgw</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=232522021-12-17T18:16:27Zdexter
<ul><li><strong>% Done</strong> changed from <i>40</i> to <i>50</i></li></ul><p>I have now started the FSM that controls the MGW. I have made a draft implementation that does all the interaction with osmo-mgw with dummy data, while not modifying the RAB Assignment message. The FSM goes through the states just fine and I still can make a testcall. However, when I try a second call it does not work anymore. Also I need to test it a bit further to see if there are problematic corner cases. When it works stable as it is I will continue with altered RAB Assignment messages to redirect the voice streams through the MGW. I also noticed that I still need to parse the codec from the RAB Assignment so that I can signal it to the MGW as well.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=232782021-12-20T13:32:53Zdexter
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>60</i></li></ul><p>The is now stable. The next logical step here is to redirect the RTP stream through the MGW.</p>
<p>See also branch pmaier/mgw</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=233062021-12-22T17:18:50Zdexter
<ul><li><strong>% Done</strong> changed from <i>60</i> to <i>70</i></li></ul><p>I have managed to redirect the RTP streams through the MGW today. Initially I had some problems because I did not create the connection that points towards the HNB in loopback mode at first but now it seems to work fine. It certainly needs some cleanup though. I also added T_defs for the FSM, but this also needs some cleanup as well.</p>
<p>In January we can probably begin with the TTCN3 testing.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=233112021-12-23T17:24:16Zdexter
<ul></ul><p>I have started to clean up everything. The tdefs are now correct. The call-id is now a concatenation of the rua_ctx_id and the RAB-ID, so that it can be better recognized in traces. Also replaced the printfs with LOGPFSML statements.</p>
<p>To try it out one would also need the following patch for osmo-mgw: <a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/26651">https://gerrit.osmocom.org/c/osmo-mgw/+/26651</a>. The branch pmaier/mgw on osmo-iuh.git is up to date. The configuration is similar to osmo-msc and osmo-bsc.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=233722022-01-06T16:59:43Zdexter
<ul></ul><p>I have now fixed (hopefully) all review issues that were present in gerrit. I have also split part of my patches to the new osmo-hnbgw.git</p>
<p>The current status can be found on osmo-hnbgw.git pmaier/mgw, and osmo-iuh.git pmaier/mgw2.</p>
<p>The current implementation enforces the usage of x213 nsap address format. I initially thought that it were ok to convert everything to x213 nsap, but it is not. It depends on what the HnodeB supports. The format can also be configured in osmo-msc. I did not know that, so we when rewriting the RAB AssignmentRequest we must retain the original format.</p>
<p>At the moment the RTP streams are terminated when an IU Release is seen, this seems to be not enough. There can also be a RAB Release, that should trigger the RTP stream termination as well.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=233762022-01-07T13:05:37Zneelsnhofmeyr@sysmocom.de
<ul></ul><blockquote>
<p>The current implementation enforces the usage of x213 nsap address format. I initially thought that it were ok to convert everything to x213 nsap, but it is not. It depends on what the HnodeB supports. The format can also be configured in osmo-msc. I did not know that, so we when rewriting the RAB AssignmentRequest we must retain the original format.</p>
</blockquote>
<p>That's correct.</p>
<blockquote>
<p>At the moment the RTP streams are terminated when an IU Release is seen, this seems to be not enough. There can also be a RAB Release, that should trigger the RTP stream termination as well.</p>
</blockquote>
<p>IIRC the RAB Release comes first, and the IU Release usually follows?</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=233772022-01-07T13:30:33Zlaforge
<ul></ul><p>On Fri, Jan 07, 2022 at 01:05:37PM +0000, neels wrote:</p>
<blockquote><blockquote>
<p>At the moment the RTP streams are terminated when an IU Release is seen, this seems to be not enough. There can also be a RAB Release, that should trigger the RTP stream termination as well.</p>
</blockquote>
<p>IIRC the RAB Release comes first, and the IU Release usually follows?</p>
</blockquote>
<p>I would also expect that both happen, and in this order.</p>
<p>Basically we have three layers of release</p>
<ul>
<li>RAB release - releases just that RAB. This is where RTP resources should be release,<br />as the RTP flows are coupled to the RAB</li>
<li>Iu release - logical release of the Iu connection at RANAP level</li>
<li>SCCP level release of the IuCS connection</li>
</ul>
<p>Now it is of course possible that thre is an Iu release without RAB release, or even a SCCP<br />release without Iu or RAB release (e.g. in case of SCCP network outage, MSC restart, ...)</p>
<p>In both of these situations we should recover sanely and destroy the RTP connections.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=234162022-01-10T16:26:39Zdexter
<ul></ul><p>Hello Harald and Neels.</p>
<p>Thanks for the Input. I have had a look in the trace (3g_call_23112021.pcapng) I have made when I was starting with this ticket. What makes me wonder a bit is that in that trace I can't find a RAB Relase Request. I only see the IU release. I will look closer at this when I have resolved the remaining review issues for osmo-hnbgw.</p>
<p>Best regards.<br />Philipp</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=234172022-01-10T17:20:26Zlaforge
<ul></ul><p>On Mon, Jan 10, 2022 at 04:26:39PM +0000, dexter wrote:</p>
<blockquote>
<p>What makes me wonder a bit is that in that trace I can't find a RAB Relase Request. I only see the IU release.</p>
</blockquote>
<p>Well, the Iu release tears down any RABs within that Iu context, so it is a valid scenario.</p>
<p>As I wrote we need to deal with all possible scenarios (RAB release, Iu release, SCCP connection loss)</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=234262022-01-11T16:56:45Zdexter
<ul></ul><p>The patches for osmo-iuh.git are all merged now. So the branch pmaier/mgw on osmo-hnbgw.git can be used with current master of osmo-iuh now.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=234272022-01-11T17:24:51Zneelsnhofmeyr@sysmocom.de
<ul></ul><blockquote>
<p>The current implementation enforces the usage of x213 nsap address format. I initially thought that it were ok to convert everything to x213 nsap, but it is not. It depends on what the HnodeB supports. The format can also be configured in osmo-msc. I did not know that, so we when rewriting the RAB AssignmentRequest we must retain the original format.</p>
</blockquote>
<p>I've just been thinking about this a bit more.<br />It doesn't <strong>have</strong> to be the MSC deciding about the address format.<br />Maybe for a sys admin, it also makes sense to be able to configure the address format at the hnb-gw?</p>
<p>I guess we don't need such a feature until someone asks for it, but maybe good to keep in mind.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=234882022-01-25T11:08:50Zdexter
<ul></ul><p>The patchset is currently still in review. There is currently some discussion around where and how the encoding/decoding of the ASN.1 messages should happen. There are some patches pending for osmo-iuh that intrduce a message decoder that works similar to the one in ranap_common_cn.c The problem here is that ranap_common_cn.c only decodes messages towards the core network, we also have to decode messages that are directed towards the HnodeB. (e.g. RANAP RAB Assignment Request).</p>
<p>The current status can be found in gerrit and on the following branches:<br />osmo-iuh.git: pmaier/mgw<br />osmo-hnbgw.git: pmaier/mgw</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=235162022-01-27T14:30:29Zdexter
<ul></ul><p>Besides the architectural problems with the RANAP message decoding we also need to put the focus on testing osmo-hnbgw with TTCN3.</p>
A minimal testsuite should test the following:
<ul>
<li>Normal call scenario: We should test MO and MT calls just to be complete. In any case for the scope of this ticket this is irrelevant. Regardless how the call is established, the RAB assignment procedure will work the same way. This is basically the most important test.</li>
<li>Errornous call scenarios: We might also try some errornous call establishment examples, just to see that FSMs and RTP conns on the MGW are cleared properly.</li>
<li>RAB Release: Usually the RAB gets released when the IU Release is carried out. In a simple call scenarios there will be no extra RAB Release Rquest. A RAB Release Request might happen e.g. when the HnodeB detects that the radio link has failed failed. Then a RAB Release Request is sent to the MSC, the MSC then sends another RAB Assignment Request that contains information to release the related RAB. I think for the testcase it is enough just to send an appropriate RAB Assignment Request and check that the related RTP streams are cleared properly.</li>
<li>Errornous MGW behaviour: We might also consider to try some MGW failure scenarios to make sure that osmo-hnbgw handles this properly and does not crash etc.</li>
</ul> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=235172022-01-27T14:31:32Zdexter
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>Finish RANAP message decoding</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>Add testsuite</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>Implement RAB Release</i> added</li></ul> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=235532022-01-31T17:00:59Zdexter
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>make sure fsm terminates when context map is freed (garbage collector)</i> added</li></ul><p>I am now through with the changes to osmo-iuh and osmo-hnbgw that fix the API issues described above. We noticed that there is also an issue with the context map that is used by the FSM. The logic that creates and maintains those contexts must destroy a possibly existing FSM before it frees the context. This should be rather easy to fix.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=235622022-02-02T13:53:44Zdexter
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>Finish RANAP message decoding</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>make sure fsm terminates when context map is freed (garbage collector)</i> set to Done</li></ul> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=235632022-02-02T16:23:15Zdexter
<ul></ul><p>At the moment it is unclear what should happen when the RAB AssignmentResponse contains an unsuccessful outcome. At the moment the ranap_message container will decode, but as far as I can see it will not populate the procedure code. This means the message would fall through. It will not go through the FSM, it will just be passed on to the MSC. So the MSC will most likely tear down the call.</p>
<p>(see also: <a class="external" href="https://git.osmocom.org/osmo-iuh/tree/src/ranap_common_cn.c#n493">https://git.osmocom.org/osmo-iuh/tree/src/ranap_common_cn.c#n493</a>)</p>
<p>However, I think the FSM should be informed about the problem, so that it can clear the half open RTP stream. For that we would need to know the procedure code and the type of the outcome. As far as I understand we have this direction field in ranap_message, that could be checked for RANAP_RANAP_PDU_PR_unsuccessfulOutcome. If it is so, the FSM should be terminated. That should be enough and this is also already present in osmo-iuh.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=235912022-02-07T13:44:47Zdexter
<ul></ul><p>I could make the testsuite that <a class="user active" href="https://osmocom.org/users/30">daniel</a> running. Currently I am using TC_RAB_Assignment as a starting point to work out a testcase to verify what happens when the HnodeB responds with a Failure List instead of a Setup or Modify list.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=236452022-02-14T09:20:00Zdexter
<ul></ul><p>The FSM is now able to react to RANAP RAB AssignmentResponse messages that contain a FailedList. When a FailedList with the related RAB-ID comes back, then the FSM will terminate the RTP streams and forward the message to the MSC so that the CN is also informed about the problem.</p>
<p>I have started working on the RANAP RAB AssignmentResponse that contains a ReleaseList. In this case we must also terminate the RTP streams and also forward the message so that the HNB is informed abot the release as well.</p>
<p>At the moment all this supports only a single RAB.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=236972022-02-24T13:59:24Zdexter
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>Add testsuite</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>Implement RAB Release</i> set to Done</li></ul> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=236982022-02-24T14:02:22Zdexter
<ul><li><strong>% Done</strong> changed from <i>70</i> to <i>90</i></li></ul><p>The relevant patches are merged. osmo-hnbgw now has support for a co-located osmo-mgw instance. The implementation is now basically ready to be tried out by actual users.</p>
<p>The following patches are still in review, but they address only minor problems:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/27320">https://gerrit.osmocom.org/c/osmo-hnbgw/+/27320</a> mgw_fsm: release call when FSM is not created<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/27321">https://gerrit.osmocom.org/c/osmo-hnbgw/+/27321</a> ranap_rab_ass: check for more than one RAB assignment req</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=236992022-02-24T14:24:40Zdaniel
<ul></ul><p>The tests are now enabled on Jenkins and so far everything looks good:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test/</a></p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=237042022-02-28T09:44:29Zdexter
<ul><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>The last two fixup patches are merged. At lest from my perspective, this ticket can be closed. The implementation is tested and working in the lab setup. If there are problems in the real world, they should be addressed with a new ticket.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=237502022-03-07T12:02:52Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>The jenkins testsuite still passes all tests and all pending patches are merged. I will set this to resolved now. I case of problems we will open a dedicated ticket.</p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=245992022-08-10T06:57:59Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-2 priority-default" href="/issues/5153">Feature #5153</a>: support hnbgw co-located GTP-U proxy (UPF)</i> added</li></ul> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=246012022-08-10T06:58:01Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>100</i> to <i>90</i></li></ul><p>I just noticed that <a class="wiki-page" href="https://osmocom.org/projects/osmohnbgw/wiki/OsmoHNBGW">OsmoHNBGW</a> doesn't say anything yet about a co-located mgw. Please update the wiki accordingly, including a statement what the mgw is used for.</p>
<p>Please coordinate with <a class="user active" href="https://osmocom.org/users/91">neels</a> to avoid "merge conflicts" as he has to do a similar task for the UPF side, see my recent update to <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: support hnbgw co-located GTP-U proxy (UPF) (In Progress)" href="https://osmocom.org/issues/5153">#5153</a></p> OsmoHNBGW - Feature #5152: support hnbgw co-located osmo-mgw for RTP proxyinghttps://osmocom.org/issues/5152?journal_id=248862022-09-12T15:34:17Zdaniel
<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><p>laforge wrote in <a href="#note-35">#note-35</a>:</p>
<blockquote>
<p>I just noticed that <a class="wiki-page" href="https://osmocom.org/projects/osmohnbgw/wiki/OsmoHNBGW">OsmoHNBGW</a> doesn't say anything yet about a co-located mgw. Please update the wiki accordingly, including a statement what the mgw is used for.</p>
</blockquote>
<p>It looks like <a class="user active" href="https://osmocom.org/users/91">neels</a> has already taken care of that, thanks!</p>
<p>Both <a class="wiki-page" href="https://osmocom.org/projects/osmohnbgw/wiki/OsmoHNBGW">OsmoHNBGW</a> and the manual mention the co-located mgw.</p>