Subject: Re: [AVT] 2833bis

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Oct 2002 16:43:56 -0400

Sorry for the delay in getting back to this draft. I'm ready to do 
another update; comments below. I've split my response into several 
messages to keep the follow-up manageable.

Flemming Andreasen wrote:

> Questions/Comments
> ================
> p.5: After the sentence "A compliant implementation MUST support the 
> events
> listed in Table 1 with the exception of "flash"."  the implementation note
> "Implementations can support events 0 through 15 (DTMF) by simply 
> ignoring the
> packets, but MUST declare all event numbers that are meaningful to it 
> in the
> fmtp parameter, including 0 through 15."
> should be added (and/or perhaps in Section 3.9). Also on p. 25 (Optional
> parameters).

The last part "including 0 through 15" contradicts RFC 2833. Or are you 
suggesting that inclusion implies a higher level of support beyond just 
swallowing packets whole? This would still mean that RFC 2833 wouldn't 
declare this, even if they did something "meaningful" with the packets. 
In general, I don't think that distinguishing processing behavior is 
useful, since there doesn't seem to be a bright line. What exactly does 
"meaningful" mean? I can see that this probably means "regenerate the 
tone" for a gateway, but what about other devices?

> p.6-8: There seem to be some minor inconsistencies and ambiguities 
> introduced
> by the new state event concept.
> - Timestamp: It's not clear if the duration value "0" can only be used 
> with
> state events or not.

Yes. I don't think we want this for other types of events, since it 
could mean that a tone gets "stuck" forever. I'll reference the 'state' 
flag in the table explicitly.

>
> - duration: The definition states "...has so far lasted as long as 
> indicated by
> this parameter.", however this is inconsistent with the duration "0", 
> and also
> seems inconsistent with the definition of state events under the "E:" 
> (end bit)
> definition that follows:
> - E (end bit):  The new text seems to imply that state event can be 
> sent with
> an "anticipated or good till cancelled duration", i.e. not necessarily 
> just the
> duration so far, however as noted, this is inconsistent with the 
> "duration"
> parameter. It's also not entirely clear if this is only allowed for state
> events (I assume so). Rephrasing parts of the paragraph might aid in the
> understanding here too.

The description after "Some events..." was left over from an earlier 
discussion of states and contradicts the zero-duration rule. It assumes 
a non-zero indication, basically a time-out value after which the state 
is reset unless it is refreshed. I think zero is simpler to implement, 
but the timeout value might make for a reasonable soft-state 
implementation that avoids systems getting "stuck" after packet loss. 
I'd appreciate feedback on this.

[More to follow]

Henning

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Oct 2002 17:02:42 -0400

> - V.21 data bits:  It would be nice if we had a more efficient way of 
> sending
> V.21 data bits which also doesn't require us to use RFC 2198 
> redundancy. We
> could for example define two new events (one for each V.21 channel) 
> that simply
> use the (otherwise unused) volume field to encode the actual bit 
> values. That
> would enable us to send 20 ms of V.21 data bits in a single event.
> Alternatively, we could consider encoding it in the duration field as well
> (e.g. have volume indicate number of bits and duration the actual 
> bits), but
> that seems more inconsistent (it would on the other hand allow us to 
> encode up
> to the recommended 50 ms).

I'd rather not mess with the duration field, since that seems to 
possibly break things and requires more special-casing. I added the 
first option. Also, you need the duration to indicate which bits are 
actually valid. Otherwise, how would you express 0101, say?

[more to follow...]

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Oct 2002 17:07:13 -0400

> - 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.

>
> 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?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Oct 2002 17:15:26 -0400

> - 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...

> Do we keep the state as
> off-hook, and then send a flash-hook, or do we change off-hook to 
> on-hook to
> off-hook ? In the latter case, do we still send the flash-hook event ?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Oct 2002 17:24:38 -0400

Continuing on Flemming's comments:

>
> Other:
> =====
> RTP continuity:     Continuity tests are being performed in the PSTN 
> to verify
> the operation of the trunk over which your call is setup. It turns 
> out, that
> it's very useful to have a similar capability to verify continuity of 
> an RTP
> session. While RTCP does offer some help in this area, it's not a complete
> solution for a couple of reasons; 1) the RTP and RTCP destination 
> ports differ,
> 2) you can't force the other party to actually send you an RTCP packet 
> when you
> would like to (e.g. immediately to verify RTP continuity on call 
> setup). If we
> had something like a "ping" and a "pong" event, it would be very 
> helpful (if
> you get a "ping", you send a "pong"). Comments ?

