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

["Adil Raja" <adilraja@xxxxxxxxx>]

Aisling,
  I dont mean to discourage u. But u wouldnot find any currently. I personally suggest (if u r so motivated) to comile the openH323 on ur machine and try to debug it. Compiling the stack could be a bit of problem. But then u could find some support on the OpenH323 project's mailing list. Then if u r a reasonable coder, u can debug the code (or activate the fields). But its all up to u.

Regards,
Adil Raja

On 3/28/06, Aisling <ashling.odriscoll@xxxxxx> wrote:

Hi Adil,

 

Thank you for the reply. Yes unfortunately I am after finding that XLite send bogus RTCP values and don't seem to implement the RTP/RTCP stack correctly. I looked at the Counterpath Xlite mailing list and found other people who have had similar issues. This is very disappointing so I will now need to find a softphone which sends correct RTCP information.

 

Regards,

Aisling.

 

-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx [mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of Adil Raja

Sent: 28 March 2006 13:04
To: Ethereal user support
Subject: Re: [Ethereal-users] RTCP for VoIP QoS

 

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

-------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

-------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

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