Project

General

Profile

Feature #2605

from OsmoMSC, use the new OsmoMGW instead of osmo-bsc_mgcp

Added by neels 9 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
MGCP towards MGW
Target version:
-
Start date:
10/31/2017
Due date:
% Done:

100%

Estimated time:
Resolution:

Description

As I'm writing doc like [[Cellular Infrastructure:Osmocom Network In The Box]], I notice that OsmoMSC still relies on osmo-bsc_mgcp.
If it needs any adjustments to use osmo-mgw instead, apply them.
Also make sure the osmo-gsm-tester runs osmo-mgw instead of osmo-bsc_mgcp for the AoIP runs.


Related issues

Blocks OsmoGSMTester - Bug #2699: Update osmo-msc to use osmo-mgwResolved2017-12-01

History

#1 Updated by neels 9 months ago

  • Assignee set to dexter
  • Priority changed from Normal to High

dexter, can you take a look at this plz? Then let's talk about what needs to be changed, if any.

#2 Updated by dexter 9 months ago

This is definetly on the list of the items that I will work on next. osmo-bsc_mgcp will be removed form osmo-msc and we will use osmo-mgw instead. There are indeed adjustments needed since osmo-msc is depending on the hacks of osmo-bsc_mgcp at the moment. When done it will be incompatible to osmo-bsc_mgcp and only work with osmo-mgw.

#3 Updated by dexter 9 months ago

  • Status changed from New to In Progress

I have looked at the code now. We probably might consider to re-write the parts that control MGCP. Especially the loopback hack would work different now. (Simply create a loopback connection on the bts side and we should be good).

neels: Lets have a chat about this today.

#4 Updated by dexter 8 months ago

  • % Done changed from 0 to 30

As neels and me decided to re-implement the MGCP related parts with an osmo-fsm I have started doing that.

The FSM and the API around is outlined and partially implemented. The next step is to actually use it to see if it works as expected.

#5 Updated by dexter 8 months ago

  • % Done changed from 30 to 80

The FSM now seems to work fine. I did not test it with external mncc yet, but it should work. It also still must be tested with RANAP.

Patch is up for review: https://gerrit.osmocom.org/4980

#6 Updated by dexter 8 months ago

  • % Done changed from 80 to 90

#7 Updated by dexter 8 months ago

The patch is still in the review process. There was some problem with the IU support I have overseen. Now this is also fixed and it now builds fine and the unit-tests all work.

#8 Updated by dexter 7 months ago

The patch is now also tested against a setup with external MNCC. It turned out that the FSM missed a state. Before we used formulas to calculate the port on the RAN side, so we were not reliant on the ASSIGNMENT COMPLETE message. Now we are and we must wait until the assignment on the A-Interface side is complete. I expect a similar problem on the IuCS side. I did not test with IuCS yet. I need to get the nano3G BTS working first before I can test.

#9 Updated by dexter 7 months ago

I have found the right location where the RTP / IP-Address of the NodeB becomes known. From there we just need to call msc_mgcp_ass_complete(). That should make it work again. Unfortunately the address information seems to be inside a nested ASN.1 encoded bitstring. I need some hints on how to pars this bitstring using our libraries.

Also have a look at: https://gerrit.osmocom.org/#/c/4980/13/src/libmsc/iucs_ranap.c

#10 Updated by neels 7 months ago

dexter wrote:

I have found the right location where the RTP / IP-Address of the NodeB becomes known. From there we just need to call msc_mgcp_ass_complete(). That should make it work again. Unfortunately the address information seems to be inside a nested ASN.1 encoded bitstring. I need some hints on how to pars this bitstring using our libraries.

Also have a look at: https://gerrit.osmocom.org/#/c/4980/13/src/libmsc/iucs_ranap.c

The code should work something like this:

static int decode_transp_layer_addr(BIT_STRING_t *in, uint32_t *ip_addr)
{                  
        implement reverse of new_transp_layer_addr() in ranap_msg_factory.c sort of like
        if (in->size != 160/8)
            ||in->buf[0] != 0x35
            || ...)
                return -EINVAL;
        memcpy(ip_addr, &in->buf[3], sizeof(*ip_addr));
        return 0;
}

static int iucs_rx_rab_assign(struct gsm_subscriber_connection *conn,
                              RANAP_RAB_SetupOrModifiedItemIEs_t *setup_ies)
{
        uint8_t rab_id; 
        RANAP_RAB_SetupOrModifiedItem_t *item = &setup_ies->raB_SetupOrModifiedItem;
        uint32_t ip_addr;
        uint32_t port; 

        rab_id = item->rAB_ID.buf[0];

        if (item->transportLayerAddress) {
                if (decode_transp_layer_addr(item->transportLayerAddress, &ip_addr)
                    error("fubar");
        }          

        if (item->iuTransportAssociation
            && item->iuTransportAssociation->present == RANAP_IuTransportAssociation_PR_bindingID) {
                port = asn1bitstr_to_u32(&item->iuTransportAssociation->choice.bindingId);
        } else {
                error("we need a port");
        }

        LOGP(DIUCS, LOGL_NOTICE,
             "Received RAB assignment event for %s rab_id=%hhd\n",
             vlr_subscr_name(conn->vsub), rab_id);

        return 0;
}

and it would make sense to implement the decode_transp_layer_addr in asn1helpers.c instead of locally, I guess. And move the new_transp_layer_addr() to asn1helpers.c too. Both with proper naming with respect to that public API.

#11 Updated by dexter 7 months ago

It now also works for the nano3G, however external MNCC does not work yet because IuUP is not understood by the average PBX software.

#12 Updated by laforge 7 months ago

On Wed, Dec 20, 2017 at 03:38:53PM +0000, dexter [REDMINE] wrote:

It now also works for the nano3G, however external MNCC does not work yet because IuUP is not understood by the average PBX software.

well' the proper solution is to have IuUP support in osmo-mgw and insrtuct osmo-mgw to
use IuUP on the connection twoards the nano3G and use plain RTP-AMR on the connection
towards the core network (or PBX).

I plan to do the related work on osmo-mgw in the next few days. However, we will need
support from the osmo-msc to actually specify the different media types for the two
call legs.

#13 Updated by laforge 7 months ago

  • Category set to MGCP towards MGW

#14 Updated by pespin 7 months ago

  • Blocks Bug #2699: Update osmo-msc to use osmo-mgw added

#15 Updated by dexter 6 months ago

The patch is still in review process: https://gerrit.osmocom.org/4980

There are two things to mention:

  • We will get a more comfortable interface to the mgcp-client soon (see https://gerrit.osmocom.org/#/c/5881/) We might consider using it there too, this would simplify the implementation by some degrees.
  • osmo-mgw now supports wildcarded CRCX, we should make use of this feature here.

#16 Updated by laforge 6 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

pach merged. Let's make sure we iron out any kinks using more tests and making existing tests pass.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)