[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [AVT] Uncertain about timestamp usage in RFC 2833 named events



Steve, I had this same question a while back and I think the consensus is
your first interpretation, with the timestamp corresponding to the beginning
of the event and the duration incrementing until the event finishes.

Also, with regards to the Cisco phone, I had a couple of SIP phones that I
sniffed a while back, booting with a fairly old IOS, and I saw the behavior
you saw--the timestamp was incrementing while the duration was constant.
However, when I upgraded the IOS for both phones to the most recent one
available on the Cisco site, I saw the correct behavior--same timestamp, but
cumulative duration.

David Wong
Software Engineer
Communications Infrastructure Test Group

p| 978.661.1241 f| 978.988.0148
email | dwong@empirix.com
205 Lowell Street | Wilmington, MA | 01887

E M P I R I X
http://www.empirix.com



  > -----Original Message-----
  > From: Steve Lubbs [mailto:s.lubbs@ieee.org]
  > Sent: Thursday, October 03, 2002 12:54 PM
  > To: avt@ietf.org
  > Subject: [AVT] Uncertain about timestamp usage in RFC 2833 
  > named events
  > 
  > 
  > Hi Folks,
  > I am in a bit of a quandry related to how the timestamp for 
  > RFC 2833 named
  > events should be implemented. My interpretation of the RFC 
  > is that the
  > timestamp marks the start of the event and that this same 
  > timestamp value is
  > used in all subsequent packets associated with the event. 
  > Further, the
  > duration value is cumulative and increases with each 
  > subsequent packet
  > associated with the event.
  > In order to confirm my interpretation I investigated the 
  > behavior of some
  > existing implementations. Some, such as MS Messenger and 
  > OpenPhone, appear
  > to agree with my interpretation. Others, notably a product 
  > from Cisco,
  > don't. The Cisco implementation appears to increment the 
  > timestamp for each
  > subsequent packet and keeps the duration constant. This is 
  > the behavior I
  > would have expected for RFC 2833 tones.
  > 
  > My question is simple. Which interpretation is correct?
  > 
  > Regards,
  > Steve Lubbs
  > 
  > 
  > _______________________________________________
  > Audio/Video Transport Working Group
  > avt@ietf.org
  > https://www1.ietf.org/mailman/listinfo/avt
  > 
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt