The SIP INFO Method
obsoleted by
- rfc-6086 — Session Initiation Protocol (SIP) INFO Method and Package Framework
Extracted elements (17)
INFO message bodies should be kept small because the message may be carried over UDP and larger messages risk fragmentation. Extensions using INFO should account for the potential that INFO messages could be forked by a SIP Proxy Server.
INFO was introduced because SIP lacked a general-purpose mechanism to carry session control information along the SIP signaling path during an active session. Re-INVITE can modify session characteristics but cannot carry arbitrary mid-session application-layer signaling.
The INFO extension does not depend on the Require or Proxy-Require headers. Extensions using INFO should avoid these mechanisms where possible to improve interoperability between SIP entities.
CSeq is incremented upon transmission of each INFO message, but CSeq SHOULD NOT be used to determine the sequence of INFO information because gaps can occur when a UA sends re-INVITEs or other SIP messages between INFO messages.
Protocol rules for INFO at proxy servers (including forking proxy and redirection servers) are identical to those for the BYE request as specified in RFC 2543.
A UAS MUST send a 200 OK for an INFO request with no message body if the INFO was successfully received for an existing call.
A UAS MUST send a 481 Call Leg/Transaction Does Not Exist response if the INFO request does not match any existing call leg.
A UAS receiving an INFO request MUST send a final response.
Extensions that use the INFO message MUST NOT rely on INFO to do anything that affects the SIP call state or the state of related sessions.
If a server receives an INFO request with a body it understands but has no knowledge of INFO-associated processing rules for the body, the body MAY be rendered and displayed to the user, and the INFO is responded to with a 200 OK.
If the INFO request contains a body the server does not understand and there are no INFO-associated processing rules for that body, the server MUST respond with 415 Unsupported Media Type.
Message bodies that imply a change in the SIP call state or the sessions initiated by SIP MUST NOT be sent in an INFO message.
The INFO message MUST NOT change the state of the SIP call, or the sessions initiated by SIP.
The INFO method is used for communicating mid-session signaling information along the signaling path for the call. It does not change the state of SIP calls or sessions initiated by SIP; it provides additional optional application-layer information.
The INFO request MAY be cancelled. A UAS receiving a CANCEL for an INFO request SHOULD respond with '487 Request Cancelled' if a final response has not yet been sent, then behave as if the request were never received.
The signaling path for INFO is the path established during call setup: either direct UA-to-UA signaling or via proxy servers that added themselves to the Record-Route header in the initial INVITE.
If the contents of the INFO message body are private, end-to-end encryption of the message body can be used to prevent unauthorized access. No other security issues are specific to the INFO method; the security requirements of the base SIP specification apply.