[sip-comm-dev] Trans.: Re: RTP Stack patch


#1

Looks like the second mail I sent yesterday never arrived on the ML, so here it
is again.

@Ken: if you've received it, sorry for the noise.

Cheers,
Chris.

----- Message transf�r� de Christian Vincenot <vincenot@cyberspace7.net> -----
Adresse de retour :Christian Vincenot <vincenot@cyberspace7.net>
  Sujet : Re: RTP Stack patch
      � : dev@sip-communicator.dev.java.net

Just a little word to say that I've finished the ant target to build
automatically a jar archive (fmj4sc.jar) including FMJ's RTP in JMF (=> the
"customized" jmf). The patch is avalaible at the following address:

http://uid0.free.fr/downloads/rtp/build_xml.patch

I'll talk with Ken to see if it could be commited as it is. Until then, all you
need to do if you want to play with all this is to apply the patch and to
extract my_jmf.rar ( http://uid0.free.fr/downloads/rtp/my_jmf.rar) into the root
directory of FMJ in a directory called "jmf".

Afterwards, you can run the "fmj4sc" target.

Cheers,
Chris.

Selon Chris <sipcom@cyberspace7.net>:

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://uid0.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.

From: "Christian Vincenot" <vincenot@cyberspace7.net>
To: <dev@sip-communicator.dev.java.net>
Cc: <fmj-devel@lists.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://uid0.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.
>
> From: "Chris" <sipcom@cyberspace7.net>
> To: <dev@sip-communicator.dev.java.net>
> Cc: <fmj-devel@lists.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.free.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-help@sip-communicator.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

----- Fin du message transf�r� -----

···

Date : Mon, 20 Aug 2007 22:19:07 +0200
     De : Christian Vincenot <vincenot@cyberspace7.net>

----- Original Message -----
> ----- Original Message -----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net