[Asterisk-Dev] unreliable handling of rfc2833 events [Was: Re: Asterisk Dev wanted for quick job]

[James H. Cloos Jr.]

I spent some time last night on this, but wasn't fully successful..

Each keypress on my ata186 generates three 2833 packets with
marker=1, duration=0 and incrementing sequence numbers, followed by
one packet for each 160 of duration with marker=0 and duration
160, 320, ... and then three packets with end=1, marker=0, duration
constant and incrementing sequence numbers.

The packet traces on Phil's box showed a similar pattern except that
the marker packets were not duplicated and the three end packets all
had the same sequence number.  The packets also arrived out of order.

My idea was to ignore all 2833 event packets that duplicate ones
already seen.  Ie, if the tiemstamp, duration and type are the
same as the last 2833 seen then ignore it.

The result did eliminate duplicates, but at the cost of loosing the
occasional digit.  The loss was somewhat predictable: all entries of
5 digit vm box and passwd lost at least one digit during our tests.

I stored the extra state in two extra fields in the ast_rtp struct
as passed to ast_rtp_read().

It looks like an idempotency issue, but at this point I'm not sure
what the proper solution is.

Any thoughts?

-JimC