Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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?

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.

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.