No MOS and RTT is reported by RTPengine in production

[Giovanni Jose]

Hello Sipwise

We are having an issue where the MOS and the RTT are not being shown on the production environment but these are being showed fine in the testing environment, the difference between prod and testing is the use of Asterisk as a UAS/UAC to test, but in production, we use the carriers/providers.

Bellow is the information about the issue (this was opened on github as well)

rtpengine version the issue has been seen with
mr13.2.1.1

Used distribution and its version
Debian 12

Expected behaviour you didn't see

Unexpected behaviour you saw

config used

[rtpengine]
interface=any
listen-ng=0.0.0.0:5050
timeout=60
silent-timeout=3600
tos=184
port-min=10000
port-max=20000
recording-dir=/var/spool/rtpengine
recording-method=proc
log-level=7
log-stderr=true
log-level-control=6
mqtt-host=mosquitto
mqtt-port=1883
mqtt-publish-qos=1
mqtt-publish-topic=rtpengine
mqtt-publish-interval=10000
mqtt-publish-scope=call
mos=LQ
measure-rtp=true

[Giovanni Jose]

The Images are broken, I'll post them here
Expected

Unexpected

[Richard Fuchs]

Perhaps Asterisk is sending RTCP and your carrier is not? You can check the reception packet stats to verify. If this is the case then you need to enable local RTCP generation.

Cheers

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/7d7ec671-952b-4b5a-9e7a-979d10ff5accn%40googlegroups.com.

[Giovanni Jose]

I did this change:

rtpengine_manage(label=vendor replace-origin replace-session-connection generate-RTCP ICE=remove loop-protect)

And still not MOS: {"timestamp":1748015204.5942349,"call_id":"155610415_67037234@","legs":[{"tag":"gK06657bec","label":"vendor","medias":[{"media_index":1,"type":"audio","interface":"default","protocol":"RTP/AVP","status":"sendrecv","address":"XX","port":22700,"ingress":{"bytes":212860,"packets":1243,"errors":0,"SSRC":[{"SSRC":2007648303,"codec":"PCMU","clock_rate":8000,"codec_params":"","codec_format":"","metrics":{"packets":1243,"bytes":212860,"lost":0,"duplicates":0,"packets_per_second":0.0,"bytes_per_second":0.0,"lost_per_second":0.0,"duplicates_per_second":0.0,"jitter":0.0}}]},"egress":{"bytes":176472,"packets":1026,"errors":0,"SSRC":[{"SSRC":3924492794,"codec":"PCMU","clock_rate":8000,"codec_params":"","codec_format":"","metrics":{"packets":1026,"bytes":176472,"lost":0,"duplicates":0,"packets_per_second":0.0,"bytes_per_second":0.0,"lost_per_second":0.0,"duplicates_per_second":0.0,"jitter":0.0}}]}}]},{"tag":"3yaS37UFj0j9m","label":"customer","medias":[{"media_index":1,"type":"audio","interface":"default","protocol":"RTP/AVP","status":"sendrecv","address":"XX","port":23324,"ingress":{"bytes":176472,"packets":1026,"errors":0,"SSRC":[{"SSRC":3924492794,"codec":"PCMU","clock_rate":8000,"codec_params":"","codec_format":"","metrics":{"packets":1026,"bytes":176472,"lost":0,"duplicates":0,"packets_per_second":0.0,"bytes_per_second":0.0,"lost_per_second":0.0,"duplicates_per_second":0.0,"jitter":0.0}}]},"egress":{"bytes":212860,"packets":1243,"errors":0,"SSRC":[{"SSRC":2007648303,"codec":"PCMU","clock_rate":8000,"codec_params":"","codec_format":"","metrics":{"packets":1243,"bytes":212860,"lost":0,"duplicates":0,"packets_per_second":0.0,"bytes_per_second":0.0,"lost_per_second":0.0,"duplicates_per_second":0.0,"jitter":0.0}}]}}]}]}  

[Richard Fuchs]

On 23/05/2025 11.56, Giovanni Jose wrote:

I did this change:

rtpengine_manage(label=vendor replace-origin replace-session-connection generate-RTCP ICE=remove loop-protect)

And this was done for both sides?

Again inspect the packet stats to see what's going on. (MQTT doesn't produce stats about RTCP, check the log or use rtpengine-ctl, or even better Wireshark it.)

Cheers

[Giovanni Jose]

Hello Richard

I was able to test with Asterisk on both sides and everything worked fine, but when I did the real testing with the carriers, I got no RTCP In the screenshot is the packet capture (number 1 is the test with Asterisk and number 2 is the test with the carriers)

In my settings, I am using LQ and as the documentation states, " If set to LQ (listening quality) RTT is ignored, allowing a MOS to be calculated in the absence of RTCP.  " In this case, the MOS should be calculated, but it is not doing it. Is this feature broken or not functional? Or what should we do to calculate the MOS in the absence of RTCP

