Wireshark · Ethereal-dev: RE: [Ethereal-dev] RTP analysis w/out-of-order packets (patch included)

["Patrick Noffke" <patrickn@xxxxxxxxxxxx>]

Jaap,

Thanks for the input.  Hope you don't mind, but I'm sending this to the list as well so others can hear my rationale as well.

I realize the clock rate for dynamic payloads can be anything, and I do indicate the clock is guessed (when it is) in the status text at the bottom of the dialog.  But even though the clock can be anything, there are some common clock frequency/sample rate combinations that use payload type 96 and result in a unique interval between RTP packets.  

For example, video using a clock of 90 kHz and 30 frames per second results in a minimum timestamp increment of 3000, which is one of my timestamp intervals.  Audio may have a clock of 44.1 kHz, and frames sent every 30 ms, so the timestamp increment would be 1323.  My numbers for audio are ficticious since I don't have the experience with audio, which is also why I didn't include any increments for audio (and hopefully someone with the experience can add to my list of intervals).  The point is this audio increment is different from the increment of 3000 used by my video example.  It's only when two combinations of clock+sample rate result in the same minimum timestamp increment that you get an ambiguity.  

Besides, there's no harm in guessing, all it does is add usefulness to the delta times and jitter calculations when the guess is right, which is the reason I put it there in the first place.

People with commit access -- could someone please apply the patch or, if not, let me know if there is a problem with the changes?

Thanks,
Patrick

> -----Original Message-----
> From: Jaap Keuter [mailto:jaap.keuter@xxxxxxxxx]
> Sent: Thursday, 6 October 2005 3:43 PM
> To: Patrick Noffke
> Subject: RE: [Ethereal-dev] RTP analysis w/out-of-order packets (patch
> included)
> 
> 
> 
> Hello Patrick,
> 
> Well, I just noticed that your patch didn't get in so far, so 
> I wondered.
> 
> The only comment I would give is to remove the part which guesses the
> clock frequency. These dynamic payloads can be anything (I 
> see 96 being
> used for telephony events every day now) so it's easy to get 
> things wrong.
> 
> For the rest it looks fine to me. I would suggest to strip 
> the guessing
> part, recreate the patch from the latest SVN and send it to the list
> again. Sometimes patches do fall between the cracks, it helps 
> to tag them
> with [PATCH] in the Subject line.
> 
> Thanx,
> Jaap
> 
> On Thu, 6 Oct 2005, Patrick Noffke wrote:
> 
> > No, not yet.  Do you have any?
> >
> > > -----Original Message-----
> > > From: Jaap Keuter [mailto:jaap.keuter@xxxxxxxxx]
> > > Sent: Friday, 30 September 2005 6:01 PM
> > > To: Patrick Noffke
> > > Subject: Re: [Ethereal-dev] RTP analysis w/out-of-order 
> packets (patch
> > > included)
> > >
> > >
> > > Hi
> > >
> > > Had any comments on this yet?
> > >
> > > Thanx,
> > > Jaap
> > >
> 
>