Real-Time Delivery

In a real-time application data must be delivered with the same time relationship as it was created (but with some delay) ⇒ Two aspects of real-time delivery (for protocols):

Order	data should be played in the same order as it was created
Time	the receiver must know when to play the packets, in order to reproduce the same signal as was input

We keep these separate by using a sequence number for order and a time stamp for timing.

Consider an application which transmits audio by sending datagrams every 20 ms, but does silence detection and avoids sending packets of only silence. Thus the receiver may see that the time stamp advances by more than the usual 20 ms, but the sequence number will be the expected next sequence number. Therefore, we can tell the difference between missing packets and silence.

Transcript

[slide80] So, to achieve this real time delivery that we need, we need two important things. We need to order, because we need to make sure that we play the packets out in their correct order, and we need to have timestamps, so we play them out at the right temporal spacing. Now, why do we have to worry about playing them out at the right temporal spacing? Well, remember that voice activity detection. If we didn't have anything to play, we didn't need to send anything. So when we now have something to play again, we need to know when's the right time to play it. So to achieve this order, we use a sequence number. To achieve the temporal relationship in our play out, we now add timestamps. Pretty straightforward, right? Number the packets, put timestamps on them. How accurately do we need the timestamp? Well, we need the timestamp so that we can know, gee, if we were using 20 millisecond frames, how many 20 milliseconds do we have to wait until it's time for this next packet to play? So the timing is generally based upon the sample rate.