I have a Freeswitch system which receives a lot of DTMF.
When trying to track down some call quality issues I noticed a lot of sub 4.0 MOS calls reported by an upstream RTCP tool. A lot of analysis showed that there was a "lost" packet every time a DTMF was processed. These would accumulate and be reported back via RTCP as lost packets which would drop the MOS score.
It turned out to be some systems (including Freeswitch) send a mark bit on the start of the voice after the DTMF packets (marking the start of talkspurt). This results in "do_flush" being called (my case had no jitterbuffer) and the packet is flushed, however this is marked in RTCP stats as lost.
Arguably these are not lost packets as the network provided them to Freeswitch, it just decided not to use them. Call quality wasn’t impacted so the low MOS score is spurious and in my case hides real call quality issues behind a large number of phantom low MOS calls.
I could have turned on IGNORE_MARK_BIT but that would stop other uses of the mark bit for hold/etc. it seemed like a very blunt instrument.
I could have used a jitterbuffer which bypasses the flush but all my calls are bridged and I felt that introduced potential delay for a reporting problem.
The solution I am proposing (PR to follow) is that there is an RTP bug flag called RTP_BUG_DONT_REPORT_FLUSHED_AS_LOST which would default to false so as to not affect anyone's existing reporting.
It is a small change to the RTCP reporting function which removes the number of flushed packets from the lost count if the flag is true.
I have a Freeswitch system which receives a lot of DTMF.
When trying to track down some call quality issues I noticed a lot of sub 4.0 MOS calls reported by an upstream RTCP tool. A lot of analysis showed that there was a "lost" packet every time a DTMF was processed. These would accumulate and be reported back via RTCP as lost packets which would drop the MOS score.
It turned out to be some systems (including Freeswitch) send a mark bit on the start of the voice after the DTMF packets (marking the start of talkspurt). This results in "do_flush" being called (my case had no jitterbuffer) and the packet is flushed, however this is marked in RTCP stats as lost.
Arguably these are not lost packets as the network provided them to Freeswitch, it just decided not to use them. Call quality wasn’t impacted so the low MOS score is spurious and in my case hides real call quality issues behind a large number of phantom low MOS calls.
I could have turned on IGNORE_MARK_BIT but that would stop other uses of the mark bit for hold/etc. it seemed like a very blunt instrument.
I could have used a jitterbuffer which bypasses the flush but all my calls are bridged and I felt that introduced potential delay for a reporting problem.
The solution I am proposing (PR to follow) is that there is an RTP bug flag called RTP_BUG_DONT_REPORT_FLUSHED_AS_LOST which would default to false so as to not affect anyone's existing reporting.
It is a small change to the RTCP reporting function which removes the number of flushed packets from the lost count if the flag is true.