[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] 2833bis - hook events




Henning Schulzrinne wrote:

> > 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.
>
> However, there are devices that have a "flash" button (seems to be
> popular in Europe). For these devices, sending a single event seems
> easiest.

Right, but they should not also be sending on-hook and off-hook events as states
since you would then effectively be sending the flash twice.


> I thought Flash was used to switch between parties during call
> waiting?
>

It is, but it is still just an off-to-on-to-off hook transition.

>
> >
> > 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.
>
> Flash hook it seems to be part of the possible AT command (D) modem
> dialing sequences, shown as a !, as in ATD123!45. See, for example,
> http://supportmech.virtualave.net/at-command.htm
>
> That said, I'm not quite sure what your suggestion is for 2833bis.
>

My suggestion is to make the on-hook/off-hook events mutually exclusive with the
flash hook events (states) so there won't be any ambiguity between them.
Otherwise, we need so say something about how to treat the ambiguity that
currently exists.

-- Flemming


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