Hi, Alexander Ok, thanks for the update. I noticed that the main branch has a new switch on sipXInitialize that allows local audio to be turned off. That's probably good enough for me for now -- I'll use that.
Thanks for looking into this, ...Andrew -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alexander Chemeris Sent: Sunday, July 12, 2009 7:01 PM To: Paulo Vicentini; Lavigne, Andrew (CAR:PC00) Cc: [email protected] Subject: Re: [sipxtapi-dev] Fwd: Input audio sometimes not connected properly Ok, It's clear now. This feature is not yet implemented in the new Topology graph. So I changed the code to show this up. It will now assert in sipXtapi - slightly better then meaningful crash. Anyway, if everything go as expected, we're going to address this shortcoming in the next two month and implement device change. On Sun, Jul 12, 2009 at 23:33, Alexander Chemeris<[email protected]> wrote: > Hi Andrew, > > Thank you for reporting the bug. > > I'll try to reproduce it, but it would be helpful if you post > backtrace of the crash. > > On Sat, Jul 11, 2009 at 1:57 AM, Paulo > Vicentini<[email protected]> wrote: >> to the list >> >> ---------- Forwarded message ---------- >> From: Andrew Lavigne <[email protected]> >> Date: Fri, Jul 10, 2009 at 6:13 PM >> Subject: RE: [sipxtapi-dev] Input audio sometimes not connected >> properly >> To: Paulo Vicentini <[email protected]>, Keith Kyzivat >> <[email protected]> >> >> >> So, I've moved to the main branch. The good news is that my issue >> with the RTP stream changing and packets being dropped is now ok - >> the packets from the new stream (with a new SSRC) are now accepted. >> Many thanks for your replies - they pointed me in the right direction. >> >> The bad news is that I now seem to be getting an execption thrown >> when I try to set the audio input device to NONE, like so: >> >> sipxAudioSetCallInputDevice(g_hInst, "NONE"); >> >> This was working fine in the 3.2 branch, but now it throws an >> exception >> >> "Unhandled exception at 0x10148c96 (sipXtapid.dll) in >> TelephonyIntegration.exe: 0xC0000005: Access violation reading >> location 0x0000001c." >> >> It would appear to be the following bit of code is where it >> encounters this in OsMsgPool::findFreeMsg(), on the NULL != mpMutex check. >> >> if (NULL != mpMutex) >> { >> mpMutex->acquire(); >> } >> >> I'm not sure why this is happening now, but not before. Any clue as >> to why this is so? In any case, I will investigate.... >> >> ...Andrew >> >> ________________________________ >> From: Paulo Vicentini [mailto:[email protected]] >> Sent: Friday, July 10, 2009 3:59 PM >> To: Keith Kyzivat >> Cc: Lavigne, Andrew (CAR:PC00); [email protected] >> Subject: Re: [sipxtapi-dev] Input audio sometimes not connected >> properly >> >> Hi, >> SSRC changes will not be an issue for you in the main branch, but we >> should still address suddenly changes on TS and Seq (while SSRC keeps >> the same) Paulo On Fri, Jul 10, 2009 at 2:45 PM, Keith Kyzivat >> <[email protected]> wrote: >>> >>> Last I knew, you should not be too worried -- Alex has been trying >>> to keep it solid and stable, even with addition of new features. >>> On Fri, Jul 10, 2009 at 1:43 PM, Andrew Lavigne >>> <[email protected]> >>> wrote: >>>> >>>> Hi again. >>>> >>>> I checked out the latest main branch >>>> (http://scm.sipfoundry.org/rep/sipX/main) and I do see the methods >>>> you describe below. I had been using the 3.2 version because on >>>> the sipxtapi web page it says that the 3.2 branch is "Active, >>>> Stable; Receive only bugfixes", whereas the main branch says that >>>> the status is "Active". (and I wanted something stable and >>>> working) >>>> >>>> It would seem, however, that I need the latest functionality. I'm >>>> going to compile and try using the latest main version and see if this >>>> helps. >>>> >>>> Should I be concerned about stability if I use the latest on main? >>>> >>>> ...Andrew >>>> >>>> --- original message --- >>>> >>>> >>>> Hi, Paulo >>>> >>>> Thanks for replying. >>>> >>>> Interesting... I don't have these methods in my code base. Looks >>>> like maybe I'm not using the right / most recent load. >>>> >>>> This is my subversion URL: >>>> >>>> http://scm.sipfoundry.org/rep/sipX/branches/sipXtapi-3.2 >>>> >>>> Should I be using something different? >>>> >>>> Thanks, >>>> ...Andrew >>>> >>>> >>>> ________________________________ >>>> From: Paulo Vicentini [mailto:[email protected]] >>>> Sent: Friday, July 10, 2009 11:24 AM >>>> To: Lavigne, Andrew (CAR:PC00) >>>> Cc: Alexander Chemeris; [email protected] >>>> Subject: Re: [sipxtapi-dev] Input audio sometimes not connected >>>> properly >>>> >>>> Hi, >>>> Check if these functions below were called. >>>> if "SSRC id changes" - Then mediaLib should detect it (at least it >>>> used to work). >>>> I had an issue when SSRC remained the same while Seq and >>>> TimeStamp sudden changed. >>>> >>>> >>>> void MprRtpDispatcher::MpRtpStream::setSSRC(RtpSRC ssrc) { >>>> // Reset decoder if this is not the first time setSSRC() is called. >>>> // Note, that we deliberately does not check whether SSRC really >>>> changed. >>>> // We trust caller to perform this check. Furthermore some broken >>>> // implementations does not change SSRC on a new stream start. >>>> if (mAddress != 0 && mpDecode != NULL) >>>> { >>>> mpDecode->reset(); >>>> } >>>> >>>> setValue(ssrc); >>>> } >>>> >>>> /**************************************************/ >>>> UtlBoolean MprDecode::handleReset() { >>>> OsLock lock(mLock); >>>> >>>> // Reset JB, JBE and dejitter >>>> mpJB->reset(); >>>> mpJbEstimationState->reset(); >>>> if (mpMyDJ != NULL) >>>> { >>>> mpMyDJ->reset(); >>>> } >>>> >>>> mIsStreamInitialized = FALSE; >>>> mNumPrevCodecs = 0; >>>> >>>> return TRUE; >>>> } >>>> Paulo >>>> On Fri, Jul 10, 2009 at 10:51 AM, Andrew Lavigne >>>> <[email protected]> >>>> wrote: >>>>> >>>>> Hi, Alexander >>>>> >>>>> Thanks for your reply. Much appreciated. (and the other reply, too). >>>>> >>>>> Good to hear that the re-INVITE works for you. I've done a little >>>>> digging inside the code and it seems to me that something is >>>>> getting confused in the dejitter buffer (class MprDejitter in >>>>> sipXmediaLib). >>>>> >>>>> During the re-INVITE scenario, the media gateway switches over to >>>>> a new RTP stream (it is sending me a PCMA RTP stream before the >>>>> re-INVITE, then switches to a PCMU RTP stream afterwards. The SIP >>>>> exchange contains the proper SDP negotiation for the new codec type). >>>>> >>>>> In the trace fragment below, 47.129.106.75 is my little test >>>>> client, and >>>>> 47.135.211.232 is the media gateway that is hosting the audio conference. >>>>> You can see that the media gateway is sending PCMA RTP packets up >>>>> until the time where it sends the SIP re-INVITE. My test client >>>>> then replies with the appropriate SIP messages. In the SDP data >>>>> (which I've not included here) associated with these SIP messages, >>>>> a new port and new codec is negotiated for the new RTP stream that >>>>> will be sent by the media gateway after the re-INVITE. Then, the >>>>> media gateway starts sending packets along this new RTP stream. >>>>> >>>>> So, here's the interesting point: >>>>> >>>>> The packet stream going from my client to the media gateway >>>>> changes it's codec from PCMA to PCMU, but the timestamp, sequence >>>>> number maintain their incrementing sequence, and SSRC id remains >>>>> unchanged. However, for the packet stream coming back from my >>>>> media gateway, the timestamp and sequence number are reset to new >>>>> values, and the SSRC id changes. This is the part that seems to >>>>> trip up code in MprDejitter. In the method pullPacket(), there's >>>>> a check that compares an existing timestamp value with the >>>>> timestamp value from a new packet. This check causes the code >>>>> that retrieves the packet to be bypassed, effectively causing the >>>>> packet to be dropped. All of the packets from the point of switchover on >>>>> get dropped because of this (and this is probably why I don't hear >>>>> anything after this point). >>>>> >>>>> So, the question is this: is the media gateway doing something >>>>> improper by switching to a new SSRC id, and resetting sequence id >>>>> and timestamp? Or is there something amiss with this bit of >>>>> logic in pullPacket(). I'm not familiar enough with the standards to >>>>> know this is valid behavior or not. >>>>> >>>>> >>>>> >>>>> No. Time Source Destination Protocol >>>>> Info >>>>> 3494 24.633243000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=618, Time=885647077 >>>>> 3495 24.651004000 47.135.211.232 47.129.106.75 >>>>> RTP >>>>> PT=ITU-T G.711 PCMA, SSRC=0x95070000, Seq=2941, Time=3132451048 >>>>> 3496 24.653266000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=619, Time=885647237 >>>>> 3497 24.670539000 47.135.211.232 47.129.106.75 >>>>> RTP >>>>> PT=ITU-T G.711 PCMA, SSRC=0x95070000, Seq=2942, Time=3132451208 >>>>> 3498 24.673185000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=620, Time=885647397 >>>>> 3500 24.691061000 47.135.211.232 47.129.106.75 SIP/SDP >>>>> Request: INVITE sip:[email protected]:6060, with >>>>> session description >>>>> 3501 24.693107000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMA, SSRC=0x4A5425E6, Seq=621, Time=885647557 >>>>> 3502 24.693878000 47.135.211.232 47.129.106.75 >>>>> ICMP >>>>> Destination unreachable (Port unreachable) >>>>> 3503 24.695575000 47.129.106.75 47.135.211.232 >>>>> SIP >>>>> Status: 100 Trying >>>>> 3504 24.699837000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> Unknown RTP version 0 >>>>> 3506 24.700186000 47.135.211.232 47.129.106.75 >>>>> ICMP >>>>> Destination unreachable (Port unreachable) >>>>> 3508 24.707695000 47.129.106.75 47.135.211.232 >>>>> SIP/SDP Status: 200 OK, with session description >>>>> 3509 24.713177000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=622, Time=885647717 >>>>> 3510 24.713955000 47.135.211.232 47.129.106.75 >>>>> ICMP >>>>> Destination unreachable (Port unreachable) >>>>> 3511 24.719948000 47.135.211.232 47.129.106.75 >>>>> SIP >>>>> Request: ACK sip:[email protected]:6060 >>>>> 3512 24.733115000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=623, Time=885647877 >>>>> 3521 24.753133000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=624, Time=885648037 >>>>> 3522 24.758177000 47.135.211.232 47.129.106.75 >>>>> RTP >>>>> PT=ITU-T G.711 PCMU, SSRC=0xE8E, Seq=22427, Time=26582 >>>>> 3523 24.773143000 47.129.106.75 47.135.211.232 >>>>> RTP >>>>> PT=ITU-T G.711 PCMU, SSRC=0x4A5425E6, Seq=625, Time=885648197 >>>>> 3524 24.778966000 47.135.211.232 47.129.106.75 >>>>> RTP >>>>> PT=ITU-T G.711 PCMU, SSRC=0xE8E, Seq=22428, Time=26742 >>>>> [... Etc etc ... ] >>>>> >>>>> ...Andrew >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] >>>>> [mailto:[email protected]] >>>>> On Behalf Of Alexander Chemeris >>>>> Sent: Thursday, July 09, 2009 3:25 PM >>>>> To: Lavigne, Andrew (CAR:PC00) >>>>> Cc: [email protected] >>>>> Subject: Re: [sipxtapi-dev] Input audio sometimes not connected >>>>> properly >>>>> >>>>> Hi Andrew, >>>>> >>>>> We use sipXtapi a lot with our own Bridge (also sipXtapi-based), >>>>> and it works perfectly with re-INVITE. So, no, this issue is not known. >>>>> It would be helpful if you post here WireShark capture of the >>>>> session with the note when audio is lost. Then we'll be able to see >>>>> what's going. >>>>> >>>>> Also I'd recommend to add a simple audio logging to a file to >>>>> MprDecode::doProcessFrame(). Just create a file, named after >>>>> resource name >>>>> (getName()) and write all audio data from 'outBufs[0]' >>>>> right before "return TRUE". Then look into the file - what does it >>>>> contains. >>>>> >>>>> On Thu, Jul 9, 2009 at 7:43 PM, Andrew >>>>> Lavigne<[email protected]> >>>>> wrote: >>>>> > Hi, All >>>>> > >>>>> > I'm getting the sense that this list is not all that active. >>>>> > Still, I have a troublesome issue upon which I really really >>>>> > hope someone can give me some insight. >>>>> > >>>>> > Using a simple little client with Sipxtapi, I'm setting up a SIP >>>>> > call with an audio RTP stream to an audio conference bridge on a >>>>> > media gateway. >>>>> > Mostly, everything gets set up ok: The initial SIP Invite goes >>>>> > as expected, the initial RTP stream for setting up the >>>>> > conference works perfectly fine. >>>>> > Then, the media gateway sends my client a sip re-INVITE, along >>>>> > with a new SDP for the new audio stream that will be used for >>>>> > the actual conference. >>>>> > I'm looking at the SIP and RTP data in wireshark and everything >>>>> > gets set up perfectly... >>>>> > >>>>> > EXCEPT that most of the time, the RTP stream that comes back >>>>> > from the media gateway into sipxtapi seems to be improperly >>>>> > connected up. I see the proper RTP packets coming into >>>>> > sipxtapi, but I hear nothing in my speakers. Once in a blue >>>>> > moon, the issue does not manifest and I hear everything fine. >>>>> > Then I'll run it again and - poof - no audio can be heard (even >>>>> > though in wireshark I can clearly see it being sent from the >>>>> > media gateway into my app). >>>>> > >>>>> > It seems like something is not quite right down in the medialib >>>>> > somewhere - some sort of race condition or timing issue. >>>>> > Sometimes it works, sometimes it doesn't. I'm poking around, >>>>> > placing debug lines and breakpoints, trying to isolate the problem, but >>>>> > so far no luck. >>>>> > My questions to any experts out there are: >>>>> > >>>>> > 1) is there any sort of known issue like this in sipxmedialib? >>>>> > If so, is there some easy workaround? >>>>> > 2) any sort of hint as to where I'd look in order to verify if >>>>> > the RTP packets are getting mixed in properly into the Flow >>>>> > Graph? That would be helpful, too. >>>>> > >>>>> > 3) any other ideas that I have not yet thought of. >>>>> > >>>>> > Please, please... if anyone knowledgeable is out there reading >>>>> > this, could they please give me a few minutes of their time. I >>>>> > would be most appreciative. This bug (I'm going to call it a >>>>> > bug until proven >>>>> > otherwise) is really wasting a lot of my time. >>>>> > >>>>> > Many thanks x 100, >>>>> > ...Andrew Lavigne >>>>> > >>>>> > _______________________________________________ >>>>> > sipxtapi-dev mailing list >>>>> > [email protected] List Archive: >>>>> > http://list.sipfoundry.org/archive/sipxtapi-dev/ >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Alexander Chemeris. >>>>> >>>>> SIPez LLC. >>>>> SIP VoIP, IM and Presence Consulting http://www.SIPez.com >>>>> tel: +1 (617) 273-4000 >>>>> _______________________________________________ >>>>> sipxtapi-dev mailing list >>>>> [email protected] >>>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ >>>> >>>> >>>> _______________________________________________ >>>> sipxtapi-dev mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ >>> >> >> >> >> _______________________________________________ >> sipxtapi-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ >> > > > > -- > Regards, > Alexander Chemeris. > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 > -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
