Finally an RFC for the SIP INFO message
SIP, like HTTP, is a request-response protocol. Each request has a method, that is standardized. A call setup uses the INVITE method, a call tear-down (hangup) use the BYE method. Those are simple to understand, as are a few of the other ones, like REFER for call transfers and MESSAGE for SMS-like text messages. The SIP INFO method has been an unspecified area used for left-overs from the SIP meal. A number of usages has been established. The new RFC – “Session Initiation Protocol (SIP) INFO Method and Package Framework” (RFC 6086) tries to clear up the kitchen and organize the dishes to continue the metafor.
“The purpose of the INFO message is to carry application level
information between endpoints, using the SIP dialog signaling path.
Note that the INFO method is not used to update characteristics of a
SIP dialog or session, but to allow the applications that use the SIP
session to exchange information (which might update the state of
those applications).”
INFO – now an extensible framework
The RFC declares and extensible framework, where interested parties can register frameworks for the INFO message with the IANA, much like SIP extensions. New headers are defined for an UA to declare which of these extensions it support and for a sender to indicate in an INFO request which particular framework that is used in this request. The RFC clarifies that INFO is used to exchange information between UAs and only forwarded by proxys.
The RFC declare all the old INFO usages as “legacy” and indicates that the lack of these headers and framework definitions has created interoperability issues. In short, it has been an ugly mess. The new RFC obsoletes the old INFO RFC. It doesn’t declare all the old usage models for INFO as deprecated, but clearly states that new implementations should avoid using them.
New SIP headers and error codes
The Info-Package header indicates which package that is used by an INFO message.
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314333 INFO Info-Package: foo Content-type: application/foo Content-Disposition: Info-Package Content-length: 24 I am a foo message type
The Recv-Info: header indicates which type of INFO packages that a UA supports.
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 INVITE Recv-Info: P, R Contact: <sip:alice@pc33.example.com> Content-Type: application/sdp Content-Length: ... ...
There’s also a new SIP response code,
469 Bad Info Package
This code indicates that a received INFO message can not be parsed, since the UA does not have any implementation of this INFO package.
Overview for SIP application designers
The RFC also has a section that discusses alternatives to using INFO for exchange of data between user agents. It’s an interesting chapter well worth reading that goes through the different options, including HTTP, MSRP, SIP Message and SUBSCRIBE/NOTIFY packages.
This work has taken a few years. It was an important area of SIP to clean up and make more structured. Structure and logic is needed for programmers that implement the protocols. In short, an important step forward for the SIP protocol.