eans that the message body should be presented to the user or otherwise used or displayed. This could be used to pass a small JPEG image file or URI. The format of the message body is indicated by the Content-Type header described in Section 6.4.5. If a message contains a message body, the message must include a Content-Type header. All user agents must support a Content-Type of application/sdp. The encoding scheme of the message body is indicated in the Content-Encoding header. If not SIP Request Messages specified, the encoding is assumed to be text/plain. The specification of a Content-Encoding scheme allows the message body to be compressed. The Content-Length header contains the number of octets in the message body. If there is no message body, the Content-Length header should still be included but has a value of 0. Because multiple SIP messages can be sent in a TCP stream, the Content-Length count is a reliable way to detect when one message ends and another begins. If a Content-Length is not present, the UAC must assume that the message body continues until the end of the UDP datagram, or until the TCP connection is closed, depending on the transport protocol. Message bodies can have multiple parts if they are encoded using Multi- part Internet Mail Extensions (MIME) [22]. Message bodies in SIP, however, should be small enough SO that they do not exceed the UDP MTU of the net- work. Proxies may reject requests with large message bodies with a 413 Request Entity Too Large response, since processing large messages can load a server. As mentioned in the previous section, SIP carries message bodies the same way that e-mails carry attachments. It is possible to carry multiple message bod- ies within a single SIP message. This is done using a multipart MIME body. The Content-Type is listed as multipart/mime, and a separator is defined, which is used by the parser to separate the message. Any SIP request or response that can contain a message body may carry a multipart MIME body. An exam- ple is in SIP-T (see Sec