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 >
