On Mon, Jul 14, 2008 at 1:39 PM, Will Davies <will at hugthebubble.co.uk> wrote: > On Fri, 11 Jul 2008 16:33:59 +0100 > "Benny Prijono" <bennylp at pjsip.org> wrote: > > > > > > So this is not a call drop in the usual sense then since signaling seems > to > > be still in place (calls are still CONFIRMED on both ends), but rather > lost > > of audio after few minutes of conversation. Is that right? > > > I have a couple of logs from this user's machine where calls never to the > CONFIRMED state, but we had a conversation that lasted over a minute. I > would blame gizmo but there are other users for which it works fine. > > > In that case then these links will probably help: > > http://trac.pjsip.org/repos/wiki/audio-problem-local-no-audio > > http://trac.pjsip.org/repos/wiki/audio-problem-remote-no-audio > > > considering that the audio works to start with > are there any particular candidates there which might take a while for the > problem to kick in. > > http://trac.pjsip.org/repos/wiki/audio-check-rx-rtp is probably interesting. When the audio stalls, it would be good to see if RTP packets are still sent/received (the number of RTP packets sent and received are increasing). Would it be possible that Gizmo changes the codec in the middle of call without sending re-INVITE or UPDATE? When this happens you'll see loads of "invalid pt" error in the log though. Also even though as you said the problematic calls always involve users with dynamic IP, I assume the IP address doesn't change in the middle of a call, don't you think? Apart from these I can't think of anything else for now. -benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080714/59307488/attachment-0001.html
