 session where signalling and media is exchanged directly between them and no one else. However, two-party sessions are not what SIP does best. In fact, we saw that SIP and SDP were originally designed for conferences on the MBONE where members of a multicast group receive media on a multicast address. Multiparty conferences form the basis of many services. Probably the easiest example is a videoconference with three or more members. In this case, exchanging media between persons at the conference is synonymous with being conferenced. Nothing mandates that conference members must all be humans, though. Conferencing is used in many situations where only two humans are involved. For instance, Bob and Laura can have a business meeting over their SIP phones and record their conversation SO Laura's assistant can later prepare the meeting minutes. In this scenario, Bob and Laura are in Building Applications with the SIP Toolkit fact on a multiparty conference because the recording machine is a third member of the session. Conferencing mechanisms [draft-rosenberg-sip-conferencing-models] are most powerful when seen as service enablers rather than just a means for a large group of people to communicate. The introduction of non-human conference members can provide many different services, including back- ground music and image manipulation. In the following section, we will describe several conferencing models supported by SIP and how they are implemented. Multicast Conferences The first thing to notice is that although members of a multicast group receive media on a multicast address, SIP signalling is point to point between session participants. For instance, Bob can send an INVITE to Laura with the description of a multicast session. Bob and Laura use traditional unicast to send and receive SIP messages, but use multicast to send and receive media. Therefore, a point-to-point protocol like SIP can be used to signal multicast conferences. Multicast conferences are usually prearranged events and thus, SIP is not used to 