[Asterisk-Dev] IAX2 Receiver Reports

[Steve Kann]

A proposal for IAX2 receiver reports:

The idea of receiver reports is to allow call quality monitoring for 
IAX2 calls.  By having receivers monitor quality (presumably through a 
jitterbuffer), and report network conditions back to senders, each side 
of the call should have a relatively complete picture of what the entire 
call looks like.

Presently, IAX2 gets a good idea of network Round-Trip time by sending 
PING frames to the remote side, and getting PONG frames back.

Also, LAGRQ frames are presently sent to the remote side, in order to 
get an idea of the Round-Trip + playout(jitterbuffer) delay.  The 
implementation of LAGRQ is presently a bit broken, because they 
currently go through the jitterbuffer on _both_ the sender and receiver 
side, and the timestamps used to do this are wrong.  (actually, I 
haven't checked this recently, but it was the case).

I propose:

1) Eliminating LAGRQ frames altogether.  I think this system will be 
more accurate anyway.

2) Adding the following IEs to PONG frames returned in response to PING 
frames (or, we could add this information to the PING frames; it doesn't 
matter, really:

#define IAX_IE_RR_JITTER                        42              /* 
Received jitter (as in RFC1889) u32 */
#define IAX_IE_RR_LOSS                          43              /* 
Received loss (high byte loss pct, low 24 bits loss count, as in rfc1889 */
#define IAX_IE_RR_PKTS                          44              /* 
Received frames (total frames received) */
#define IAX_IE_RR_DELAY                         45              /* Max 
playout/jb delay for received frames (in ms) u16 */


The Jitter IE would be the presently measured jitter.  I've defined it 
here to be compatible with the RFC1889 (RTCP) measurement, but the 
mechanics of measuring it aren't that important, as long as it is 
measured in milliseconds.

The Loss IE contains two numbers packed in a 32 bit field, as in 
RFC1889.  The high 8 bits represent the percentage loss since the last 
RR was sent (i.e. the last PING or PONG).   The low 24 bits represent 
the total number of lost frames since the beginning of the call.  (this 
number may go down, of course, if packets presumed lost are received 
after the RR is sent).

i.e.:  IAX_IE_RR_LOSS = ((loss_pct & 0xff) << 24) & (loss_cnt & 0x00ffffff);

IAX_IE_RR_PKTS is the total number of IAX2 packets received during the 
present IAX2 call.  (therefore, loss_cnt / IAX_IE_RR_PKTS is the 
fraction of lost packets for the whole call).

IAX_IE_RR_DELAY is the maximum playout(jitterbuffer) delay that a 
received frame is expected to face, given that the received frame falls 
into the present jitter window.   A sender should be able to report that 
the total one-way "lag" between when it injects an audio frame into the 
network, and when it is rendered at the receiver's side, is less than or 
equal to the calculated round-trip time, plus this delay.  (Generally, 
it would be less than or equal to 1/2 RTT plus this delay, but it's 
difficult to determine one-way transit time).

================

How this information may be used:

An endpoint would then have the following useful information;

Jitter[In/Out], Loss[In/Out], Lag[In/Out], RTT


You could store this information, and monitor it, to determine if you 
have a network problem.  If you had many calls running simultaneously, 
you could tell if the problem was yours (seems to affect all calls), or 
perhaps not (only affects a few calls).  You could tell if the problem 
was increasing jitter, increasing RTT, or packet loss.

I plan on adding this to libiax2 soon as a test, but to be useful, it 
would need to be sent and interpreted on the chan_iax2 side as well.  
Also, it would be nice to send and interpret the RTCP-compatible RR 
information in RTCP from rtp.c as well.

Comments are welcome.


-SteveK