Sounds like frame slips on a TDM circuit. It could be a DS3 or DS1, doesn't really matter, the principle is the same. For example, on an ISDN PRI (T1):
2 pairs of copper wires using Time Division Multiplexing create 24 digital channels of 64Kbps: 23B channels (call bearer audio) + 1 D channel (call signalling).
This is very time sensitive, so if the clocks are incorrectly set (both in free run / not synchronized), this will happen all the time; in other cases defective equipment or noise on the line (noise is on the copper circuit, not the digital channel)(a technician connecting a test set or toner on a T1 is a common cause), it can cause all of the channels to shift one or more channels. So the audio on channel 1 is now connected to channel 2 at the opposite end, etc.
This state will last for a short while until the D channel becomes angry as it is now receiving jibberish and disable the circuit with a yellow alarm as both sides think the remote is at fault.
If more circuits are available, your second call should proceed fine and the technicians at both ends will have an alarm and will need to reset the circuit if there isn't an automatic mechanism to do so.
So nothing to worry about unless it happens all of the time, but this will definitely generate log events.
DS1 clocks are not required to be synchronized, they are interleaved into DS3 with lossless bit-stuffing.
When there is a loss of frame sync, signalling channels are inhibited. There's no transient synchronization recovery condition where channels are misaligned, the frame sync must be recovered first, and when it's recovered, all channels are correctly aligned. I used to design this equipment. I'm afraid this explanation is not correct.
It's more likely a software issue in the protocol stack that negotiates and control the switching fabric.
I work in telecoms and specialized in development and testing of TDM for almost a decade. I never saw clock slip manifest itself as a whole channel shift. The drift occurs at bit level, not in chunks of 8 bits. The elastic buffers in the phy protect against behavior and if they overflow due to a persistent drift it only results in a click in the channel.
No offense, but it sounds like you're just throwing around terms you don't really understand.
Frame slips won't cause an audio misconnect like this, because... well, lots of reasons. The channel layout (23B, 1D) you describe isn't TDM, it's PRI (primary rate interface). Slips occur at a lower layer; the T-carrier.
All T-carrier based telecommunications systems transmit at a fixed frequency. Even when the circuit is idle, a stream of bits are transmitted across the line, so that both ends remain in sync. A loss in synchronization is called a slip. That much you got correct.
These circuits are digital though. When a slip occurs, it's not as if whole frames jump from one to the next. What happens when you perform a binary shift on a chunk of data? The outcome is wildly unpredictable. The protocols at higher layers (like PRI) have mitigation strategies for dealing with slips. A re-sync occurs almost instantaneously. A T-carrier circuit that slips regularly will not be reliable. Based on my experience, persistent frame slips result in either a dropped call (B-channel reset), or garbled audio (due to shifted bits in the media [1]). If you've ever been on a call, and the audio suddenly becomes a garbled mess that sounds like a mix of modem communication and alien speech, that's what bit-shifted media sound slike.
I have never seen a misconnect caused by a slip. I suppose it's possible, but the likelihood would seem extremely remote. Imagine if you Base64 encoded something, performed a single binary shift, and the Base64 decoded result turned out to be the lyrics of the Star Spangled Banner. Unlikely.
To top it all off PRI is virtually non-existent within carriers. PRI is an end-user interface. You only see it in the last mile. Carriers use protocols like SS7, which you'll never see on end-user equipment. Even SS7 is less common these days, because the vast majority of telephone calls aren't TDM over the long haul any more. In the early 2000's, over half of the long distance calls in the US were VoIP. I'm not in the business any more, but I'm certain that percentage is much higher today. Ever since the long haul went fiber, carriers have been moving away from TDM.
Sorry to be such a pedant, but this is a real rabbit hole of a discussion that won't be solved with a basic understanding of DS1/PRI circuits.
[1]: Phone calls are broken down in to two parts. Media is what telecom people call the audio that is transmitted. It is distinct from signaling, which is the information used to set up and tear down calls.
This is very time sensitive, so if the clocks are incorrectly set (both in free run / not synchronized), this will happen all the time; in other cases defective equipment or noise on the line (noise is on the copper circuit, not the digital channel)(a technician connecting a test set or toner on a T1 is a common cause), it can cause all of the channels to shift one or more channels. So the audio on channel 1 is now connected to channel 2 at the opposite end, etc. This state will last for a short while until the D channel becomes angry as it is now receiving jibberish and disable the circuit with a yellow alarm as both sides think the remote is at fault. If more circuits are available, your second call should proceed fine and the technicians at both ends will have an alarm and will need to reset the circuit if there isn't an automatic mechanism to do so. So nothing to worry about unless it happens all of the time, but this will definitely generate log events.