Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

Ok, as was recommended by Neels:

(20:42:13) neels: pespin_, for after lunch, you should familiarize yourself with the 'codec-list'
vty config anyway. osmo-bsc enforces a set of voice codecs, and if you don't allow them, it will
just reject them. As I said, osmo-bsc.cfg, under 'msc' (which is a bit weird place as far as I'm
concerned, would have expected it under 'bts' instead)

I've added missing 'codec-list' directive to the OsmoBSC configuration:

msc 0
  codec-list hr1 hr2 hr3 fr1 fr2 fr3
  ...

But got some errors on the OsmoMGW side:

...
<0000> mgcp_network.c:837 endpoint:0x2 packet tossed
<0000> mgcp_network.c:833 endpoint:0x2 data from wrong address: 127.0.0.1, expected: 0.0.0.0
...

And then, finally a call was established, but only in one direction :)
In other words, the called subscriber accepted the call, but the calling
subscriber was still waiting for connection, producing long beeps...

The new PCAP-trace of LAPDm, RSL, and GSMTAP_LOGS (with logs of both MSC and MGW) is attached.

YOu seem to have configured "codec-list hr1 hr2 hr3 fr1 fr2 fr3", but looking at osmo_bsc_vty.c:

        vty_out(vty, " codec-list ");
        for (i = 0; i < msc->audio_length; ++i) {
            if (i != 0)
                vty_out(vty, " ");

            if (msc->audio_support[i]->hr)
                vty_out(vty, "hr%.1u", msc->audio_support[i]->ver);
            else
                vty_out(vty, "fr%.1u", msc->audio_support[i]->ver);
        }

So it seems it doesn't expect to have both hr and fr for the same version in the config?

EDIT: Nevermind, it seems they are stored in different indexes ;)

So it seems it doesn't expect to have both hr and fr for the same version in the config?

I doubt that. And if this is really the case, then it's a very obvious bug.

Tested with all TCH/F timeslots and the following directive:

msc 0
  ...
  codec-list fr1 fr2 fr3

No changes. So, there is no bug here.

What really looks strange for me (but probably unrelated):

...
<0000> gsm_04_08.c:3475 MSISDN:11996: Discarding duplicate L3 message
...

Also, I am attaching PCAP-traces of BSSMAP. Please note that MSC assign failure
happens even before the called subscriber is paged o_O (log file is attached).