Try using the mainline -- that has the most up to date code. On Fri, Jul 10, 2009 at 1:25 PM, Andrew Lavigne <[email protected]> wrote:
> 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/
