Project

General

Profile

Actions

Bug #2634

closed

OsmoBSC apparently sends CRCX a second time, after MDCX has already happened

Added by neels over 6 years ago. Updated over 6 years ago.

Status:
Rejected
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
11/10/2017
Due date:
% Done:

0%

Spec Reference:

Description

In the attached trace, each call leg gets a sequence of CRCX in loopback, MDCX to sendrecv, and then another CRCX in sendrecv mode.
That's weird. Can you reproduce it, and if yes fix it?


Files

osmo-bsc-crcx-twice.txt osmo-bsc-crcx-twice.txt 11.6 KB neels, 11/10/2017 02:25 AM
osmo-bsc-crcx-twice.pcapng osmo-bsc-crcx-twice.pcapng 2.95 KB neels, 11/10/2017 02:25 AM
Actions #1

Updated by neels over 6 years ago

  • Priority changed from Normal to High
Actions #2

Updated by neels over 6 years ago

  • Status changed from New to Feedback

Argh ok, one is for connection identifier 1, the other is for connection identifier 2.
But shouldn't the second Connection Identifier be CRCX'd before putting the first one into sendrecv mode?

  • CRCX CI 1 in loopback
  • CRCX CI 2 in sendrecv
  • MDCX CI 1 to sendrecv

or maybe even

  • CRCX CI 2 in sendrecv (the one towards MSC, where there is another MGW in loopback already)
  • CRCX CI 1 in sendrecv (the one towards BTS)

As it is now, the CI 1 (towards BTS) is first put in sendrecv, but at that point there is no other end to pass RTP through to yet.

This might be a non-issue ... what do you think?

Actions #3

Updated by dexter over 6 years ago

  • Assignee changed from dexter to neels

I have checked the trace. It looks ok to me. 1025@mgw and 1026@mgw are two endpoints of two separete connections. Then there is one 2@mgw which where we see the establishment of the leg that points towards the MSC. So this looks good to me.

Switching the connection from loopback to sendrecv before making the connection towards the MSC should not be a problem. We might loose some RTP packets between the MDCX and the CRCX since if we are in sendrecv and the MGW fails to find the partner connection it will toss the packet internally. I would keep it like it is since resolving this would mean that we have to restructure the FSM, which could introduce new bugs.

Actions #4

Updated by neels over 6 years ago

  • Status changed from Feedback to Rejected

I'd have thought it is nicer to "open the lane" once it is connected properly without dropping packets, and that combining a CRCX+MDXC into just a single CRCX would make sense ... but I accept that it's not worth the effort until an actual problem arises. After all the MGCP comm is going down rather quickly anyway.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)