Hi Alexander,
Using the most recent sipXtapi sources (2008-10-18, around 3 pm ET)
ReceiveCall receives calls from Gizmo and audio works both ways. I
verified the updated sources include your patch. Thanks again!
Finest regards,
Bill Root
At 10/15/2008 09:22 AM, Alexander Chemeris wrote:
>This patch should finally solve problem with SDP handling.
>Please, test it and report whether it helps.
>
>On Wed, Oct 15, 2008 at 1:43 PM, Alexander Chemeris
><[EMAIL PROTECTED]> 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/
