Bug #3241
closedFailed MS <-> MS call assignment
0%
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.
Files
Updated by fixeria almost 6 years ago
- File call_one_side.pcapng.gz call_one_side.pcapng.gz added
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.
Updated by pespin almost 6 years 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 ;)
Updated by laforge almost 6 years 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.
Updated by fixeria almost 6 years ago
- File call_bssmap.pcapng.gz call_bssmap.pcapng.gz added
- File osmo_msc.log osmo_msc.log added
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).
