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-unsubscribe sip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|