Clearly, this would only make work if you knew ahead of time whether the 
other side supports this feature. I can see the usefulness of this 
feature, but there are some details that may make this more than just 
another special event. A few questions:

(1) Who should send this? Clearly, end systems, but what about RTP 
mixers and translators?

(2) If mixers just replicate the packet without knowledge of the 
content, they'll get a response from each participant. Is that ok?

(3) What happens if you send this to a multicast address with 10,000 
participants? The sender and receiver may not actually know that this is 
multicast, since there may be a translator that bridges between unicast 
and multicast. The translator may also be ignorant of the special 2833 
event type (and 2833 in general), but will quickly figure out that it 
did something special, after getting flooded with 10,000 "pong" packets...

With RTCP, we have rate-limiting options in place which deal with these 
issues, particularly (3).

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 23 Oct 2002 13:14:58 -0400

> tone" for a gateway, but what about other devices?

RFC 2833 states that

    "Since all implementations MUST be able to receive events 0 through
   15, listing these events in the a=fmtp line is OPTIONAL.

There was some discussion about how appropriate this really was, and I believe
it was generally agreed, that mandating that all implementations of RFC 2833
support DTMF was not the right thing to do. For example, if I only want to
convey V.25/V.8 ANS and ANSam, then why not ? Thus, the following implementation
note was added at http://www.cs.columbia.edu/~hgs/rtp/payload_audio.html:

    "Implementations can support events 0 through 15 (DTMF) by simply ignoring
the packets, but MUST declare all event numbers that are meaningful to it in the
fmtp parameter, including 0 through 15."

Taking a look at Section 3.9 in 2833bis, I see the offending text is no longer
there. If it doesn't say anything else about mandatory and implied DTMF support
anywhere else, then I'm happy.

> I'd appreciate feedback on this.

I like the soft-state idea. It has some nice self-synchronizing properties that
would seem to make the whole "state" concept less susceptible to errors (whether
human or network induced). If there are "good til cancelled" states that need to
be communicated to the other party, and for which the soft-state approach is not
acceptable or desirable, then I wonder if a call control protocol wouldn't be a
more appropriate means of signaling such things.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 23 Oct 2002 13:22:00 -0400

> actually valid. Otherwise, how would you express 0101, say?

You could special-case everything but I agree that the first option is
preferable.

Nit:    Both entries in Table 3 for V.21 compressed say "channel 1". One of them
should say "channel 2".

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 23 Oct 2002 13:33:25 -0400

> 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.

> By sending a different one? Anybody know for sure?

Not me.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 23 Oct 2002 13:53:40 -0400

> 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

---

From: "Rex Coldren" <[email-masked]>
Date: Wed, 23 Oct 2002 10:59:19 -0700

> > By sending a different one? Anybody know for sure?

ABCD signaling events are all mutually exclusive states.  The most recent one
rules (i.e. "turns off" the previous one).

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 23 Oct 2002 14:44:18 -0400

> (1) Who should send this? Clearly, end systems, but what about RTP

I was only considering end-systems.

> content, they'll get a response from each participant. Is that ok?

Only if we can guarantee that they won't be flooded with packets, but per (3),
that seems to be rather difficult.

> did something special, after getting flooded with 10,000 "pong" packets...

Hmm, that's a good question. I suppose an answer along the lines of ""we would
only do it if we knew that" won't be satisfactory...
We wan't to send as soon as possible, i.e. don't want to wait for any RTCP
reports, so we have no way of knowing or even guestimating the actual number of
RTP session participants based on RTCP. As you indicate, the presence of
translators means we have no reliable way of distinguishing a point-to-point
case (which is what I am interested in) from a point-to-multipoint or
multipoint-to-multipoint case based on IP-address information.

This all seem to suggest that the only solution is
1) End systems must not use it if you believe you are not doing point-to-point
(use of multicast would probably imply that it is not point-to-point)
2) Mixers and translators must not support these packets if they believe they
are engaged in a multipoint session.

