Re: [AVT] 2833bis - hook events

[Flemming Andreasen <fandreas@cisco.com>]

Henning Schulzrinne wrote:

> > - Flash hook, on-hook, and off-hook: If we actually use on-hook and
> > off-hook as
> > states, then how should we signal flash-hook ?
>
> Event 16 ("flash"). I'm probably missing something...
>

Flash-hook is a transition from off-hook to on-hook and then, within 200-300
ms to 1100-1550 ms, another transition back to on-hook. Thus all we are
really observing is off-hook and on-hook, just with certain durations. To
make things more complicated, there is something called flash response
enabled timing and flash response disabled timing. In the flash response
disabled case, a transition to on-hook lasting from 200-400 ms and up will
be a disconnect and hence a subsequent off-hook transition will never imply
a flash. In the flash response enable case, the previously mentioned timing
considerations apply and hence we may see a flash.

Thus, if we are sending on-hook and off-hook events, then we can detect if
there is flash or not (or more accurately, I believe we are in just a good
or bad position as the sending party to determine whether a flash occurred
or not). This in itself makes the flash event redundant when used with the
on-hook and off-hook events. Secondly, it's not clear that the sending party
actually knows whether we want flash response enabled timing or not. This
also argues for only sending the raw on-hook and off-hook states and not the
flash event.

Now it might be useful to keep the event so you can simply monitor for
flash-hook (without general on-hook and off-hook state), however I'm not
sure what the application for this is. I vaguely recall some operator
services looking for a customer flash-hook to get the operator back on-line,
but could be wrong. Whether RFC 2833 would be the right solution for this is
perhaps another question.

-- Flemming


>

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt