Hi everybody,
Just a last note to say that I've managed to add the
following things before the
deadline:
. RTCP packets padding correction: the padding wasn't done
correctly, so most of
the RTCP RR packets were considered as malformed by
Ethereal/Wireshark. The RFC
isn't totally clear IMHO about how the padding should be
done, so I had a few
problems to conform the code. After having read the
speex-RTP profile RFC and
the wireshark RTCP dissector's code, I managed to get
something which seems
correct (it passes successfully the checks done by
wireshark). Feel free to
comment about this part if you think it's not done the right
way.
. RTCP Sender Reports correction: some internal problems in
the stack were
keeping it from sending Sender Reports packets. This is now
fixed. What's more,
the stack was sending wrong/no statistics in the SR (and
also RR packets). I
think I've corrected all of them, but I'll do some deeper
checks in the next
days to be sure that they're all ok.
. Handling more than 30 report blocks in SR/RR RTCP packets
using a round-robin
(wanted by the RFC-3550): this was already done when I wrote
the first mail I
think, but I forgot to mention it.
. Documentation: I've added javadoc and comments to the
complete stack's code.
I'm adding a target in the ant script at the moment to build
automatically the
customized jmf.jar, but I guess it will be too short for the
deadline ;).
As I said in the previous mail, the patch and the customized
jmf.jar have been
updated each evening for the last days and are available
here:
http://u
id0.free.fr/downloads/rtp/test.patch
http://uid0
.free.fr/downloads/rtp/jmf.jar
I'd like to do some more tests to verify the stats sent, and
afterwards, even if
the stack is not perfect, I think it is stable enough to be
commited to FMJ, so
I'll commit it this week if nobody is opposed to this idea.
Best regards,
Chris.
----- Original Message -----
From: "Christian Vincenot" <vincenot cyberspace7.net>
To: <devsip-communicator.dev.java.net>
Cc: <fmj-devellists.sourceforge.net>
Sent: Sunday, August 19, 2007 1:27 AM
Subject: [sip-comm-dev] 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
>
>
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|
