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-extens…
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-…
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~