Hi Andrew: This is a cool bug. Thank you so much for putting the time into this to identify the problem.
Cheers, Dan --- On Fri, 7/10/09, Andrew Lavigne <[email protected]> wrote: > From: Andrew Lavigne <[email protected]> > Subject: Re: [sipxtapi-dev] Input audio sometimes not connected properly > To: "Alexander Chemeris" <[email protected]> > Cc: [email protected] > Date: Friday, July 10, 2009, 9:51 AM > 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/
