请求包括新的扩展协议的请求除非特殊说明,否则都可能包含消息体。消息体的含义依赖于消息的方法。应答消息的状态码和该应答消息对应的请求消息的方法决定该应答消息的消息体的含义。所有的应答消息都可能包含一个消息体。
消息体的互联网媒体类型必须在Content-Type头域中给出。如果消息体经过编码(比如压缩)那么必须在Content-Encoding头域中指明。否则,Content-Encoding头域必须不出现。如果可能,消息体的字符集可以用Content-Type头域值的一部分指明。
“multipart”MIME类型在RFC2046中定义。它可以被用作消息体。
SIP消息体可能包含二进制信息。如果发送端没有指出字符集参数,则默认为"text"类型的UTF-8字符集。
Content-Length头域指出消息体的字节数。RFC3261第20.14节详细描述了这个头域必须的内容。HTTP/1.1的"chunked"不能在SIP中使用。
不像HTTP,SIP可以使用如UDP这样的不可靠的报文传输协议。每个数据报传输一个请求或应答。RFC3261第18节描述了不可靠报文传输协议的使用。
使用流传输方式处理SIP消息时,必须忽略出现在开始行前面的任何CRLF。
Content-Length头域的值可以在流中定位每个SIP消息的结束位置。在流传输方式下,这个头域一定出现在每个SIP消息中。