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
