ne multiple frequency (DTMF) digits. A low bit rate codec that is optimized for transmitting vocal sounds will not transport the superimposed sine waves of a DTMF signal without introducing significant noise, which may cause the DTMF digit receiver to fail to detect the digit. As a result, it is useful to switch to another codec when the sender detects a DTMF tone. Because a RTP packet contains the payload type, it is possible to change codecs "on the fly" without any signaling information being exchanged between the user agents. On the other hand, switching codecs in general should probably not be done without a SIP signaling exchange (re-INVITE) beacuse the call could fail if one side switches to a codec that the other does not support. The SIP re-INVITE mes- sage exchange allows this change in media session parameters to fail without causing the established session to fail. The use of random numbers for CSRC provides a minimal amount of security against "media spamming" where a literally uninvited third party tries to break into a media session by sending RTP packets during an established call. Unless the third party can guess the CSRC of the intended sender, the receiver will detect a change in CSRC number and either ignore the packets or inform the user that something is going on. This behavior for RTP clients, however, is not universally accepted, because in some scenarios (wireless hand-off, announcement server, call center, and SO forth.) it might be desirable to send media from multiple sources during the progress of a call. RTP supports encryption of the media. In addition, RTP can use IPSec [9] for authentication and encryption. 7.3 RTP Audio Video Profiles The use of profiles enables RTP to be an extremely general media transport protocol. The current audio video profiles defined by RFC 3551 are listed in Table 7.4. The profile document makes the following specifications for RTP: UDP is used for underlying transport; RTP port numbers are always even, the corresponding RTCP port number is the next high