Hi, On 7/12/07, Alexander Boreham <[EMAIL PROTECTED]> wrote:
It looks like there is an issue in the MpdSipxPcma::decodeIn function. The same presumably applies to MpdSipxPcmu::decodeIn. The error is around the handling of the following code:<skip>
Thank you for discovering this bug. Jitter buffer part of sipXmediaLib is known to be error prone and is waiting for a good cleanup/update/rewrite. This is a part of code with really weird logic. I've already fixed many bugs in it, but seems not all of them. And I to rewrite it from scratch, adopting one of existing JiterBuffers (speex, or any else) or writing our own with better structured and documented one. Could you test attached patch and report result? As far as I see it, problem you've pointed out is caused by the fact that decodeIn() return value is not handled properly by MprDecode. If decodeIn() returns 0, RTP packet should remain in buffer, so it will be processed next time again. Current code does not return pulled RTP packet to jitter buffer, and this break all operation logic. My patch just fix this. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
decodeIn_handling.patch
Description: Binary data
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
