Session Initiation Protocol (SIP) INFO Method and Package Framework
obsoletes
- rfc-2976 — The SIP INFO Method
Extracted elements (30)
RFC 2976 legacy INFO usages lacked a registration mechanism, making it impossible for a UA to indicate which types of application-level contexts it supports for the INFO method. This caused industry-wide interoperability problems requiring static configuration and proprietary workarounds. The working group resolved this by defining the Info Package framework and IANA registry rather than deprecating INFO entirely.
RFC 6086 does not define a SIP option-tag for the Info Package mechanism as a whole. This avoids requiring a Require/Supported header field exchange for the base mechanism; instead, presence of the Recv-Info header field serves as the capability indicator. Individual Info Package specifications may define their own option-tags.
The Info Package mechanism does not support package versioning at the framework level. If versioning is needed, specific Info Package message body payloads must carry version information handled at the application level. This keeps the framework simple while allowing flexibility in individual packages.
Due to the possibility of forking, the UA sending the initial INVITE MUST be prepared to receive INFO requests from multiple remote UAs during the early dialog phase, and MUST be prepared to receive different Recv-Info header field values from different remote UAs.
For backward compatibility, RFC 6086 does not deprecate legacy INFO usages defined in RFC 2976. A UA indicating support of the INFO method using the Allow header field does not implicitly indicate support of the Info Package mechanism; a UA MUST use the Recv-Info header field to signal Info Package mechanism support.
A UA MUST NOT include a message body associated with an Info Package in an INFO response; Info Package message bodies MUST only be sent in INFO requests. A UA MAY include a message body not associated with an Info Package in an INFO response.
A UA MUST NOT include a Recv-Info header field in a response if the associated request did not contain a Recv-Info header field.
A UA MUST NOT include an Info-Package header field in a legacy INFO request (one not associated with any registered Info Package). The INFO request MUST NOT contain a Recv-Info header field.
A UA MUST NOT send an INFO request outside an invite dialog usage, and MUST NOT send an INFO request for an Info Package inside an invite dialog usage if the remote UA has not indicated willingness to receive that Info Package within that dialog.
A UA that supports the Info Package mechanism MUST indicate, using the Recv-Info header field, the set of Info Packages for which it is willing to receive INFO requests. If not willing to receive INFO for any Info Package, the UA MUST include an empty Recv-Info header field to signal continued support of the mechanism.
Any new INFO usage MUST use the Info Package mechanism defined in RFC 6086. UAs SHALL NOT mix legacy INFO usages and Info Package usages to transport the same application-level information; if possible, UAs SHALL prefer an Info Package.
For a specific dialog usage, a UA MUST NOT send an INFO request associated with an Info Package until it has received an indication that the remote UA is willing to receive that Info Package, or after receiving indication that the remote UA is no longer willing.
If a UA receives a 469 (Bad Info Package) response to an INFO request, the response represents a Transaction Only failure per RFC 5057, and the UA MUST NOT terminate the invite dialog usage.
If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad Info Package) response containing a Recv-Info header field listing the Info Packages for which the UA is currently willing to receive requests. The UA MUST NOT use the response to update that set.
If an INFO request associated with an Info Package contains a message body part, that body part MUST be identified by a Content-Disposition header field value of 'Info-Package'. UAs MUST support multipart body parts in accordance with RFC 5621.
If the INFO request is syntactically correct and well-structured, the UA MUST send a 200 (OK) response. Application-level rejection of received information must be done at the application level by sending a new INFO request.
If the receiver of a request containing a Recv-Info header field rejects the request, both sender and receiver MUST roll back to the set of Info Packages that was used before the request was sent. This applies even when the receiver has included a Recv-Info in a provisional response but later rejects the request.
Info Package specifications MUST NOT weaken any behavior designated with SHOULD or MUST in RFC 6086. However, Info Package specifications MAY strengthen SHOULD, MAY, or RECOMMENDED requirements to MUST if applications require it.
The sender of an initial INVITE request MUST include a Recv-Info header field in the initial INVITE, even if not willing to receive INFO requests for any Info Package. The receiver of a request containing Recv-Info MUST include a Recv-Info header field in a reliable 18x/2xx response, using the same value in all responses for the same transaction.
When a UA sends an INFO request associated with an Info Package, it MUST include an Info-Package header field identifying the Info Package. A specific INFO request can be used only for a single Info Package.
Response code 469 (Bad Info Package) is returned when a UA receives an INFO request for an Info Package it has not indicated willingness to receive. The response MUST contain a Recv-Info header field with the current set of accepted Info Packages and represents a Transaction Only failure that does not terminate the dialog.
The INFO method carries application-level information between SIP UAs within an existing invite dialog usage. INFO does not update dialog or session characteristics; it allows applications using the SIP session to exchange information. An INFO request is always part of, and shares the fate of, the invite dialog usage and cannot be sent outside it.
The Info-Package header field is included in INFO requests to identify the associated Info Package. It contains exactly one Info-package-type value (Info-package-name plus optional parameters). The Info Package name is case-sensitive; Info-package-param is not part of the matching algorithm.
The Recv-Info header field is used by a UA to indicate, on a per-dialog basis, the set of Info Packages for which it is willing to receive INFO requests. It can appear in INVITE, UPDATE, REGISTER requests and their 1xx/2xx responses, and in 469 responses to INFO requests. An empty Recv-Info signals support of the mechanism but unwillingness to receive any Info Package.
IANA created the 'Info Packages' registry under 'Session Initiation Protocol (SIP) Parameters'. Registration policy is Specification Required. Each entry contains an Info Package Name (case-sensitive token, no duplicate case-insensitive values permitted) and a Reference. The initial table is empty.
IANA registered the Content-Disposition value 'info-package' in the 'Mail Content Disposition Values and Parameters' registry, with the description 'The body contains information associated with an Info Package', and registered SIP response code 469 with default reason phrase 'Bad Info Package'.
IANA registered two new SIP header fields: 'Info-Package' (no compact form, reference RFC 6086) and 'Recv-Info' (no compact form, reference RFC 6086) in the 'Header Fields' registry under 'Session Initiation Protocol (SIP) Parameters'. The existing INFO method registration was updated from RFC 2976 to RFC 6086.
If the content of an Info Package payload is private, UAs must use end-to-end encryption such as S/MIME, because INFO requests traverse SIP proxies and B2BUAs that the user may not trust. TLS provides only hop-by-hop protection; any SIP hop along the path can view, modify, or intercept INFO requests.
INFO requests may require a higher level of protection than the underlying SIP dialog signaling because they carry application-level data. Individual Info Package specifications must enumerate their own security requirements. The Info Package framework itself provides the tools for negotiating and enforcing package-specific security.
The ABNF for Info-Package is: Info-Package = 'Info-Package' HCOLON Info-package-type, where Info-package-type = Info-package-name *( SEMI Info-package-param ), Info-package-name = token, Info-package-param = generic-param. Recv-Info = 'Recv-Info' HCOLON [Info-package-list], where Info-package-list = Info-package-type *( COMMA Info-package-type ).