e is the level of security in the protocol. SIP as defined in RFC 3261 has very robust security mechanisms to provide encryp- tion, authentication using certificates, and end-to-end message integrity even in the presence of untrusted intermediary servers. SIP did not need to develop these security features; instead, since it is an Internet protocol, it was able to inherit the rich set of Internet security protocols such as TLS and S/MIME in very straightforward way. For example, the same security mechanisms that make it safe to enter credit card information on a secure Web page form is what allows SIP to provide secure signaling between servers. While it is not directly related to SIP, the media capability/negotiation capabilities of SDP are quite different to that provided by H.245 for H.323. H.245 is often criticized for its complexity, but SDP is often correctly criticized for its lack of expressiveness. The multicast legacy of SDP has not provided SIP with a good basis for media negotiation. As a result, some codec/media negotia- tion capabilities interwork poorly between implementations due to these prob- lems. Much industry work has gone into fixing the problem, but a replacement for SDP is not yet within sight yet. Over the years that they have coexisted, SIP and H.323 have actually become more similar in some functionality. This is natural in that each protocol seems to have adopted some of the useful features of each. For example, SIP: Understanding the Session Initiation Protocol while SIP had DNS and URL support right from the start, H.323 began with none but has added some support for them. Another similarity relates to confer- encing. While H.323 had the concept of an MCU right from the start, SIP ini- tially had no defined conferencing mechanisms. However, work is currently underway to define the SIP signaling equivalent, called a "focus" as described in Section 11.1.2. Additional work is underway in the IETF to standardize the media mixing functions of an MCU. In other ways, the protocols started o