SpectraAnalyzer, comment out print statements

[mcacker]

PortManager, make currPort static so that multiple instances don't
conflict port useage
UdpManager, cleanup selector is created
RTPDataChannel, expose JitterBuffer
Scheduler, fix thread leaks

[hrosa]

Hi Mitchell,

After reviewing your work, all seems fine to me except one thing - your branch is deprecated which makes the merge impossible.

Last year I added support for RTCP, ICE & STUN (for WebRTC calls) and refactored the RTPDataChannel (became deprecated, replaced with RtpChannel class).

The question now is: should I do the "merge" manually or are you willing to pull from master, apply the changes and then submit your work?

Let me know what you prefer.

Many thanks once again,
Henrique

[mcacker]

Glad to hear about RTCP, that is something we may want to use and I was
thinking I might have to jump to the Jitsi library.

I'll pull the latest branch and do the merge, and let you know if I run
into any issues. I'll want to check that there are no thread/memory/cpu
leaks. I take it that the API hasn't changed significantly and the switch
to RtpChannel is straightforward?

Mitchell

On Wed, Jul 8, 2015 at 4:28 AM, Henrique Rosa [email protected]
wrote:

Hi Mitchell,

After reviewing your work, all seems fine to me except one thing - your
branch is deprecated which makes the merge impossible.

Last year I added support for RTCP, ICE & STUN (for WebRTC calls) and
refactored the RTPDataChannel (became deprecated, replaced with RtpChannel
class).

The question now is: should I do the "merge" manually or are you willing
to pull from master, apply the changes and then submit your work?

Let me know what you prefer.

Many thanks once again,
Henrique

—
Reply to this email directly or view it on GitHub
#24 (comment).

[hrosa]

Hi,

There may be some work involved but I don't think too much.
Overall, here are some guidelines:

• The RtpConnection is now composed of MediaChannels (requirement to have a video channel as well in the future).
• The MediaChannel contains an RTP channel and an RTCP channel. The RTCP channel is optional because you can do multiplexing in the RTP channel.
• The RtpChannel contains a list of PacketHandlers that will treat suitably incoming packets (handlers for DTLS, STUN, RTP and RTCP are implemented so far). This was necessary for WebRTC calls where STUN, DTLS and SRTP packets were sent to the same channel.
• The RTPDataChannel is equivalent to the RtpChannel, having its RxTask and TxTask replaced by the RtpHandler and RtpTransmitter for simplicity sake.

Also, it's worth noting that I am preparing to implement a Selective Forwarding Unit for Mobicents MS (issue #20 ). As pre-requirement we need to have the capability to decide what is the relay type at RTP level: mixer or translator.
Up to this moment the entire MMS design assumes that we will always use mixing... so I'm currently working on issue #23 , refactoring the RTP library once again.

My advice is that you that a look at the current master branch and evaluate how much work is needed so you can plan ahead, but wait for issue #23 to be closed so you don't have to do extra work after a while.

Also, let's have discussions like this on the mobicents public forum so other users in community can benefit and take part of discussion.

[hrosa]

FYI
https://groups.google.com/forum/#!topic/mobicents-public/YI8wcO3dleQ

[mcacker]

Henrique,

I finally found some time to try and apply my updates to the latest repo, and see that the main source of the resource leaks, org.mobicents.media.server.scheduler.Scheduler, has been completely refactored to use standard java util executors, and none of my changes are relevant any more.

I haven't performed any memory leak tests on the latest code, but is it your opinion that this refactoring has addressed the previously observed scheduler resource leaks?

thanks, Mitchell