In general, we can't expect mixers and translators to apply special processing
to some RTP packets, so we would have to require, that any session description
containing the destination address of a mixer or translator cannot violate 2)
above. That in turn would seem to imply that any such session description would
have to be generated by the mixer or translator itself (and hence it would have
to actively announce use of these events for them to be used) as opposed to e.g.
some middle-man just changing the destination address in a session description
without looking further into what is actually going. That's probably not a
viable path forward.

Any good suggestions ?

-- Flemming

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Oct 2002 15:04:45 -0400

> also argues for only sending the raw on-hook and off-hook states and 

However, there are devices that have a "flash" button (seems to be 
popular in Europe). For these devices, sending a single event seems 
easiest. I thought Flash was used to switch between parties during call 
waiting?

> 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.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 23 Oct 2002 15:27:43 -0400

Henning Schulzrinne wrote:

> 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.

> 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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Oct 2002 10:52:43 -0400

As your note points out, you'd have to be a lawyer to deal with all the 
corner cases where things could go wrong, particularly since translators 
and mixers may not always be visible to the parties initiating the session.

There's also another, non-multicast problem: You have to be really 
careful that you don't inadvertently create a DOS mechanism. You won't 
get amplification, but the system now has to check for various no-no 
addresses (local broadcast, multicast) to make sure the return address 
is safe.

It might help to determine what types of diagnostics problems this is 
supposed to solve; maybe there's another way. (One possibility would be 
a triggered RTCP message that "uses up" the RTCP bandwidth allocation 
and is subject to the usual reconsideration rules.) This still doesn't 
address the same-port-as-RTP requirement you posed, but it should 
diagnose most likely problems.

My general concern is that the mechanism better be simple, or nobody 
will implement it, defeating its usefulness as a diagnostic tool.

Thus, can you summarize the problems that this mechanism is supposed to 
solve?

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Oct 2002 11:19:06 -0400

> addresses (local broadcast, multicast) to make sure the return address

Actually, I wasn't planning on sending the "pong" back to the source address if
that's what you're implying. Rather, it should go where all other RTP packets
for the session goes.

> Thus, can you summarize the problems that this mechanism is supposed to

1) Verify, in real-time, that RTP packets sent to the destination are actually
received (keeping in mind that NATs, firewalls, etc. may play different tricks
on RTP and RTCP).
2) Perform 1 on demand (at least once), including during call setup.

-- Flemming

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Oct 2002 11:25:20 -0400

That makes more sense. Triggered media transmission is probably the 
right mental model. The flooding issues are still similar, including in 
large conferences with a mixer in the middle (where most of the time, 
only one person speaks).

Would a periodic RTP beacon serve the same purpose? Via RTCP, you'd know 
whether the other side has received the beacon.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Oct 2002 11:32:40 -0400

> since you would then effectively be sending the flash twice.

Certainly. I noted the exclusion, although I'd hope the temptation is 
low. I also added that receivers should ignore Flash if they are in 
explicitly signaled off-hook or on-hook state.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Oct 2002 11:43:37 -0400

> and B can change each other, and C and D can change each other, but 

Interesting question. So far, the only states are the ABCD states and 
on/off hook. In general, I would agree that state groups make the most 
sense. I'll just use the lowest event number as the state group 
identifier in the table, to avoid yet another namespace.

> Also, I noticed that off-hook and on-hook in table 4 are not marked as 

Yes.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Oct 2002 11:59:05 -0400

> whether the other side has received the beacon.

If you could send it when you need to and get the RTCP report back in
real-time, including during call setup, it would be just fine.

-- Flemming

---

From: Chuck Harrison <[email-masked]>
Date: Thu, 24 Oct 2002 10:18:15 -0700

Hi, all

> explicitly signaled off-hook or on-hook state.

Are you sure this is right? It's been a long time since I was
involved in telephony but I would think you go to off-hook state
for the duration of the call and that a "flash" would be a valid
*event* during an off-hook *state*. Flash during an on-hook state
would be invalid/ignored.

In the olden days you'd distinguish these with a copper slug on
the core of a relay. :-)

Cheers,
  Chuck

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Oct 2002 17:26:41 -0400

> In the olden days you'd distinguish these with a copper slug on

I guess just off-hook state would be ok since that's the default state 
anyway during a call. In any event, a receiver will have to be prepared 
to track hook state via either mechanism.