Carsten Avenhaus wrote: > Hi, > > I think wantedBufferSamples is normally around -80. > When the DTMF is received, mStreamState.rtpStreamHint changes from 0 to a > large number, > which causes wantedBufferSamples to become a large negative number. > mStreamState.rtpStreamHint is changed in > MprDecode::pushPacket()->MpJbeFixed::update() > > Apparently this happens when there is a jump in rtp->timestamp . > My guess is that the DTMF events may have different time stamps than the > normal audio > which causes this problem. Does it make sense to not call > MpJbeFixed::update() for > telephone-event RTP packets? > > I am also having a similar problem when I am aborting a supervised transfer. > There are new RTP streams, but MprDecode::pushPacket() does not reinitialize > the > RTP session. Again, this causes a jump in the expected rtp->timestamp, which > causes > the same problems as a bad rtp->timestamp from a DTMF.
The DTMF packets were from the same SSRC with the same time stamps as the audio stream. For my application I have re-worked the code to not call MprDecode::pushPacket() for DTMF packets, this then caused a problem that the DTMF packets never got decoded, I fixed this and my application is working fine now. Now all seems to work OK. Regards Paul _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
