Project

General

Profile

Bug #3241

Failed MS <-> MS call assignment

Added by fixeria 4 months ago. Updated 1 day ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/06/2018
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

There are only two subscribers:

  #1 IMSI: 001010000011996, MSISDN: 11996
  #2 IMSI: 262423403001393, MSISDN: 01393

Please have a look at 'call.pcapng.gz' attached to this issue:

  #118: Subscriber 01393 initiates a call to 11996,
        by sending CM Service Request on established channel;
  #227: The network accepts this request,
        by sending CM Service Accept;
  #230: Subscriber 01393 sends SETUP to 11996
  #427: The network responds with Call Proceeding message;
  #447: The network initiates paging of subscriber 11996,
        by sending Paging Request Type 1;
  #475: Subscriber 11996 responds by sending Paging Response;
  #600: The network informs subscriber 11996 about an incoming call,
        by sending SETUP message;
  #611: Subscriber 11996 confirms this call,
        by sending Call Confirmed message;

  ...

  #667: OsmoMGW fails to send a dummy RTP packet...
  #710: OsmoMGW fails to send a dummy RTP packet...

  ...

  #758: The MSC indicates assignment failure

  ... Both SDCCH channels remain open for some long time ...

  #1488: Subscriber 01393 sends Disconnect message,
         due to "(102) Recovery on timer expiry";
  #1584: Subscriber 11996 sends Disconnect message,
         due to "(102) Recovery on timer expiry";

  ... Both SDCCH channels remain open for some long time ...

I am running a single OsmoMGW instance, both BSC and MSC
are configured to use it, configuration files attached.

call.pcapng.gz call.pcapng.gz 80.6 KB fixeria, 05/06/2018 02:47 PM
osmo-msc.cfg osmo-msc.cfg 1.94 KB fixeria, 05/06/2018 02:47 PM
osmo-bsc.cfg osmo-bsc.cfg 4.66 KB fixeria, 05/06/2018 02:47 PM
osmo-mgw.cfg osmo-mgw.cfg 512 Bytes fixeria, 05/06/2018 02:47 PM
call_one_side.pcapng.gz call_one_side.pcapng.gz 3.14 MB fixeria, 05/07/2018 02:20 PM
call_bssmap.pcapng.gz call_bssmap.pcapng.gz 1.38 KB fixeria, 05/07/2018 06:11 PM
osmo_msc.log osmo_msc.log 76 KB fixeria, 05/07/2018 06:16 PM

History

#1 Updated by fixeria 4 months ago

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.

#2 Updated by pespin 4 months ago

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 ;)

#3 Updated by laforge 4 months ago

On Mon, May 07, 2018 at 02:36:25PM +0000, pespin [REDMINE] wrote:

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.

#4 Updated by fixeria 4 months ago

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).

#5 Updated by laforge about 2 months ago

  • Assignee set to dexter

#6 Updated by dexter 1 day ago

  • Status changed from New to Resolved

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)