Protocol Action: 'Definition of Events For Channel-Oriented Telephony Signalling' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce