The SIP INFO Method (RFC 6086): Application-Specific Mid-Call Signaling Workflows

Overview

Key takeaways

• RFC 6086 updates RFC 2976 by introducing well-defined Info Packages to eliminate payload ambiguity in mid-dialog SIP INFO messages.
• SIP INFO is designed strictly for session-related control information and must not be used to modify stream definitions or SDP parameters.
• Endpoints negotiate supported Info Packages during dialog establishment using the Recv-Info header field in INVITE and 200 OK exchanges.
• Unrecognized or unnegotiated Info Packages must be rejected by receiving User Agents with a 469 Bad Info Package response code.
• Common legacy and modern applications include DTMF tones, video keyframe requests (RFC 5168), and custom carrier-specific mid-call control features.

Prerequisites

• Basic understanding of SIP dialog lifecycle (INVITE, 200 OK, ACK, BYE)
• Familiarity with MIME content types and SIP header manipulation
• Conceptual knowledge of mid-call session signaling versus media path (RTP) operations

Guide

1. section #1

   Evolution from RFC 2976 to RFC 6086 Info Packages The original SIP INFO method defined in RFC 2976 provided a generic mechanism for sending mid-dialog information without updating the Session Description Protocol (SDP) state. However, RFC 2976 lacked a standardized framework for negotiating which payloads a User Agent (UA) was willing to accept, leading to interoperability issues where endpoints received unexpected content types or ambiguous application payloads. RFC 6086 resolved this by establishing the Info Package framework. Under RFC 6086, every INFO message must explicitly reference a registered or custom Info Package name in its headers, ensuring UAs can deterministically negotiate, validate, and parse mid-call application data.

2. section #2

   Negotiating Support with the Recv-Info Header To prevent UAs from receiving unsupported mid-call messages, RFC 6086 mandates explicit capability advertisement using the Recv-Info header during dialog establishment. A UAC includes Recv-Info in the initial INVITE listing the Info Packages it can receive. The UAS responds with its own Recv-Info header in the 200 OK. If a proxy or endpoint supports no Info Packages, it transmits the header with a value of 'nil'. Once the dialog is established, endpoints may only send INFO requests corresponding to packages successfully declared by the remote peer.

   httpcopy

   INVITE sip:alice@example.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK776asdhds
   From: <sip:bob@example.com>;tag=1928301774
   To: <sip:alice@example.com>
   Call-ID: a84242c26568189@192.168.1.10
   CSeq: 314159 INVITE
   Recv-Info: foo, bar, g3fax
   Content-Type: application/sdp
   Content-Length: 142

3. section #3

   Structure of a Mid-Call SIP INFO Request A SIP INFO request sent within an active dialog contains the Info-Package header field specifying the negotiated package context. The message body carries the context-specific payload, matched to the appropriate Content-Type header. Unlike re-INVITE or UPDATE requests, an INFO request never triggers an SDP offer/answer exchange and must not alter media streams or network paths.

   httpcopy

   INFO sip:alice@192.168.1.20:5060 SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK892341
   From: <sip:bob@example.com>;tag=1928301774
   To: <sip:alice@example.com>;tag=a6c85570
   Call-ID: a84242c26568189@192.168.1.10
   CSeq: 314160 INFO
   Info-Package: foo
   Content-Type: application/foo-data
   Content-Length: 24
   
   command=action&target=1

4. section #4

   Application Scenarios: DTMF, Media Control, and Custom Signaling SIP INFO is widely deployed for mid-call application event transport. Common applications include legacy DTMF relay via 'application/dtmf-relay' or 'application/dtmf', picture fast update commands for video streams (RFC 5168 using 'media-control' XML payloads), ISUP tunneling, and proprietary PBX feature key synchronization (e.g., call record toggling or mute status synchronization). While out-of-band DTMF is often handled via RFC 4733 RTP telemetry, SIP INFO remains a primary fallback in environments where in-band RTP payload processing is bypassed or undesirable.

   httpcopy

   INFO sip:1001@10.0.0.1:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK33101
   From: <sip:1002@10.0.0.2>;tag=tag1
   To: <sip:1001@10.0.0.1>;tag=tag2
   Call-ID: c301293810293
   CSeq: 101 INFO
   Info-Package: dtmf
   Content-Type: application/dtmf-relay
   Content-Length: 26
   
   Signal=5
   Duration=160

5. section #5

   Error Handling and Response Codes RFC 6086 introduces specific SIP response codes to handle mid-call signaling failures gracefully. If a UA receives an INFO request containing an Info-Package header that was not previously negotiated via Recv-Info, or if the package is unsupported, it must reject the request with a 469 Bad Info Package response. If the Info-Package is recognized but the specific MIME body type or syntax is invalid, standard HTTP/SIP error codes such as 415 Unsupported Media Type or 400 Bad Request must be returned.

   httpcopy

   SIP/2.0 469 Bad Info Package
   Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK892341;received=192.168.1.10
   From: <sip:bob@example.com>;tag=1928301774
   To: <sip:alice@example.com>;tag=a6c85570
   Call-ID: a84242c26568189@192.168.1.10
   CSeq: 314160 INFO
   Recv-Info: bar, g3fax
   Content-Length: 0

6. section #6

   Best Practices and Architectural Constraints When implementing RFC 6086, engineers must adhere to key architectural boundaries. First, INFO must never be used to statefully control dialog state, transfer calls, or re-negotiate media sessions—standard SIP mechanisms like REFER, re-INVITE, or UPDATE must be used instead. Second, UAs should apply strict rate-limiting on incoming INFO requests to prevent CPU starvation attacks or mid-call flood conditions. Finally, Session Border Controllers (SBCs) must be configured to inspect and filter Recv-Info headers to avoid leaking internal proprietary Info Package capability names to untrusted external networks.

Further reading

• RFC 6086 - Session Initiation Protocol (SIP) INFO Method and Package Framework
• RFC 2976 - The SIP INFO Method (Obsoleted by RFC 6086)
• RFC 5168 - XML Schema for Media Control (Picture Fast Update)
• IANA Session Initiation Protocol (SIP) Info-Packages Registry