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

Re: [AVT] 2833bis




Henning Schulzrinne wrote:

> > - States in tables:  Which events are states is open for debate I
> > guess, but
> > the fewer we have, the better it would seem. A guiding principle for
> > whether
> > something can be a state should be that there must be an easy and
> > reliable way
> > of getting rid of that state (not least considering the special
> > duration "0").
> > Thus for every state event there must be another state event (or something
> > else, e.g. non-RFC 2833 media) that can obsolete that state event.
> > With that in
> > mind, there seems to be (only ?) two additional events that qualify,
> > namely
> > on-hook and off-hook in table 4.
>
> I agree with your principle. See also my response regarding duration 0
> vs. duration with refresh, which bears on this discussion.
>

OK. Section 3.5 now says that

    "Some events are actually states, i.e., the appearence of a   |
     different named event implies the end of the previous        |
     state. Thus, for named RTP events labeled "state" in Tables  |
     1 through 5, sending of a packet with the "E" bit set is     |
     OPTIONAL. State events are sent with zero duration."

Does this mean that once I send an RFC 2833 "state" event, then any other RFC
2833 event will obsolete that state, or is it only another "state" event that
will negate it ? It would seem that only "state" events should be able to
obsolete another "state" event. Furthermore, it's also not clear to me whether
such "state" events need to be divided in groups, so that e.g. state events A,
and B can change each other, and C and D can change each other, but neither A or
B can affect C or D.

Also, I noticed that off-hook and on-hook in table 4 are not marked as states. I
assume that's an error.

>
> >
> > Question: Do all of the ABCD signaling events define a state ? How do
> > you "turn
> > off" the individual ABCD states ?
> >
> By sending a different one? Anybody know for sure?

Not me.

-- Flemming

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