["Anders Broman" <a.broman@xxxxxxxxx>]

Hi,
Sorry for the late reply. I made a quick test of your patch and on a trace
file I have it looked as it 'dropped' packets from the analysis, I have
Been meaning to make a better check but have not found the time yet :(

Perhaps the patch can be split into two parts one dealing with the clock
rate which is probably not causing the problem and one with out of order
packets?

There is code to extract the dynamic payload type from SDP data and store it
In the conversation data this could be used to 'know' which dynamic Payload
type is used but some bits and pieces are missing still if I remember
correctly. For H323 something similar will have to be done.
Best regards
Anders

-----Ursprungligt meddelande-----
Från: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] För Patrick Noffke
Skickat: den 6 oktober 2005 09:47
Till: ethereal-dev@xxxxxxxxxxxx
Ämne: RE: [Ethereal-dev] RTP analysis w/out-of-order packets (patchincluded)

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
> > >
> 
> 

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev