different interoperable implementations. Authors have received a large amount of review feedback from the com- munity and the implementors' experiences are being recorded. All fixes and Chapter 4 additions to the protocol are gathered in an Internet draft [draft-ietf-sip- rfc2543bis] destined to become the draft standard RFC when SIP is truly stable. It is worth noting that although SIP is still a proposed standard, it is sta- ble enough to be implemented in products. Developers hold periodic inter- operability tests to ensure interoperability, originally known as bake-offs but now somewhat stodgily renamed SIP interoperability events at the behest of the baking industry (see http://www.cs.columbia.edu/ sip/sipit /pillsbury.html for the story). The first bake-off took place in April 1999 at Columbia University and now usually three SIP bake-offs take place in a year. SIP bake-offs have proved useful for finding bugs in the specification and elaborating solutions for them. Functionality Provided by SIP RFC 2543 describes the core of SIP: that is, the basic operation of the pro- tocol. Besides this basic spec, a number of extensions to SIP have been defined in other RFCs and Internet drafts (Figure 4-3). Once again, this chapter will limit the discussion to the functionality provided by the basic specification. Session Establishment, Modification, and Termination SIP establishes, modifies, and terminates multimedia sessions. It can be used to invite new members to an existing session or to create brand new sessions. When SIP notifies my friend Bob that something he would find interesting is being multicast on the Internet, I'm invoking an existing ses- sion. However, if Bob calls up Laura to spread the news, this two-party call constitutes a new multimedia session with a single audio component. In this case, Bob is inviting Laura to join a session that has yet to be created. Additionally, it will only be created if two conditions are met: (1) Laura willing to speak to Bob and (2) they can agree on the media paramet