[Richard Fuchs]

On 28/05/2025 12.33, Giovanni Jose wrote:

Hello Richard

I was able to test with Asterisk on both sides and everything worked fine, but when I did the real testing with the carriers, I got no RTCP In the screenshot is the packet capture (number 1 is the test with Asterisk and number 2 is the test with the carriers)

In my settings, I am using LQ and as the documentation states, " If set to LQ (listening quality) RTT is ignored, allowing a MOS to be calculated in the absence of RTCP.  " In this case, the MOS should be calculated, but it is not doing it. Is this feature broken or not functional? Or what should we do to calculate the MOS in the absence of RTCP

You enable local RTCP generation.

If you don't see rtpengine sending RTCP then most likely there's something wrong with your signalling and you don't actually have RTCP generation enabled (or there hasn't been any RTP). We do have tests for this so I would be very surprised if there's something broken.

Enable debug logging to see which flags are actually coming across, and also when and if RTCP is being sent. You can also use the "query" command to inspect which flags are active on a running call.

Cheers

[Giovanni Jose]

Hello Richard,

I have a question, if one of the legs is not coming with RTCP traffic, the statistics are not going to be generated? I mean, the condition that we need for us to have the statistics is to have RTCP in both legs of the call? 

[Richard Fuchs]

On 02/06/2025 18.31, Giovanni Jose wrote:
> Hello Richard,
>
> I have a question, if one of the legs is not coming with RTCP traffic,
> the statistics are not going to be generated? I mean, the condition
> that we need for us to have the statistics is to have RTCP in both
> legs of the call?

With LQ MOS you can have one-sided RTCP and you should get one-sided
statistics.

Cheers

[Giovanni Jose]

Ok so is there any way to debug besides the RTPengine logs? I mean it's not showing the statistics, or if you could help me on what I need to provide you to show you that something is not working correctly since I am using the LQ options and is not doing what it suppose to do according to the documentation

On my last testing on one Leg I am getting RTCP and in the other Leg I am not receiving RTCP and I am not getting any statistics (this is the prod scenario) and in the staging scenario both Legs are receiving RTCP and I am getting the statistics.

Regards 

Gio

[Richard Fuchs]

On 03/06/2025 11.13, Giovanni Jose wrote:
> Ok so is there any way to debug besides the RTPengine logs? I mean
> it's not showing the statistics, or if you could help me on what I
> need to provide you to show you that something is not working
> correctly since I am using the LQ options and is not doing what it
> suppose to do according to the documentation
>
> On my last testing on one Leg I am getting RTCP and in the other Leg I
> am not receiving RTCP and I am not getting any statistics (this is the
> prod scenario) and in the staging scenario both Legs are receiving
> RTCP and I am getting the statistics.

Post a concrete example that can be reproduced. Ideally a pcap that
contains all the RTP and RTCP, full debug log, full config, and the
exact version you're using.

Cheers

[Richard Fuchs]

Every packet in these pcaps has a length of zero.

On 03/06/2025 19.22, Giovanni Jose wrote:

Hello Richard

Attached are the logs with the non-working scenario

Version: mr13.2.1.1 [rtpengine] interface=IP!PublicIP.226 listen-ng=0.0.0.0:5050 timeout=60 silent-timeout=3600 tos=184 endpoint-learning=heuristic port-min=22000 port-max=32000 recording-dir=/var/spool/rtpengine recording-method=proc log-level=7 log-stderr=true log-level-control=7 mos=LQ measure-rtp=true rtcp-interval=5000
The scenario is:  carrier -> rtpengine -> asterisk

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/rtpengine/167b7508-8118-4e55-b63f-5b497d4ba756n%40googlegroups.com.

[Richard Fuchs]

This isn't a build without transcoding support by any chance, is it?

On 03/06/2025 19.22, Giovanni Jose wrote:

Hello Richard

Attached are the logs with the non-working scenario

Version: mr13.2.1.1 [rtpengine] interface=IP!PublicIP.226 listen-ng=0.0.0.0:5050 timeout=60 silent-timeout=3600 tos=184 endpoint-learning=heuristic port-min=22000 port-max=32000 recording-dir=/var/spool/rtpengine recording-method=proc log-level=7 log-stderr=true log-level-control=7 mos=LQ measure-rtp=true rtcp-interval=5000
The scenario is:  carrier -> rtpengine -> asterisk

On Tuesday, June 3, 2025 at 11:37:58 AM UTC-7 rfuchs wrote:

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/rtpengine/167b7508-8118-4e55-b63f-5b497d4ba756n%40googlegroups.com.

[Giovanni Jose]

Hello Richard

Compiling with transcoding support did the trick!

Thanks for your help, Richard!!

You can close this thread