As ZuluAlpha said, the MBG is most likely the SRC. On the MiVoice Business, by default the signalling and audio on Minet sets are encrypted. Call recording equipment (CRE) need something to tap in to the calls and send them (the CRE) the unencrypted audio and signalling data. This is what the SRC service on the MBG does. Phones are supposed to register to the MBG instead of the MiVB. If you look at the DHCP options, option 125 probably has the MBG's IP as the call server instead of the MiVB. Alternatively, one can put a set in teleworker mode using the MBG's LAN IP. The CRE talks to the MBG and directs it which phones to record. Then, the MBG will send the audio and signalling data to the CRE.
Since the primary lines are being recorded correctly, we can say that the connection between the MBG and CRE is fine. Also, we know that the phones are talking to the MBG instead of the MiVB. My guess is that something isn't configured correctly for the secondary extensions in the CRE.
I have worked on a few call recording deployments, but only on the MiVB and MBG servers. The CRE was third party, and the third party handled all configuration on the CRE. All I had to do was set the phones (that need to be recorded) to talk to the MBG. I also had to accept a request from the CRE and make sure that the MBG had the recording service enabled. The CRE does the rest. It even tells the MBG where to send the recordings. One time the third party changed the CRE's ip address, but didn't update a field that tells the MBG where to send audio. After that, call audio wasn't showing up in the CRE. The third party was blaming us, but in the end the MBG was just doing what the CRE was telling it to do which was to send the audio to the old ip address.