Hi Sadanand,

I was going through libosmo-abis codebase to understand how it handles \x93Rtp to Trau\x94 and vice-versa GSM-EFR conversions. I was able to find \x93RTP to Trau\x94 and \x93Trau to Rtp\x94 conversion code of EFR speech frames, but could not find anything related to EFR SID (silence) frames.

In the most common scenarios of TRAU to RTP interworking, for both FR1 and EFR codecs (the only ones I am sufficiently familiar with at the moment), there is generally no need to differentiate between speech and SID frames:

* When you are converting from TRAU to RTP in the UL direction, you simply ignore the SID classification bits provided by the CCU (in C13 and C14 bit positions) and always pack the payload (Dn) bits into the RTP frame of ETSI TS 101 318. The actual speech transcoder (the real TRAU, so to speak) on the receiving end of the RTP stream will need to reconstruct these SID classification bits (for its Rx DTX handler function) from the payload per the rules of section 6.1.1 of GSM 06.31 for FR1 or GSM 06.81 for EFR; same section in both specs.

* When you are converting from RTP to TRAU in the DL direction, the critical question becomes: is DTX-DL enabled or disabled? If DTX-DL is disabled, like it MUST be if your GSM cell has only one ARFCN, then the remote speech encoder at the far-source end of the RTP stream MUST be configured to operate in no-DTX mode, and all FR1 or EFR frames it will emit are going to be speech frames, no SID. In this case the SP bit (C16) in the TRAU DL frame must always be set to 1, and that's exactly what osmo_rtp2trau() function in libosmo-abis does currently.

* The only case which osmo_rtp2trau() does not handle currently is the case where DTX-DL is allowed (because you have a multi-TRX cell with more carriers than just C0) and you have configured your speech encoder (non-Osmocom software required for this function) to operate in DTX mode. In this case the RTP stream generated by this DTX-enabled speech encoder will contain both speech and SID frames, and by the rules of GSM 06.31 and 06.81, the SP flag (carried in bit C16 in TRAU-DL) needs to be 0 when the payload is SID rather than speech. osmo_rtp2trau() fails to do the last part: to be 100% correct, it would need to check the payload (FR1 or EFR) for SID and set the SP bit accordingly, but it doesn't do that last part currently.

Adding the just-described SID logic to osmo_rtp2trau() would be quite easy:

1) Add a function to libosmocore that would be just like osmo_fr_check_sid(), but for EFR;

2) Add the SID logic to osmo_rtp2trau() in libosmo-abis, using osmo_fr_check_sid() for FR1 and the new function for EFR.

I would be happy to submit Gerrit patches doing 1 and 2 above, *iff* there is at least one person on Earth (OP or anyone else) who would find them useful.

However, distinguishing between speech and SID frames in the one case where they do need to be distinguished is the easy part; handling of bad or missing frames (BFI=1 in the framework of GSM 06.31 & 06.81) is the part where current industry standards for RTP transport of GSM- encoded speech (created before Osmocom, to the best of my knowledge) simply suck. Please read my rant on this subject here:

https://www.freecalypso.org/hg/themwi-system-sw/file/tip/doc/RTP-BFI-extensi...

I have a patch to osmo-bts-sysmo (very hacky, not suitable for merging or even for submission to Gerrit) that implements my RTP BFI extension hack:

https://www.freecalypso.org/hg/themwi-system-sw/file/tip/osmo-patches/osmo-b...

I currently run with this patch on my BTS, and it works for me - but of course sysmoBTS is a native Ethernet/RTP BTS, thus osmo-bts patches (mine or anyone else's) won't help you (OP) if you've got an E1-based BTS and you are interfacing to TRAU frames with osmo-mgw. I haven't looked at E1 TRAU code in osmo-mgw yet, I've only looked at libosmo-abis code as prompted by your post, but my preliminary impression is as follows:

* In the UL direction, if the behaviour of osmo-mgw upon getting an idle or BFI=1 speech frame from the BTS is the same as the behaviour of osmo-bts under equivalent conditions, then your speech transcoder on the receiving end of the RTP stream will likely have the same problem I ran into, as described in my rant linked above.

* In the DL direction, I do see a problem in osmo_rtp2trau() that can be fixed with a patch. GSM 08.60 sections 4.5.2 and 4.5.3 say: "If no speech is received from the MSC side of the interface (downlink direction), idle speech frames shall be transferred instead of speech frames." - however, the code in osmo_rtp2trau() fails to obey this requirement, instead it sends TRAU speech frames with garbage payload when the rtp_len argument to the function is 0, indicating missing speech data. Once again, I would be happy to produce a patch fixing this bug if someone (OP or anyone else) would like to see one.

M~