Re: [AVT] 2833bis
Flemming Andreasen <fandreas@cisco.com> Wed, 23 October 2002 17:32 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26614 for <avt-archive@odin.ietf.org>; Wed, 23 Oct 2002 13:32:52 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9NHYiT12543 for avt-archive@odin.ietf.org; Wed, 23 Oct 2002 13:34:44 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NHYJv12523; Wed, 23 Oct 2002 13:34:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NHXov12491 for <avt@optimus.ietf.org>; Wed, 23 Oct 2002 13:33:50 -0400
Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26540 for <avt@ietf.org>; Wed, 23 Oct 2002 13:31:27 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NHXSIm018549; Wed, 23 Oct 2002 10:33:28 -0700 (PDT)
Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NHXQ4J020557; Wed, 23 Oct 2002 10:33:27 -0700 (PDT)
Received: from cisco.com (che-vpn2-24.cisco.com [10.86.244.24]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA08108; Wed, 23 Oct 2002 10:33:25 -0700 (PDT)
Message-ID: <3DB6DD65.9D454795@cisco.com>
Date: Wed, 23 Oct 2002 13:33:25 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: avt@ietf.org
Subject: Re: [AVT] 2833bis
References: <3CF3F6E3.3080602@cs.columbia.edu> <3D3731FB.E0FA609E@cisco.com> <3DB46C81.40804@cs.columbia.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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
- [AVT] 2833bis Henning Schulzrinne
- Re: [AVT] 2833bis Flemming Andreasen
- Re: [AVT] 2833bis Henning Schulzrinne
- Re: [AVT] 2833bis - V.21 Henning Schulzrinne
- Re: [AVT] 2833bis Henning Schulzrinne
- Re: [AVT] 2833bis - hook events Henning Schulzrinne
- Re: [AVT] 2833bis - RTP ping Henning Schulzrinne
- Re: [AVT] 2833bis Flemming Andreasen
- Re: [AVT] 2833bis - V.21 Flemming Andreasen
- Re: [AVT] 2833bis Flemming Andreasen
- Re: [AVT] 2833bis - hook events Flemming Andreasen
- Re: [AVT] 2833bis Rex Coldren
- Re: [AVT] 2833bis - RTP ping Flemming Andreasen
- Re: [AVT] 2833bis - hook events Henning Schulzrinne
- Re: [AVT] 2833bis - hook events Flemming Andreasen
- Re: [AVT] 2833bis - RTP ping Henning Schulzrinne
- Re: [AVT] 2833bis - RTP ping Flemming Andreasen
- Re: [AVT] 2833bis - RTP ping Henning Schulzrinne
- Re: [AVT] 2833bis - hook events Henning Schulzrinne
- Re: [AVT] 2833bis Henning Schulzrinne
- Re: [AVT] 2833bis - RTP ping Flemming Andreasen
- Re: [AVT] 2833bis - hook events Chuck Harrison
- Re: [AVT] 2833bis - hook events Henning Schulzrinne
- Re: [AVT] 2833bis Henning Schulzrinne