hat a UA supports should be listed in an Allow header field. SIP extensions should be listed in a Supported header field. Message body types that are supported should be listed in an Accept header field. 3.2 Presence Agents A presence agent (PA) [2] is a SIP device that is capable of receiving subscription requests and generating state notifications as defined by the SIP Events specifi- cation [3]. An example of a presence agent is in the example of Section 2.4. A presence agent supports the presence Event package [2], responds to SUBSCRIBE requests, and sends NOTIFY requests. A presence agent can collect presence information from a number of devices. Presence information can come from a SIP device registering, a SIP device publishing presence information [4], or from many other non-SIP sources. SIP Clients and Servers A presence server is a server that sometimes acts as a presence agent and supplies presence information and other times acts as a proxy, forwarding SUBSCRIBE requests to another presence agent. A presence agent first authenticates a subscription request. If the authenti- cation passes, it establishes a dialog and sends the notifications over that dialog. The subscription can be refreshed by receiving new SUBSCRIBE requests. 3.3 Back-to-Back User Agents A back-to-back user agent (B2BUA) is a type of SIP device that receives a SIP request, then reformulates the request and sends it out as a new request. Responses to the request are also reformulated and sent back in the opposite direction. For example, a B2BUA device can be used to implement an anonymizer service in which two SIP UAs can communicate without either party learning the other par- ty's URI, IP address, or any other information. To achieve this, an anonymizer B2BUA would reformulate a request with an entirely new From, Via, Con- tact, Call - ID, and SDP media information, also removing any other SIP header fields that might contain information about the calling party. The response returned would also change the Contact and SDP media infor