["Adil Raja" <adilraja@xxxxxxxxx>]

David,
  It is good to hear from u. The best thing I worked was the OpenH323 project. It does not have some calculations implemented properly (such as LSR or DLSR). I try to probe into the code but finding that it was quite a bit of work and that a deviation from my work I left it for some solitary time. I have also tried with winRtp as well but it had some problems as well. Astonishingly, the stach has some bugs in some of its basic calculations. Anyway, 
The thing with SIP is that it is call control and signalling protocol (a suite so to say). RTCP always comes as a part of RFC 3550. i.e. the RTP protocol. 

I must share with u one more thing (or if I am lagging in knowledge then please correct me) that RTCP-XR is not supported by any of the applications I have encountered so far. This means that even if there are some they are only a few. Which implies that the number of ppl using such applications are also few. On the other hand some companies are providing solutions to masses based on the assumption that RTCP-XR is there. Anyway, it was just a thought and I wanted to share it with u.

Regards,
Adil Raja

On 3/27/06, David Grau Serra <dgs@xxxxxxxxxx> wrote:

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
>

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