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.
...Carsten
> Hi All,
>
> I have just updated to a release 3.2, and know I seem to have
> an issue with the Jitter buffering and the RFC 4733 DTMF events.
>
> I am not sure what is going wrong, but as soon as the code receives a
> DTMF event the jitter buffer gets severely confused! From that
> point on incoming events and audio are not longer played.
>
> The actual mechanism of how the jitter buffer is meant to work
> seems obscure to me, I have not been able to figure out what is
> required to get it to go.
>
> In the code the variable, wantedBufferSamples, gets to be a very large
> negative number.
>
> If I disable the DTMF in the remote device, then the audio work correctly.
>
> Any suggestions?
>
> Regards
>
> Paul
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
