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