The IESG has approved the following document: - 'Definition of Events For Channel-Oriented Telephony Signalling ' <draft-ietf-avt-rfc2833biscas-05.txt> as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833biscas-05.txt Technical Summary This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in RFC 2833 section 3.14. As documented in Appendix A of RFC 4733, certain of the RFC 2833 events have been deprecated, because their specification was ambiguous, erroneous or redundant. Document Quality The draft has existing implementation, it updates RFC2833. Personnel Roni Even is the document shepherd. Note to RFC Editor Change the following in the security section: OLD To prevent these attacks, the transmission of the telephony signalling events described in this memo MUST be given confidentiality protection. Message authentication and the protection of message integrity MUST also be provided. These address the threats posed by message insertion and modification. With these measures in place, RTP sequence numbers and the redundancy provided by the RFC 4733 procedures for transmission of events add protection against and some resiliency in the face of message deletion. The Secure Real-time Transport Protocol (SRTP) [3] meets the requirements for protection of confidentiality, message integrity, and message authentication described above. It SHOULD therefore be used to protect media streams containing the events described in this document. Note that the appropriate method of key distribution for SRTP may vary with the specific application. In some deployments it may be preferable to use other means to provide protection equivalent to that provided by SRTP. NEW These attacks can be prevented by use of appropriate confidentiality, authentication, or integrity protection. If confidentiality, authentication, or integrity protection are needed then Secure Real-time Transport Protocol (SRTP) [3] SHOULD be used with automated key management. Just before Table 4, please add the following new note. Note that a naive strategy for onward relay of R2 inter-register signals may result in unacceptably long call setup times and timeouts when the call passes through several exchanges as well as a gateway before terminating. Several strategies are available for speeding up the transfer of signalling information across a given relay point. In the worst case the relay point has to act as an exchange, terminating the signalling on one side and reoriginating the call on the other. After the first paragraph of 2.5, please add the following new note: Note that implementations often send a slightly different check-tone, e.g. 2010 Hz, because of undesirable aliasing properties of 2000 Hz. In section 1.2 OLD interworked to signalling NEW signalled _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
