Hi, Andrew Just wondering - what is the use-case? We should better understand what users use ;)
On Mon, Jul 13, 2009 at 21:09, Andrew Lavigne<alavi...@nortel.com> wrote: > 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: alexander.cheme...@gmail.com [mailto:alexander.cheme...@gmail.com] On > Behalf Of Alexander Chemeris > Sent: Sunday, July 12, 2009 7:01 PM > To: Paulo Vicentini; Lavigne, Andrew (CAR:PC00) > Cc: sipxtapi-dev@list.sipfoundry.org > 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<alexander.cheme...@sipez.com> 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<vicentini.pa...@gmail.com> wrote: >>> to the list >>> >>> ---------- Forwarded message ---------- >>> From: Andrew Lavigne <alavi...@nortel.com> >>> Date: Fri, Jul 10, 2009 at 6:13 PM >>> Subject: RE: [sipxtapi-dev] Input audio sometimes not connected >>> properly >>> To: Paulo Vicentini <vicentini.pa...@gmail.com>, Keith Kyzivat >>> <kam...@gmail.com> >>> >>> >>> 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:vicentini.pa...@gmail.com] >>> Sent: Friday, July 10, 2009 3:59 PM >>> To: Keith Kyzivat >>> Cc: Lavigne, Andrew (CAR:PC00); sipxtapi-dev@list.sipfoundry.org >>> 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 >>> <kam...@gmail.com> 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 >>>> <alavi...@nortel.com> >>>> 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:vicentini.pa...@gmail.com] >>>>> Sent: Friday, July 10, 2009 11:24 AM >>>>> To: Lavigne, Andrew (CAR:PC00) >>>>> Cc: Alexander Chemeris; sipxtapi-dev@list.sipfoundry.org >>>>> 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 >>>>> <alavi...@nortel.com> >>>>> 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:telephony_t...@47.129.106.75: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:telephony_t...@47.129.106.75: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: alexander.cheme...@gmail.com >>>>>> [mailto:alexander.cheme...@gmail.com] >>>>>> On Behalf Of Alexander Chemeris >>>>>> Sent: Thursday, July 09, 2009 3:25 PM >>>>>> To: Lavigne, Andrew (CAR:PC00) >>>>>> Cc: sipxtapi-dev@list.sipfoundry.org >>>>>> 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<alavi...@nortel.com> >>>>>> 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 >>>>>> > sipxtapi-dev@list.sipfoundry.org 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 >>>>>> sipxtapi-dev@list.sipfoundry.org >>>>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> sipxtapi-dev mailing list >>>>> sipxtapi-dev@list.sipfoundry.org >>>>> List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ >>>> >>> >>> >>> >>> _______________________________________________ >>> sipxtapi-dev mailing list >>> sipxtapi-dev@list.sipfoundry.org >>> 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 > -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ sipxtapi-dev mailing list sipxtapi-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
