[Asterisk-Dev] Brown paper bag time [Was: Re: unreliable handling of rfc2833 events]

[James H. Cloos Jr.]

[SIGH]

I took another look at the packet trace in ethereal, and found
something I'd missed before, thanks to better display filtering.

The duplicated digits are a bug on the phone, not a problem with *.

One example goes like this:

 seq   ts   dur
---- ------ ---
3912 680384 0    (marker)
3916 680384 320
3914 680384 160
3920 680384 640
3918 680384 480
3922 680384 800
3924 680384 960  (end)
3924 680384 960  (end)
3924 680384 960  (end)
3929 681984 0    (marker)
3931 681984 160
3935 681984 480
3933 681984 320
3937 681984 640
3939 681984 800
3943 681984 1120 (end)
3941 681984 960
3943 681984 1120 (end)
3943 681984 1120 (end)

So there is either a problem with the phone's keyboard
or with its firmware.

I don't see any way for * to deal with this unless it uses the
heuristic that two identical events should have some space between
them.  (You'll notice above that the first event's ts+dur equals the
2nd event's ts.)

That would mean storing the event type, ts and final duration, and
ignoring events that match the old type and have a ts == the old
event's ts + dur.  

Any thoughts on that?


Incidently, regarding the three end packets, rfc 2833 says:

2833> If there has been no new event in the last interval, the event
2833> SHOULD be retransmitted three times or until the next event is
2833> recognized. This ensures that the duration of the event can be
2833> recognized correctly even if the last packet for an event is
2833> lost.

That doesn't say whether the seq should increment with the packets,
and even cisco's own firmware disagrees amongst themselves on that.

-JimC