On Tue, Mar 24, 2015 at 4:04 PM, Yousf Ateya <[email protected]> wrote: > One of the ways in which IAX calculates peer ping time is using > POKE/PONG/ACK sequence as follows: > > - Peer1 sends POKE (frame timestamp is time of sending) > - Peer2 sends PONG with same time stamp received from POKE. > - Peer1 calculates ping time by doing: pong_reception_time - poke_send_time. > > While using a shaky connection, sometimes ping time changes from normal > ~100ms to long ping time (~2 seconds, sometimes get TOO LAGGED) for one ping > and returns to normal again. > > This happens because of packet loss. Here is what happens: > > - Peer1 sends POKE (it mark sending time stamp in channel member `offset`) > - POKE packet is dropped > - After sometime (qualify / 2), POKE is retried. > - Peer2 receives the POKE packet and sends PONG. > - Peer1 receives the PONG packet, and calculates ping time = > pong_receiption_time - first_poke_send_time > > So ping time becomes high for short period because of a packet retry, not > because the network is slow. > > Is it better to calculate ping time = pong_receiption_time - > last_poke_send_time? So we get **actual** network ping time instead of > network_ping_time + packet_retry_time.
I'd say we should always be using the time of the POKE that corresponds to the PONG that was received. Unfortunately, that doesn't appear to be easy, as I don't _think_ there's a way to know which POKE message the PONG is for - we don't send back the identity of the POKE message that caused the PONG message. (At least from what I can tell - I may be mistaken here.) The only problem with your proposal is that you may get very inaccurate qualification times. Consider a situation in which the network is terribly lagged: 1. Send POKE #1 2. Wait, get no PONG 3. Send POKE #2 4. Get a PONG message for POKE #1 With your algorithm, we'd calculate the round trip time as PONG - POKE #2 - which is very wrong. In fact, doing that may be more harmful than reporting a high qualify time due to a packet getting dropped. So I'm not sure this is the right approach - at least not without knowing how we would correlate PONGs to POKEs in such a scenario. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
