More RTCPSent RTCPReceived documentation somewhere?

Asterisk Asterisk APIs
1

I have some questions about the stats in RTCPSent RTCPReceived AMI events that the wiki pages [1, 2] don’t seem to answer. If there is more documentation somewhere that gives more details how this data can be used in practice, please do share.

Am I understanding this right?

  • RTCPReceived with a 200 packet type is the phone reporting to Asterisk its statistics for the rtp audio stream from Asterisk to the phone.
  • RTCPSent with a 200 packet type is the Asterisk reporting statistics of the rtp audio stream from the phone to Asterisk.
  • To report on call quality in real-time, both are needed because there are two audio streams in the channel going in opposite directions, and each stream may take different routes to arrive at their destination.

Does the 201 packet type really just mean that the sender of the report hasn’t actually dealt with any packets? I’m not quite sure what I am supposed to do with the 201 packet type as someone who is trying to report to the end-user about network quality.

It seems like RFC 5760 tries to provision for reporting on multiple audio streams, and the ReportCount and ReportX* fields seem to allow for multiple reports, but did Asterisk actually implement code that will report on more than one? Under “Add support for multiple remote media sources” in the RTP task list there is a comment that seems to imply that we may not ever expect multiple audio sources on the same stream, so the author wasn’t quite sure what should be done. So, at this point with Asterisk, I should only really ever expect one report if there is one provided?

Is the RTT value in the RTCPReceived packet in response to a previous RTCPSent packet? Or is it something Asterisk is calculating from the timestamps from RTCPReceived alone?

RTT is a little bit confusing because ReportXDLSR is expressed in 1/65536 seconds as RFC 3550 says, and RFC 5760 says that RTT is expressed in 1/65536 seconds, but the wiki page seems to imply that RTT is a decimal second.

Does RTT on the RTCPReceived do the math to subtract the DLSR processing time already? Or is that time still included in RTT and I need to convert the 1/65536 from RTT to get the actual network latency? I understand that DLSR is basically the delay in processing CPU/memory/scheduling on the phone. For example, some of these old Polycom phones we use have 125MHz processors, so DLSR could represent quite a bit of time in addition to the actual network round-trip latency. That is, if the reply is immediate – the phone could just sit and wait for some other timeout before it decides to send the packet too.

Since there is a CumulativeLost, it is possible to calculate the fraction of lost packets for the entire call with SentPackets. That’s nice because FractionLost is just for the time since the last report packet. IAJitter is also only a snapshot since the last RTCP packet. I guess there isn’t a way to figure summarize Jitter for the entire call length with these events?

Any suggestions on how to use these stats in practice to report network reliability to the user in real-time are welcome.

Thanks.

1 Like
2

I’ve been trying to learn (reading the code) more about Asterisk and RTCP myself lately, so might be able to answer some of your questions.

Essentially correct, but as you’ve stipulated a 200 packet type (Sender Report) it’ll also contain some information with regard to the sender (phone in this case) like SentNTP, SentPackets, etc…

Same as above, but reversed.

Correct.

No, a 200 (Sender Report) is sent when the receiver has also itself sent packets since the last sent report. Otherwise a 201 (Receiver Report) is sent. From rfc3550#section-6.4:

RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender. The only difference between the sender report (SR) and receiver report (RR) forms, besides the packet type code, is that the sender report includes a 20-byte sender information section for use by active senders. The SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued.

As far as what you’d do with it (a 201), you would probably want to handle it similarly to the way you handle the 200.

For most user’s setups Asterisk currently only supports a single sourced negotiated audio stream. The source can change upon renegotiation, transfers, and possible during “RTP learning”. However, for security reasons the “RTP learning” phase is restricted by default (see the strictrtp option in rtp.conf. In any case if the source switches RTCP reports will then go to that new source.

Asterisk is calculating the RTT from the timestamps given in the received report.

Yes it subtracts the DLSR time when calculating RTT. RTT is calculated in Asterisk as follows:

RTT = Current Asterisk system time - LSR - DLSR

Where LSR (time since last sender report received) and DLSR (mentioned delay) are time values received in a report. The calculated RTT value is then converted to seconds, which is what gets reported in the AMI events.

From the limited information given in AMI event(s) it does not appear to contain accumulated jitter data. Your app would have to track this itself over time.

Hope that helps!

1 Like
3

You helped immensely! Thank you so much for your response to each of my questions!

4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.