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
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) :
Please feel free to contact me about any bug or strange behaviour in the RTP
----- Original Message -----
From: "Chris" <firstname.lastname@example.org>
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
because I would need feedback on things that don't work with the stack now.
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
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
. 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
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
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
. 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
(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
meant to calculate the minimum RTCP delay used in the RTCP delay computation
considering the session bandwidth available instead of using a static value
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
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
this RTP stack is available at :
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org