Feature #1846

Implement AoverIP specific procedures, message extensions and information elements

Added by laforge 6 months ago. Updated 1 day ago.

In Progress
Start date:
Due date:
% Done:


Spec Reference:


AoIP introduces a variety of new RSL information elements that extend the classic BSS[M]AP messages in several ways, for example to carry RTP IP/port identification rather than TDM circuit identifier codes. Or to indicate MSC/BSC codec capabilities.

We'll need to implement those new information elements (parsing/encoding/testcases) and implement their handling in osmo-bsc (and most likely osmo-msc, too)

notes.txt Magnifier (11.6 KB) dexter, 03/21/2017 10:40 PM

messages_we_use.txt Magnifier (6.5 KB) dexter, 03/24/2017 06:28 PM

Related issues

Related to OsmoMSC - Feature #2289: implement AoverIP New 05/24/2017


#1 Updated by laforge 6 months ago

#2 Updated by neels 3 months ago

  • Description updated (diff)

#3 Updated by laforge 3 months ago

  • Assignee set to dexter

#4 Updated by laforge 2 months ago

Background info on 3GPP AoIP

#5 Updated by dexter 2 months ago

  • File notes.txtMagnifier added
  • Status changed from New to In Progress

I have reviewed the change requests and created an overview to point out where messages had changed. See the attached file. Each line marked with a # indicates that there is a change that directly affects the message type (by adding/changing codings or adding elements).

#6 Updated by dexter 2 months ago

I have now reviewed the source code. When I get things correct, the following messages types have to be updated:

+ASSIGNMENT REQUEST        (BSS_MAP_MSG_ASSIGMENT_RQST, rx only, osmo_bsc_bssap.c)
+ASSIGNMENT COMPLETE        (BSS_MAP_MSG_ASSIGMENT_COMPLETE, gsm0808_create_assignment_completed())        test exists
+ASSIGNMENT FAILURE        (BSS_MAP_MSG_ASSIGMENT_FAILURE, gsm0808_create_assignment_failure())        test exists
+COMPLETE LAYER 3 INFORMATION    (BSS_MAP_MSG_COMPLETE_LAYER_3, gsm0808_create_layer3())                test exists

(+ means, message needs to be patched)

#7 Updated by dexter 2 months ago

We have now an encoder / decoder plus tests for "AoIP Transport Layer Address" and an encoder for "Speech Codec Element". (see also libosmocore.git pmaier/aoip)

When I get the osmo-bsc / libosmocore code and the spec right. Then we only need the following additional fields for the BSC case:
AoIP Transport Layer Address (MGW)
Codec List (MSC Preferred)
Call Identifier

Judging by the messages osmo-bsc can unsterstand, we would need generator functions for the following messages:

(I have attached some of my notes with some more details about what is missing)

#8 Updated by dexter 2 months ago

  • % Done changed from 10 to 20

Finished the implementation and the tests for the Codec List message element. Also started the integration. ASSIGNMENT COMPLETE, ASSIGNMENT FAILURE and COMPLETE LAYER 3 INFORMATION can now handle the Codec List field.

See also branch: pmaier/aoip

#9 Updated by dexter 2 months ago

  • % Done changed from 20 to 30

The create functions of the messages which are relevant in the bsc role are now extended and we should be able to send AoIP messages by now. Also added encoding/decoding for two more elements: gsm0808_channel_type (needed for ASSIGNMENT REQUEST). And gsm0808_encrypt_info (needed for BSS_MAP_MSG_CIPHER_MODE_CMD). The encoding function of these two will be needed to for the create functions that generate the MSC messages. The decoding will replace the hacks in osmo_bsc_bssap.c.

We still lack the GSM0808_IE_CELL_IDENTIFIER_LIST element. Once we have that, we can implement the missing create functions for the MSC role.

#10 Updated by dexter 2 months ago

  • % Done changed from 30 to 40

