Hi, I have faced an issue related to RTP stream: If the seq number and time of the received RTP packet is somehow reset ( while *ssrc* remains the *same*), playback is stopped That seq/time's change in the same SSRC may mislead the media processing For instance: got SIP 183.... incoming RTPs : SSRC=0xE2B0C9A5, Seq=231, Time=36960 SSRC=0xE2B0C9A5, Seq=232, Time=37120 SIP/SDP Status: 200 OK, with session description SSRC=0xE2B0C9A5, Seq=0, Time=0, Mark==== => *audio processing fails* SSRC=0xE2B0C9A5, Seq=1, Time=160 SSRC=0xE2B0C9A5, Seq=2, Time=320 Remote endpoint keeps SSRC but reset Seq / Time We would need to detect that change in the stream and to perform as the very SSRC had changed Paulo
On Thu, Jul 9, 2009 at 4:24 PM, Alexander Chemeris < alexander.cheme...@sipez.com> wrote: > 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/