 a signaling path involving SIP proxy servers that were involved in the call setup and added themselves to the Record-Route header on the initial INVITE message. The mid-session information can be communicated in either an INFO message header or as part of a message body. The definition of the message body and/or message headers used to carry the mid-session information is outside the scope of this document. There are no specific semantics associated with INFO. The semantics are derived from the body or new headers defined for usage in INFO. 2.1 Header Field Support for INFO Method Tables 1 and 2 add a column to tables 4 and 5 in the [1]. Refer to Section 6 of [1] for a description of the content of the tables. Note that the rules defined in the enc. and e-e columns in tables 4 and 5 in [1] also apply to use of the headers in the INFO request and responses to the INFO request. Donovan Standards Track [Page 3] RFC 2976 SIP INFO Method October 2000 2.2 Responses to the INFO Request Method If a server receives an INFO request it MUST send a final response. A 200 OK response MUST be sent by a UAS for an INFO request with no message body if the INFO request was successfully received for an existing call. Beyond that, no additional operations are required. Header Where Accept Accept-Encoding Accept-Language Allow Allow Authorization Call-ID Contact Contact Contact Contact Contact Content-Encoding Content-Length Content-Type Encryption Expires Max-Forwards Organization Table 1 Summary of header fields, A-0 Handling of INFO messages that contain message bodies is outside the scope of this document. The documents defining the message bodies will also need to define the SIP protocol rules associated with those message bodies. A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a UAS if the INFO request does not match any existing call leg. Donovan Standards Track [Page 4] RFC 2976 SIP INFO Method October 2000 If a server receives an INFO request with a body it understands, but it has no knowledge of INFO asso