Hi, I think the issue I saw last week might also be related to this (Long delays in re-invite processing). The reinvite destroys the stream, which includes acquiring the jitter buffer mutex. We've observed delays of up to several minutes here, which is a big problem obviously... would be very interested in a timeline for a possible fix. I'll keep digging in the meantime. Alternatively, assuming this behaviour did not exist prior to the ticket #744 fixes, I might actually consider undoing that fix as an interim workaround. regard, Klaus On Mar 24, 2009, at 6:56 PM, Nanang Izzuddin wrote: > Hi, > > Just realized that the jitter buffer had just got resetted (after > looking at the log, well, I should have figured it out with the call > stack & vars dump, anyway, the log helped!). And it seems we've been > able to 'catch' the problem root, that (internal buffer of) jitter > buffer is rejecting the frame since it is detected as a duplicated > frame (instead of frame seq restart). It seems to be bug of ticket > #744. New tickets has been created for this, ticket #762 for trunk and > #763 for 1.0 branch. > > Thanks for the report. > > Regards, > nanang > > > On Tue, Mar 24, 2009 at 10:25 PM, Michael Broughton > <Michael_Broughton at advanis.ca> wrote: >> Nanang Izzuddin wrote: >>> >>> Hi, >>> >>> I have tried to list possible scenarios that may lead to the >>> problem, >>> however I couldn't really find one, so far my only suspect is there >>> was a random jump of RTP timestamp. Is there a bit more pointer that >>> may help us to reproduce the scenario? e.g: RTP packet logs (from >>> sniffing tool), call time, sip provider (if possible). >>> >>> Regards, >>> nanang >> >> >> Hi Nanang, >> >> Thanks for taking the time to look into this. >> >> I can run a tcpdump but with the amount of calling that I do (even >> on five >> phone lines) this will create a very large packet log. I would most >> likely >> have to write a script to rotate the log periodically until a >> deadlock >> happens. What sort of information would you need in the dump? Just >> RTP >> headers? Or would the SIP traffic be needed as well? >> >> Perhaps as a starting point I should add some extra logging. Can >> you provide >> any suggestions as to what sorts of things would be most useful? >> This is >> what I have right now for the JB that is deadlocking: >> >> >> 13:20:01.925 stream.c Stream strm0x804195bc8 created >> 13:20:01.925 strm0x804195bc Encoder stream started >> 13:20:01.925 strm0x804195bc Decoder stream started >> 13:20:01.939 strm0x804195bc Jitter buffer empty (prefetch=0) >> 13:20:01.939 strm0x804195bc Start talksprut.. >> 13:20:02.020 strm0x804195bc RTP status: badpt=0, badssrc=0, dup=0, >> outorder=0, probation=-1, restart=0 >> 13:20:02.039 strm0x804195bc jb updated(2), prefetch=1, size=2 >> 13:20:02.040 strm0x804195bc PUT prefetch_cnt=1/1 >> 13:20:02.059 strm0x804195bc jb updated(2), prefetch=2, size=2 >> 13:20:02.060 strm0x804195bc PUT prefetch_cnt=2/2 >> 13:20:02.498 strm0x804195bc Jitter buffer empty (prefetch=2) >> 13:20:02.649 strm0x804195bc RTP status: badpt=0, badssrc=0, dup=0, >> outorder=-1, probation=0, restart=0 >> 13:20:02.669 strm0x804195bc RTP status: badpt=0, badssrc=0, dup=0, >> outorder=0, probation=-1, restart=-1 >> 13:20:02.669 strm0x804195bc Jitter buffer reset >> 13:20:02.689 strm0x804195bc PUT prefetch_cnt=1/2 >> 13:20:02.689 strm0x804195bc PUT prefetch_cnt=2/2 >> 13:20:33.919 strm0x804195bc Jitter buffer empty (prefetch=2) >> 13:20:34.087 strm0x804195bc RTP status: badpt=0, badssrc=0, dup=0, >> outorder=-1, probation=0, restart=0 >> 13:20:34.107 strm0x804195bc RTP status: badpt=0, badssrc=0, dup=0, >> outorder=0, probation=-1, restart=-1 >> 13:20:34.107 strm0x804195bc Jitter buffer reset >> >> >> -- >> Michael Broughton, Advanis >> >> Unintended Recipient & Unauthorized Use of E-Mail: >> This message and attachments may contain confidential or privileged >> information that is intended only for the named recipient of this >> e-mail. Any unauthorized use or distribution is not permitted. If you >> have received this e-mail in error, deleting the e-mail and notifying >> the sender would be appreciated. Thank you. >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
