On Thu, Nov 13, 2008 at 7:18 AM, Paul Whitfield <[EMAIL PROTECTED]> wrote: > Paulo Vicentini wrote: >> >> okay, >> >> Thanks for the tips... >> >> Attached are new ones...I've tested and it seems to work... >> >> PS: Just as i can see, my way to detect SSRC changes was >> SSRC_SWITCH_MISMATCH_COUNT times of the new RTP packet stream ahead of the >> current way...it was detecting first the change and already resetting >> dejitter (despising transient rtp stream by "keeping ssrc state" rather than >> countering new ssrc) >> > > I found an issue with these changes - > On exit I was getting a exception on deleting the Dejitter buffer... > > I suggest that rather than deleting the jitter buffer, > make the reset() method of the dejitter buffer public and > call that. > > I can send diff's if you would like.
Sure, patches are always welcome. Post it here and I'll comit it after some review. > Also: What is the status for a "proper" fix, i.e. the multicast > / conference changes that will mix the audio ? They're ready to be tested in trunk! I'm lagging with anounce because I need to gather a list of changes we've made (a handful of them were made). Also we haven't tested all build configurations yet - Linux should build fine, same for VS2003. Not sure about other VS versions. So, try to compile and look into MpRtpInputConnection constructor, line 90 and below. That's where we create so called "RTP Dispatcher" resources which are responsible for dispatching RTP packet to RTP streams. MprRtpDispatcherIpAffinity is a default dispatcher for unicast streams - it maintains only single stream and is very much the same as older code. MprRtpDispatcherActiveSsrcs - is a default for multicast. It maintains some predefined number of streams and dispatch incoming RTP packets to them, using "most recent SSRC is preffered" scheme. You probably will want to change dispatcher to multicast one even for unicast streams. You can do this in MprRtpInputConnectionConstructor::newResource() easily. Though it would be better to make this a configuration option so everyone will be able to do similar thing :) -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
