Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)Cisco Systems, Inc.1899 Wynkoop Street, Suite 600DenverCO80202USA+1-303-308-3282psaintan@cisco.comSIPCall-Infoheader fieldInstant MessagingPresenceThis document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).Some real-time communication endpoints support the combined use of the
Session Initiation Protocol (SIP) [RFC3261] and the Extensible Messaging and
Presence Protocol (XMPP) [RFC6120]. To improve interoperability among such
"CUSAX" endpoints [CUSAX], it can be helpful to advertise each endpoint's SIP
address over XMPP and each endpoint's XMPP address over SIP, thus providing
hints about the communication capabilities of the endpoints.
The former feature is enabled by an XMPP
extension protocol called Reachability Addresses . As
to the latter feature, discussion in the SIP community led to the conclusion
that it would be best to use the Call-Info header field with a value of "impp" ("instant messaging and presence
protocol") for the "purpose" header field parameter. An example follows.
Although CUSAX endpoints constitute the primary use case for the "impp" purpose, a Uniform Resource Identifier (URI) for an instant messaging and presence protocol other than XMPP could be included in the Call-Info header field.Advertising an endpoint's XMPP address over SIP could inform malicious
entities about an alternative attack vector. Because the "purpose" header
field parameter could be spoofed, the receiving endpoint ought to check the
value against an authoritative source such as a user directory. Clients can
integrity protect and encrypt this header field using end-to-end mechanisms
such as S/MIME or hop-by-hop mechanisms such as Transport Layer Security (TLS).This specification provides a new way to correlate otherwise possibly unconnected identifiers. Because such correlations can be privacy sensitive, user agents ought to provide a means for users to control whether or not these values are sent.This document defines and registers a new predefined value "impp" for
the "purpose" header field parameter of the Call-Info header field. The IANA
has completed this action by adding this RFC as a reference to the line for the
header field "Call-Info" and parameter name "purpose" in the "Header Field
Parameters and Parameter Values" section of the "Session Initiation Protocol
(SIP) Parameters" registry as follows:CUSAX: Combined Use of
the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence
Protocol (XMPP)This
document describes suggested practices for combined use of the Session
Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol
(XMPP). Such practices aim to provide a single fully featured real-time
communication service by using complementary subsets of features from each of
the protocols. Typically such subsets would include telephony capabilities
from SIP and instant messaging and presence capabilities from XMPP. This
specification does not define any new protocols or syntax for either SIP or
XMPP. However, implementing the practices outlined in this document may require
modifying or at least reconfiguring existing client and server-side software.
Also, it is not the purpose of this document to make recommendations as to
whether or not such combined use should be preferred to the mechanisms provided
natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It
merely aims to provide guidance to those who are interested in such a combined
use.Reachability Addressesstpeter@jabber.orgjhildebr@cisco.comThanks to Gonzalo Camarillo, Keith Drage, Saul Ibarra, Emil Ivov, Cullen Jennings, Olle Johanssen, Paul Kyzivat, Gonzalo Salgueiro, Dean Willis, and Dale Worley for their input. Elwyn Davies, Salvatore Loreto, Glen Zorn, and Mehmet Ersue completed reviews on behalf of the General Area Review Team, Applications Area Directorate, Security Directorate, and Operations and Management Directorate, respectively. Stephen Farrell and Pete Resnick provided substantive feedback during IESG review. Thanks to Yana Stamcheva for her helpful comments and for shepherding the document.