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
<vincenotcyberspace7.net> -----
Date : Mon, 20 Aug 2007 22:19:07 +0200
De : Christian Vincenot <vincenotcyberspace7.net>
Adresse de retour :Christian Vincenot <vincenotcyberspace7.net>
Sujet : Re: RTP Stack patch
À : devsip-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:
htt
p://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://u
id0.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 <sipcomcyberspace7.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://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" <vincenotcyberspace7.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
>
>
----- Fin du message transféré -----
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|
