Re: RTP Stack patch

Hi everybody,

Just a little update to tell you that I've fixed the dynamic
minimum RTP delay
calculation (which is now enabled in the customized jmf.jar)
as well as the
interarrival jitter calculation which was doing some weird
calculation always
returning zero.

The most recent patch and jmf.jar can be downloaded here (I
prefer giving links
to avoid being moderated by FMJ's ML because of the mail
size) :

http://u
id0.free.fr/downloads/rtp/test.patch
http://uid0
.free.fr/downloads/rtp/jmf.jar

Please feel free to contact me about any bug or strange
behaviour in the RTP
stack.

Best regards,
Chris.

----- Original Message -----
From: "Chris" <sipcomcyberspace7.net>
To: <devsip-communicator.dev.java.net>
Cc: <fmj-devellists.sourceforge.net>
Sent: Friday, August 17, 2007 3:28 AM
Subject: [sip-comm-dev] RTP Stack patch


> Hi everybody,
>
> Here is the first real patch to FMJ's RTP stack. I'll
surely submit other
> corrected versions before the deadline. This patch is
meant for testing
purpose,
> because I would need feedback on things that don't work
with the stack now.
I've
> done a lot of changes in it, and some algorithms only
kick in when special
> situations happen, so I haven't been able to test many
scenarios for the
moment.
> Please feel free to report anything that looks strange
or fails.
>
> Here is a little summary of the main things done :
>
> . more secure SSRC generation : conforming to the RFC,
Math.random() isn't
> enough, so I've written an SSRC generator class which
isn't the best piece of
> code possible, but seems to work correctly. It's
supposed to avoid as much as
> possible that two machines generate the same SSRC in
the same RTP session
> (collision).
>
> . same thing for sequence numbers : the sequence
numbers are supposed to be
> unpredictable to avoid any kind of attacks.
>
> . RTCP delay calculation : I've done many modifications
in this part. The
> algorithm used before was not conforming to the RFC,
and there were also a few
> bugs and design problems in the calculation which were
causing RTCP packets to
> be almost never sent because the allocated bandwidth
was almost inexistant.
> I've rewritten most of this part (initialization,
computation) and I've also
> added a timer reconsideration algorithm and reverse
reconsideration algorithm
> for the delay to be more reactive to changes in the
configuration of the
> session.
> As a consequence, if/when everything works fine, the
participant joining a
> session will be detected faster, the delay between RTCP
packets will be
> calculated more accurately to avoid congestion to be
unseen or on the contrary
> flooding the session with too many RTCP packets, and
the session manager will
be
> more reactive to changes and return faster to a proper
state. What's more, the
> session manager now uses the bandwidth repartition
parameters to compute the
> RTCP delay.
>
> . Participant Timeout was added: conforming to the RFC,
we must delete
> participants who seem to be dead after a given period.
I've implemented a
> "reaper" to do this job.
>
> . The transmission task has been modified too,
considering the previous
changes
> (especially the timer reconsideration algorithm)
>
> . A BYE packet transmission algorithm conforming to the
RFC-3550 has been
> implemented. It is supposed to be able to handle
sessions with more than 50
> participants by delaying the transmission of the BYE
packet following the
> algorithm described in the RFC.
>
> . A dynamic RTCP minimum delay computation algorithm
has been added. This is
> disable in this patch because I've still got some
strange results with it. It
is
> meant to calculate the minimum RTCP delay used in the
RTCP delay computation
> considering the session bandwidth available instead of
using a static value
(5s
> is suggested in the RFC).
>
> . The algorithm calculating the average RTP packet size
has been rewritten
> conforming to the RFC (which suggests a computation
method which is more
> reactive to changes, giving more importance to recent
packets)
>
>
> Many smaller modifications have been done, and some are
left to be done,
> especially the SSRC loop/collision detection algorithm
and handling CSRC
> correctly. Those points are not vital (especially in
the case of SC), but if I
> don't get lost in bug tracking, I might be able to
write them before the
> deadline.
>
> As said, this patch is really meant for testing. I'll
clean & document the
> important parts of the RTP stack and I'll do some bug
corrections /
> modifications before the deadline. A jar file
containing the customized JMF
with
> this RTP stack is available at :
>
> http://uid0.fre
e.fr/downloads/jmf.jar
>
> When the stack seems stable, I'll commit it to FMJ's
repository. Until then,
> please feel free to contact me to tell me about
anything that you find strange
> or any bug that appears when using this stack.
>
> I hope my mail was clear. I'm a bit tired so I might
have talked nonsense,
> that's why I'll post another summary of the
modifications with my final patch.
>
> Thanks.
>
> Cheers,
> Chris.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net