Ethereal-users: Re: [Ethereal-users] RTCP for VoIP QoS

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: David Grau Serra <dgs@xxxxxxxxxx>
Date: Mon, 27 Mar 2006 21:46:59 +0100
Hi Adil,

SIP is a signalling protocol.
RTP is a transport of real-time data protocol.
Media path != signalling path.
Every RTP session has a parallel RTCP session.
RTCP:

   * Exchange information about losses and delays between the end systems.
   * Packets sent in intervals determined based on number of end
     systems and available bandwidth.
   * The sender knows what quality of reception the receiver is
     experiencing.

I just know that some extensions to RTCP are called RTCP-XR.

Regards,
David



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


------------------------------------------------------------------------

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