Hi Alexander,
Thanks for the patch. Sorry for the delay -- I was out of town most
of last week.
I applied your patch, built, and tested ReceiveCall again. I got a
heap corruption error. Then, I updated all sources from the
repository, rebuilt, and now it seems to work fine. No 100% CPU consumption.
Thank you, Alexander.
Finest regards,
Bill Root
At 10/15/2008 05:43 AM, Alexander Chemeris wrote:
>Please apply attached patch and test again - 100% CPU consumption
>should go away. But you still won't hear any audio, as SDP answer
>is not fixed yet - expect this to be fixed in the next patch.
>
>
>On Mon, Oct 13, 2008 at 8:13 PM, Alexander Chemeris
><[EMAIL PROTECTED]> wrote:
> > Thanks for your help, I've got the problem - it is due to wrong
> > SDP answer generation. Gizmo offer following SDP:
> >
> > v=0
> > o=GizmoProject 659312305 1 IN IP4 198.104.137.136
> > s=GizmoAudioSession
> > c=IN IP4 198.104.137.136
> > t=0 0
> > m=audio 6526 RTP/AVP 103 102 0 8 3 106 13
> > a=rtpmap:103 ISAC/16000
> > a=rtpmap:102 iLBC/8000
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:8 PCMA/8000
> > a=rtpmap:3 GSM/8000
> > a=rtpmap:106 telephone-event/8000
> > a=rtpmap:13 CN/8000
> > a=rtcp:6527
> > m=video 6526 RTP/AVP 34 125
> > a=rtpmap:34 H263/90000
> > a=rtpmap:125 MP4V-ES/90000
> >
> > while ReceiveCall answers with this:
> >
> > v=0
> > o=sipX 5 5 IN IP4 72.240.225.139
> > s=call
> > c=IN IP4 72.240.225.139
> > t=0 0
> > m=audio 23465 RTP/AVP 100 0 8 3 102
> > a=rtcp:23466
> > a=rtpmap:100 ilbc/8000/1
> > a=rtpmap:0 pcmu/8000/1
> > a=rtpmap:8 pcma/8000/1
> > a=rtpmap:3 gsm/8000/1
> > a=rtpmap:102 telephone-event/8000/1
> > a=ptime:20
> >
> > ReceiveCall behaves unfriendly, using different payload types
> > then offerer. But (if I recall RFC correctly) Gizmo then should
> > send us audio with payload from the answer, but it does not.
> > So, both sides are wrong. I'm going to fix sipX, so watch
> > for updates.
> >
> > And also it definitely mustn't enter infinite loop under any
> > circumstances. We should fix this too.
> >
> > On Sat, Oct 11, 2008 at 6:29 PM, Bill Root <[EMAIL PROTECTED]> wrote:
> >> At 10/11/2008 03:38 AM, Alexander Chemeris wrote:
> >>>
> >>> >> >
> >>> >> >
> "2008-09-19T13:23:24.482000Z":433:KERNEL:CRIT:vpc-vs4sipxtapi::00000000:sipXtapi:"OsMsgPool::FindFreeMsg
> >>> >> > 'MediaSignals' queue size (64) exceeds hard limit (64)"
> >>> >>
> >>> >> This messages usually mean that some flowgraph is blocked
> >>> >> and don't want to process messages, sent to it. To debug this,
> >>> >> you should pause the process from debugger and see where
> >>> >> is Mediatask thread looping. Few iterations should give you
> >>> >> a clue about the place where infinite loop occurred.
> >>> >> Posts this information here, and we'll be able to help you better.
> >>> >
> >>> > The "exceeds soft/hard limit" messages are less common today, using
> >>> > newly
> >>> > downloaded source code from the relocated SVN repository. However,
> >>> > ReceiveCall still starts consuming 100% of CPU shortly after I connect,
> >>> > like
> >>> > it did previously. When I break into the debugger, MpMedia thread is
> >>> > looping in MprDecode::doProcessFrame (MprDecode.cpp). It's the main
> >>> > loop:
> >>> > // Pull packets from JB queue, till we won't get enough samples to
> >>> > playback
> >>> > ...
> >>> > while (mpJB->getSamplesNum() < mpFlowGraph->getSamplesPerFrame())
> >>> > {
> >>> > ...
> >>> > }
> >>> >
> >>> > mpJB->getSamplesNum() returns 0, and mpFlowGraph->getSamplesPerFrame()
> >>> > returns 80. Over and over. I just watched > 50 loops, always with the
> >>> > same
> >>> > values for those two.
> >>>
> >>> Ok, that gives us a clue. Could you uncomment this line in MprDecode.cpp
> >>> and
> >>> send me console output od ReceiveCall:
> >>> //#define DEBUG_PRINT
> >>> (run it, get it to the point when it starts infinite loop and just kill
> >>> it).
> >>> Also, please, you send me Wireshark capture of the RTP+SIP this sessioin
> >>> on
> >>> the ReceiveCall side. I hope this would be enough for me to fix the
> >>> problem.
> >>
> >> Done. The attached zip file includes the console output from ReceiveCall,
> >> the WireShark capture file, and the sipXtapi log file.
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
