["Adil Raja" <adilraja@xxxxxxxxx>]

Aisling,
   I would just like to add a few things here. I have seen a number of implementations of RTP and in all the cases either there are no RTCPs or if they are present then the specific fields for delay calculations are not implemented properly (such as in the ohphone stack). So, I just wanted to say this. To the contrary, if u find an implementation which handles this effectively then please let me know.

Regards,
Adil Raja

On 3/27/06, Martin Mathieson <martin.mathieson@xxxxxxxxxxxx> wrote:

Aisling,  I've written some answers below prefixed by [Martin].

Hello Martin,

My name is Aisling and I am helping David Grau with his project (his
project as part of an undergraduate degree but this also interests me
as part of my postgraduate degree).

I have read rfc 3550 with particular emphasis on the part detailing
how the round trip time (RTT) should be calculated.  The formula
"A-DLSR-LSR" is provided and an example "46864.500 - 5.250 -
46853.125 = 6.125 seconds" is given. We are working from a tethereal
capture file - This was running on the same pc as one of the
softphones involved in the call but as the two softphones calling
each other are on the same LAN segment we should have captured all
the necessary RTCP sender and receiver reports anyway.I have attached
the sample capture file.

[Martin]  Note that within the same LAN segment you are unlikely to see any
interesting roundtrip delays.  You can set the RTCP preference 'Minimum rountrip calculations to report'
to 0 milliseconds.



Myself and David are not clear on a few things:

1) The A field is when the receiver report block is received. Is this
referring to the NTP timestamp? I am struggling to identify this from
the tethereal capture (perhaps the capture format is slightly
non-standard?)and if you could point this out from the attached
capture file we would greatly appreciate it.

[Martin]  'A' seems to be the middle 32 bits from the NTP timestamp, whose units would be 1/65536th seconds.
All 3 quantities in the formula you quote are in these units, though they are converted into seconds to make it easier to read.



2)The LSR field is said to be the middle 32 bits of the NTP timestamp
and the NTP timestamp is made up of the MSW and LSW. So if the
figures are MSW=3350115113 and LSW=493921239 I still fail to
understand why the LSR=3005816176...this is based on the figures from
the attach capture file.

[Martin]  MSW and LSW are being displayed as decimals, it is easier to look at them as hex.
MSW = 0xC7AEB329,   LSW = 0x0x1D70A3D7

The middle word in this case from this would be 0xB3291D70 = 3005816176

However, remember that the LSR in a frame refers to the timestamp seen in a message seen in the opposite direction
(i.e. in a received message it refers to the middle-bytes from the time of a frame you previously sent).



3)the DLSR does appear to be 1 for all captures but as you said this
could be for the reasons that you described before.

[Martin] As in the other example I looked at, there appears to be only RTP/RTCP in one direction, so these values looke made up / default to me.
You maybe need to make sure that someone is speaking in both directions to that RTP and SRs are sent.  No calculation can be done until a SR in one direction
refers to an SR in the previous direction (by matching its LSR and having a sensible DLSR filled in).



4)Based on the above points and the attached capture file could you
give an example with figures (from the file) of using A-DLSR-LSR?

[Martin]  Sorry, I don't have ready access to my old capture collection at the moment.  I realise that the way this calculation is done is a bit complex.
I notice that RFC 3611 allows non-senders to calculate roundtrip delays, but I've never seen it used in a real client.

I really do hope this helps you.
Best Regards,
Martin


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