A Session Initiation
Protocol (SIP) Media Feature
Tag for MIME Application Sub-TypesCiscoEdisonNJUSjdrosen@cisco.comhttp://www.jdrosen.net
Real Time Applications and Infrastructure (RAI)
SIPSIPIMSThe caller preferences specification for the Session Initiation
Protocol (SIP) allows a caller to express preferences that the call be
routed to a User Agent (UA) with particular capabilities. Similarly, a
specification exists to allow a UA to indicate its capabilities in a
registration. Amongst those capabilities are the type of media streams
the agent supports, described as top-level MIME types. The
'application' MIME type is used to describe a broad range of stream
types, and provides insufficient granularity as a capability. This
specification allows a UA to indicate which application sub-types the agent
supports.
The caller preferences specification for the
Session Initiation Protocol (SIP) allows a
user to express preferences for the routing of SIP requests. These
preferences are expressed as a set of desired capabilities and
characteristics of a receiving agent. When a user agent registers to
the SIP network, it includes, as part of its registration, its own
capabilities and characteristics . These
capabilities are stored as part of the registration, and then made
available to the proxy in the network. When a request arrives at the
proxy with caller preferences, the preferences in the request are
compared with the supported characteristics and capabilities stored in
the registrations, and the result is used to select the target user
agents for the request.
RFC 3840 makes use of media feature tags . Each tag has a name and a type. The tags defined
in RFC 3840 describe some of the basic characteristics of user agents,
including whether they are automata or
not (the sip.automata tag), their class (the sip.class tag), whether
they support media in one or both directions (the sip.duplex), and
whether they are a conference focus (sip.isfocus). These tags also
include SIP protocol capabilities, including the schemes supported by
the agent (sip.schemes), the methods (sip.methods), and the event
packages (sip.events).
RFC 3840 also defines media feature tags for multimedia stream
types. There is a media feature tag defined for each top-level media
type - sip.audio for audio streams, sip.video for video streams, and
so on. The primary use case for this is to correctly deliver
multimedia sessions to the user agent that supports that media
type. Consider a caller on a videophone that wants to have a video
call with another user. That user has two devices - a mobile phone
that only supports audio, and a videophone. We'd like to deliver the
videophone call to the videophone as a first priority, and only 'ring'
the mobile device for an audio-only call if the user is not present on
the videophone.
RFC 3840 defines media feature tags for each and every top-level media
type, including 'application'. This media type covers an extremely
broad range of subtypes - multiplayer games of all sorts, shared
whiteboards and application sharing, and so on. With audio and
video, where there is often a common codec supported by agents (i.e.,
a common subtype). Consequently, if a caller wants an audio session, routing
the request to any user agent that supports audio is likely to result in
successful communications. However, with application streams, just
routing a request to an agent that supports *some* application stream
isn't useful; application streams for different applications are
wildly different. Consequently, the application media feature tag does
not provide sufficient granularity for call preferences. The specific
application sub-type needs to be indicated as well.
To remedy this, this specification defines a new media feature tag
that indicates which application sub-types are supported by the agent
for streaming. The name of this media feature tag is
'sip.app-subtype'.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
The 'sip.app-subtype' media feature tag is of type token with a
case-sensitive equality relationship. Its value can be any registered
or private MIME application sub-type. When included in the Contact
header field of a REGISTER request, an agent SHOULD include all
application subtypes that it can support as streaming formats. An
application sub-type is supported if the user agent would be capable
of processing an Session Description Protocol (SDP) offer that contained
that sub-type as a format in the m-line of the SDP.
When included in the Accept-Contact or Reject-Contact header field, it
indicates a desire on the part of a UAC to be connected to a UAS which
can support, or cannot support respectively, streaming using that
application sub-type.
It is important to note that this media feature tag is only indicating
the streaming media types that a user agent is capable of
supporting. It says nothing about the functionality provided by the
user agent itself, or the MIME types that the agent can send or
receive in SIP messages or emails. For example, let us assume that a
SIP user agent is capable of supporting a chess game. The game is
played by each user sending chess moves as binary objects over UDP
between a pair of user agents. Those objects have a MIME type of
"application/example". When a UA includes the sip.app-subtype
media feature tag in a Contact header field with a value of
"example", it means that the UA can handle a SIP INVITE that
contained an SDP with an application media line and format of
"example". It does not mean that the SIP user agent is a chess
application, or that the user agent can accept SIP requests that
include bodies of type "application/example". To indicate that a
user agent can accept SIP requests that include bodies of type
"application/example", the agent would utilize the "type" media
feature tag as defined in .
A consequence of this is that, as new streaming media type formats are
defined (such as game stream formats, whiteboard session formats, and
so on, they SHOULD be defined using the SDP application stream, and
utilize a MIME application sub-type.
The following is an example SIP REGISTER message fragment indicating
usage of this media feature tag. The REGISTER indicates that the UA
can particiate in application media sessions utilizing exchange of
objects of type "application/example".
Such a registration indicates that an INVITE of the following form:
would be accepted by the UA. The SDP in the INVITE indicates an audio
session and an application session which runs over UDP and exchanges
"application/example" object formats.
When present in a REGISTER request, this media feature tag gives
information on the set of supported application media streams. It is
possible that this information is sensitive, providing insight into
the capabilities of a product. These considerations are already
discussed in RFC 3840, and those considerations apply here as well.
Applications which utilize this media feature tag SHOULD provide a
means for ensuring its integrity. Similarly, the media feature tag
should only be trusted as valid when it comes from the user or user
agent described by the feature tag. As a result, mechanisms for
conveying the feature tag SHOULD provide a mechanism for guaranteeing
authenticity.
This specification adds a new media feature tag to the SIP Media
Feature Tag Registration Tree defined in RFC 3840 .
sip.app-subtype 1.3.6.1.8.4.22 This
feature tag indicates the MIME application sub-types supported by the
agent for purposes of streaming media.
Token. This
feature tag is most useful in a communications application, for
describing the capabilities of a device, such as a phone or PDA. Routing a call to a phone that can
support a multiplayer game. RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]] Security considerations for this
media feature tag are discussed in of
RFC XXXX . [[Note to IANA: Please replace XXXX with the RFC number of
this specification.]]