Subject: RE: [AVT] RTP packet format for events in RFC2833

From: "Wong, David" <[email-masked]>
Date: Thu, 5 Sep 2002 14:14:37 -0400

Thanks for the answer.

Given that multiple packets corresponding to an event will have the same RTP
timestamp (and this could be interspersed with regular encoded audio
packets), then how would the jitter calculation be updated? For example,
would you only calculate jitter on encoded audio packets versus event
packets?

  > -----Original Message-----
  > From: Bino George [mailto:[email-masked]]
  > Sent: Thursday, September 05, 2002 12:57 AM
  > To: Wong, David; [email-masked]; [email-masked]
  > Subject: Re:[AVT] RTP packet format for events in RFC2833
  > 
  > 
  > Hello :
  >         Obviously the second interpretation is correct. Logically an
  > event is generated at a specific RTP time stamp and  after 
  > that only RTP
  > sequence number and the event duration is updated.
  >      From RFC 2833 :
  >            If the event continues more than one period, the source
  > generating the events should send a new event packet with the RTP
  > timestamp value corresponding to the beginning of the event and the
  > duration of the event increased correspondingly.
  > 
  >      I think retransmission of the last packet of the event is a
  > nuisance{ for  transmitter logic } , the receiver can take care this
  > issue.
  > 
  > bino
  > 
  > I'm confused on how to update values in the RTP header 
  > (timestamp) and
  > event block (duration) when transmitting an event.
  > 
  > Let's take the example in section 3.8 of RFC 2833 (or the draft).
  > 
  > I. Consider the digit event "9" at time 0 that lasts 200 ms.
  > 
  > I have two interpretations for how the RTP header timestamp and the
  > event duration should be updated. Which one is correct (assuming an
  > interpacket delay of 50 ms, or 400 timestamp units)?
  > 
  > 1. The RTP header timestamp is updated by 400 timestamp units per
  > packet, and the duration is the same for each packet during 
  > the event
  > (400 timestamp units).
  > 
  > RTP seq#        RTP timestamp        duration
  > ---------------        ---------------------        ------------
  >       0                        0                     400
  >       1                        400                 400
  >       2                        800                 400
  >       3                        1200               400
  > 
  > 2. The RTP header timestamp is the same for all of the 
  > packets during
  > the event (0) and the duration increments by 400 timestamp units per
  > packet.
  > 
  > RTP seq#        RTP timestamp        duration
  > ---------------        ---------------------        ------------
  >       0                        0                     400
  >       1                        0                     800
  >       2                        0                     1200
  >       3                        0                     1600
  > 
  > 
  > II. For the last packet for the event, seq # 3 in either 
  > example, how is
  > this packet retransmitted? Are the recommended three retransmissions
  > transmitted at 50 ms apart or are they retransmitted 
  > immediately? Are
  > the RTP sequence numbers updated for each retransmission?
  > 
  > III. What should be transmitted between the end of digit "9" and the
  > beginning of digit "1", which happens at time 800 ms? Can nothing be
  > transmitted or should silence be transmitted? If silence is 
  > transmitted
  > between events, then shouldn't silence be transmitted even when the
  > digit "9" is being transmitted (from the viewpoint that 
  > this may be a
  > VOIP phone that isn't transmitting any audio, I would think 
  > that silence
  > would always be transmitted that a person is not speaking).
  > 
  > David Wong
  > Software Engineer
  > Communications Infrastructure Test Group
  > 
  > p| 978.661.1241 f| 978.988.0148
  > email | [email-masked]
  > 205 Lowell Street | Wilmington, MA | 01887
  > 
  > E M P I R I X
  > http://www.empirix.com
  > 
  > 
  > 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Bino George <[email-masked]>
Date: Fri, 06 Sep 2002 14:00:40 +0530

Hello wong:
       From my understanding, the event packets  have  to be excluded from
jitter calculation.
The receiver may interpret Events the way they want, still they are events not a
continuous audio stream.
If overlapped audio packets are present, the receiver can use this for jitter
manipulation.
bino