[David Grau Serra <dgs@xxxxxxxxxx>]

Hi Adil,

I am helping Aisling, and if I understand what are you saying, these it 
could happen to xlite phone, but I am not sure at all.
I give you some links that they are saying that:

http://support.counterpath.net/viewtopic.php?t=2154
http://support.counterpath.net/viewtopic.php?t=2201
http://support.counterpath.net/viewtopic.php?t=5920

By the way, I can catch RTCP packets in both directions using xlite 
phone, but as you say, maybe the specific fields for delay calculations 
are not implemented properly...
I am wondering, like you, if there are any soft phone (SIP) hich handles 
this effectively.

> 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 
> <mailto: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 <mailto:Ethereal-users@xxxxxxxxxxxx>
>     http://www.ethereal.com/mailman/listinfo/ethereal-users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>