Project

General

Profile

Actions

Bug #2782

closed

OsmoBSC sends BSSMAP ASSIGNMENT COMPLETE before RSL MODE MODIFY succeeds

Added by laforge over 6 years ago. Updated almost 5 years ago.

Status:
Rejected
Priority:
Low
Assignee:
Category:
A interface
Target version:
-
Start date:
12/23/2017
Due date:
% Done:

0%

Spec Reference:

Description

OsmoBSC sends the BSSMAP ASSIGNMENT COMPLETE when it receives the RR CHANNEL MODE MODIFY ACK from the MS, but before it has successfully modified the mode on the BTS side.

See attached protocol trace snippet.


Files

ass_compl_too_early.pcapng ass_compl_too_early.pcapng 1.08 KB laforge, 12/23/2017 01:01 AM
Actions #1

Updated by laforge about 6 years ago

  • Assignee set to dexter
Actions #2

Updated by dexter about 6 years ago

In Theory this can still happen with the GSCON FSM. I suspect the reason for this is that we make the FSM depended on the S_ABISIP_MDCX_ACK in osmo_bsc_audio.c and that S_ABISIP_MDCX_ACK arrives earlyer than the MODE MODIFY REQuest.

When S_ABISIP_MDCX_ACK arrives an GSCON_EV_RR_ASS_COMPL is generated in osmo_bsc_audio.c. The FSM is then expected to be in ST_WAIT_ASS_CMPL.

There is also a second location where GSCON_EV_RR_ASS_COMPL can be sent. This is when GSM48_MT_RR_CHAN_MODE_MODIF_ACK arrives in bsc_api.c and the bsc_assign_compl() in osmo_bsc_api.c runs. This looks completely correct. In order to resolve this, the RR assignement and the IPACC RTP negotiation should be untangled and the sending of GSCON_EV_RR_ASS_COMPL should be removed. This should solve the problem cleanly.

Actions #3

Updated by dexter almost 5 years ago

  • Status changed from New to Rejected

This ticket refers to an older implementation. Meanwhile the assignment process is reinforced by various state machines and the described behavior should no longer appear.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)