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

["Adil Raja" <adilraja@xxxxxxxxx>]

David,
  Well thats what I meant to say.
Regards,
Adil Raja

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

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
>

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