We can now handle GSM0808_IE_CELL_IDENTIFIER_LIST, to the extend which we need (whole BSS, or by a list of LACs). All other schemes are not yet supported (our BSC can't handle them anyway), but we can upgrade any time, if needed.

We are also now ready to generate BSS_MAP_MSG_PAGING and BSS_MAP_MSG_CIPHER_MODE_CMD messages. We still miss the support for BSS_MAP_MSG_ASSIGMENT_RQST, but I think I will finish this one during the day tomorrow. After that we are ready to make some changes to the BSC code. In my opinion we should first get rid of the decoding hacks, since we now have proper decoding utilities, we should use them.

#11 Updated by dexter 2 months ago

We now also can generate the assignment request. I have sent the patches now into the review process: gsm0808: Add utils for Speech Codec List and Speech Codec gsm0808: Add AoIP specific elements to gsm0808_create_... functions gsm0808: Add utils for Channel Type gsm0808: Add utils for Encryption Information gsm0808: Add utils for Cell Identifier List gsm0808: Add create functions for CIPHER MODE COMMAND gsm0808: Add create functions for BSS_MAP_MSG_PAGING gsm0808: Add create functions for BSS_MAP_MSG_ASSIGMENT_RQST

#12 Updated by dexter about 2 months ago

Started the integration of libosmo-sigtran into omso-bsc. To get a starting point I disabled the existing sccp-line code pathes and started to build up the interfaces for libosmo-sigtran next to it. When done, we can remove the no longer needed code.

There are some things where I am not sure if they can be removed, or if they have to work with the new code as well. There is this filter mechanism that seems to filter out unauthenticated connections. I think that will be handled directly by libosmo-sigtran in the future.

We also seem to have this strange feature that the BSC can be simultaniously connected to multipls MSC. To my understanding, this is not 100% standard conform. But since the infrastructure for this is now everywhere in the code. I think its easier when we just keep it.

For osmo-msc, I have started with some dummy MSC code to try out the BSSAP side on the MSC side. So far, the exchange of the RESET command is working fine. I can also make connections and can see the location update passing along together with CC and L3 Complete. It is not yet answered by my code, but It shows that most basic things are working. So we now should move on with integrating the dummy code into osmo-msc and see what happens when we forward the Location update into the MSC.

#13 Updated by dexter about 2 months ago

For osmo-bsc the most basic things should be done. We can connect to an msc and we can disconnect again. Connection contexts are created when the connection is opened and freed again when the connection closes. However. The mgcp side needs some attention now, but first some basic things like location update, imsi-detach and paging should work.

Started to integrate AoIP into osmo-msc. I have put my msc-dummy code into a_iface.c. The code does the reset handshake with the MSC and can receive Layer 3 complete messages. The code extracts the cell ID element and the Layer3 data element. I have tried to forward the code into the MSC, but I get a segfault (function bssmap_handle_l3_compl(), line rc = msc_compl_l3(conn, dtap_msg, 0);) here. Probably I am doing it wrong or something is not initialized properly.

Branches in openbsc.git:

#14 Updated by dexter about 1 month ago

  • % Done changed from 40 to 50

Apart from some AoIP messages that are still missing, the overall message passing between MSC and BSC works fine. Location update (without encryption!) works fine. I can attach phones and detach them again. Also the classmark change is already implemented.

The handling for the following messages is still missing:
BSS_MAP_MSG_CIPHER_MODE_COMPLETE (My guess is that I will have to detect the cipher mode command in the DTAP payload and then encapsulate it accordingly)

Branches in openbsc.git:

#15 Updated by dexter about 1 month ago

  • % Done changed from 50 to 60

Paging, Authentication and ciphering is working. Since paging is woring now, it is possible to send an SMS from one mobile to another.

The BSS_MAP_MSG_CIPHER_MODE_REJECT is parsed, no action is taken since I did not find the right hooks in the code where I could possibly deliver a cause code. All in all, this is a rare event. If encryption fails the whole call will fail too. Its probably enough to just print an error message?

So far the following is still missing:
BSS_MAP_MSG_SAPI_N_REJECT (should be simple)
BSS_MAP_MSG_ASSIGMENT_COMPLETE (setting up a call without audio should work without mgcp)

The code also still uses the simple-client/simple-server. I might need some hints on how to configure the STP

#16 Updated by dexter about 1 month ago

  • % Done changed from 60 to 70

The code now handles all BSSMAP messages that are relevant for us. However, the Assignment command is not complete yet. Currently the code sends a dummy assignment with some hardcoded parameters to the BSC. The assigment gets immediately rejedted with cause code 22 (no radio resource). This is expected. Next big task would be to get voice traffic going.

I have discussed the current status and the code with neels today. He will continue working on the A-Interface while I am on vacation. I have also updated my branches in openbsc.git:

#17 Updated by neels 6 days ago

#18 Updated by dexter 4 days ago

Status update:

  • The BSC can now receive AoIP transport identifiers via the assignment command. The contained IP/Port is forwared via IPACC/RSL to the BTS. The BTS will assign an RX port and return that back to the BSC. The BSC will than communicate that port back to the MSC via another AoIP transport identifier in the assignment complete message. However, this must be changed later. The BSC will get its own private MGCPGW. This will not change anything for the MSC side. The IP/Port negotiation and procedures will remain the same.
  • The MSC currently sends the IP of its attached MGCPGW. Since the MSC performs a CRCX operation before sending the assignment command, an RX-Port is already allocated and the port number is known. That IP/Port pair is forwarded to the BSC. (conn->iu.mgcp_rtp_port_cn). The BSC will then return with the IP/Port pair where the BTS expects the RTP input (conn->iu.mgcp_rtp_port_ue). This does not work. I think I am using the wrong struct members here.
struct gsm_subscriber_connection {
    /* which Iu-CS connection, if any. */
    struct {
        struct ue_conn_ctx *ue_ctx;
        int integrity_protection;
        unsigned int mgcp_rtp_endpoint;
        uint16_t mgcp_rtp_port_ue;
        uint16_t mgcp_rtp_port_cn;
        uint8_t rab_id;
    } iu;

My biggest question is what are mgcp_rtp_port_ue and mgcp_rtp_port_cn for? Am I correct (probably not) that mgcp_rtp_port_cn is the RX port at the MGCP, where the BTS has to send its data?. Is mgcp_rtp_port_ue the RX port at the BTS where the MGCPGW has to send its RTP stream to?

The logic that currently works for 3G should work for 2G as well.

#19 Updated by dexter 1 day ago

  • % Done changed from 70 to 80

There is good news: Made a successful voice call. I will now clean the current state a bit up and push it. We also still have to give the BSC its own MGCP.

#20 Updated by dexter 1 day ago

Current status can be found on branch: pmaier/aoip

Also available in: Atom PDF