Hi Christian, I have a NanoBTS 165G with similar firmware (168d472_v200b411d0), and I am able replicate both your issue and workaround exactly. I think I have a fix - although I will caution that my first deployment of the Osmocom stack is under two weeks old, so I don't yet know what I don't know! Here's my take: Suspected bug: The general problem seems to be that when a channel is released before a phone has established a connection on it then the NanoBTS does not remove the RTP connection. The non-establishment is inferred by the absence of a EST IND message, and the non-removal by the absence of an DLCX IND message. That may not hold to be true, but so far as I know there is no way to peek inside the NatoBTS to see its state. In this scenario, I find every subsequent CRCX that gets mapped to that timeslot is NACK'd with cause 0x52. That code appears to be vendor-specific and isn't documented anywhere I could find. 0x50 seems to be "Radio channel already allocated", so it doesn’t seem a totally bananas working assumption to take 0x52 to mean "There's already an RTP connection associated" As we've both found, a reliable trigger for the bug is to call a number that is not attached. Proposed fix: Track whether the BTS holds an RTP connection for an lchan: - Set on CRCX ACK - Clear on DLCX IND, DLCX ACK, DLCX NACK, and by lchan_reset(). And if it is still set when sending RF Channel Release to a NanoBTS, then send a DLCX for the connection first - on the same RSL link - so that it handles it before the release. So far as I can find in the codebase, osmo-bsc has never sent a DLCX. As such, my instinct says we're working around a NanoBTS bug and it really should be responsible for the clean-up. Certainly, the OsmoBTS (gsm_lchan_release - lines 213-226 in lchan.c) handles clean-up itself and I guess that is the principal development target. Testing: I've implemented this in a very inelegant way in a lab setup but the good news is have not yet been able to get a timeslot "stuck" in testing! I am conscious that I've assumed a 1:1 mapping between channel and timeslot - so testing with half-rate channels might yet break things. Given the observation above re. OsmoBTS, there probably needs to be some handling around the BTS type. I've no idea what bugs this might introduce otherwise, either for other BTS types or NanoBTS on earlier firmware revisions. Separately, I am also working on what I think is a possible bug related to timing advance with NanoBTS units, which also results in dropped calls but with a different behaviour. I plan to keep testing and hopefully submit a coherent patch, but would certainly welcome any comments in the meantime. All the best, Alistair