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/
