URGENT question on draft-ietf-avt-tones-07

[Stephen Casner]

To the IETF AVT working group and ITU SG16:

--> Interested parties need to respond by end of day PST Monday 2/14 <--

The following has come up during IESG discussion of the
draft-ietf-avt-tones-06.txt document:

> In section 3.11 there are two events (CRd and MRd) where the signals
> are different for the initiator and the responder.
> This implies that the entity doing the translation between audio and events
> need to be aware of the higher layer roles of the communicating peers.
> Is this a reasonable assumption?

This appears to be a valid concern that we did not realize in the
working group review of this document.  One would want the gateway
that is doing the translation from an event to a tone to not be
required to know the higher layer roles.

It would be possible to give two different codepoints to each of these
events.  I don't know if there has already been enough implementation
of this protocol that this would cause a problem, and the purpose of
this message is to find out.  Given that the modem and fax tones were
added fairly late in the development of the draft, I suspect is would
not be a problem to add two codepoints in that section (32-47) without
changing the other sections.

The author (Henning Schulzrinne) agreed:

> This is at least ambiguous, particularly for a "pass-through" gateway
> that's pretty clueless as to call state. There are effectively four tone
> sequences
>
> 1375/2002 followed by 1150
> 1529/2225 followed by 1150
> 1357/2002 followed by 1900
> 1529/2225 followed by 1900
>
> My suggestion would be to split the Crd and Mrd into Crdi and Crdr for
> the initiating and responding side. Same for the other pair.

The draft has been revised to make this split, so the codepoints 41-49
are now different.  The revised draft has been submitted but is
available in the meantime as:

http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.txt
http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.ps

I believe that, subject to this change, the draft has been approved by
the IESG.  If there are no objections from the working group by the
end of the day PST on Monday (2/14), then I will give our OK for the
-07 draft be sent to the RFC editor.  This is a very short response
time, but our goal is to get the RFC number assigned before the end of
the SG16 meeting on 2/18.  To those at the SG16 meeting, please call
this issue to the attention of interested parties that might not have
seen this message.
                                                -- Steve Casner