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/
