RFC 5688

A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes 🎀

okay so this one is RFC 5688 💖 It's a Standards Track doc from the Internet Engineering Task Force (IETF), written by J. Rosenberg from Skype, and it's dated January 2010. The ISSN is 2070-1721. The title block doesn't say what it obsoletes or updates, so there's nothing to report on that front 🫶

---

Abstract ✨

okay bestie, the caller preferences spec for SIP lets a caller say "route my call to a User Agent (UA) that has these particular capabilities" 📞 There's also a spec that lets a UA list its capabilities when it registers. One of those capabilities is the types of media streams the agent supports, which are described as top-level MIME types. The problem is that application covers a massive range of stream types, so it's way too vague to be useful as a capability 😭 This spec lets a UA say exactly which application subtypes it supports. slay 💅

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741.

For info about the current status of this document, any errata, and how to give feedback on it, go to http://www.rfc-editor.org/info/rfc5688.

Copyright Notice 💜

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get a proper license from whoever controls the copyright in that material, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exception is formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents 🦋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.  sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . . 3
4.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

---

1. Introduction 🧚

okay so the caller preferences spec [RFC3841] for SIP [RFC3261] lets a user say how they want their SIP requests routed 💅 Those preferences are written as a set of desired capabilities and characteristics of the receiving agent. When a user agent registers with the SIP network, it includes its own capabilities and characteristics as part of that registration [RFC3840]. Those capabilities get stored with the registration and then made available to the proxy in the network. When a request shows up at the proxy with caller preferences, the preferences get compared against the capabilities and characteristics stored in the registrations, and the result picks the target user agents for the request. it's giving matchmaking 🫶

RFC 3840 uses media feature tags [RFC2506]. Each tag has a name and a type. The tags RFC 3840 defines describe basic characteristics of user agents, like whether they're automata (the sip.automata tag), their class (the sip.class tag), whether they support media in one or both directions (sip.duplex), and whether they're a conference focus (sip.isfocus). These tags also cover SIP capabilities, like the schemes the agent supports (sip.schemes), the methods (sip.methods), and the event packages (sip.events) [RFC3265] 📞

RFC 3840 also defines media feature tags for multimedia stream types. There's one for each top-level media type: sip.audio for audio streams, sip.video for video streams, and so on. The main use case is delivering multimedia sessions to the user agent that supports that media type, and that's where it gets iconic ✨ Picture this: a caller on a videophone wants a video call with another user. That user has two devices, a mobile phone that only supports audio and a videophone. We want the call to ring the videophone first, and only ring the mobile for an audio-only call if the user isn't present on the videophone 📱🎥

Here's the tea 🍵 RFC 3840 defines media feature tags for every top-level media type, including application. That type covers an extremely broad range of subtypes: multiplayer games of all sorts, shared whiteboards, application sharing, and so on. With audio and video, there's usually a common codec that agents support (so a common subtype). That means if a caller wants an audio session, routing the request to any user agent that supports audio will probably work out fine. With application streams, though, just routing to an agent that supports some application stream isn't useful, because application streams for different applications are wildly different 🙈 So the application media feature tag doesn't give enough granularity for call preferences. The specific application subtype needs to be indicated too, periodt.

To fix this, this spec defines a new media feature tag that says which application subtypes the agent supports for streaming. The name of this tag is sip.app-subtype 🦋

2. Terminology 💖

okay this part is the key word situation 🔑 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 🎀

3. sip.app-subtype Media Feature Tag 🌈

the sip.app-subtype media feature tag is of type token, with a case-insensitive equality relationship. Its value can be any registered or private MIME application subtype that follows the subtype-name grammar defined in [RFC4288] 💅 When it's included in the Contact header field of a REGISTER request, an agent SHOULD include all the application subtypes it can support as streaming formats. An application subtype counts as supported if the user agent would be able to process a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that has that subtype as a format in the m-line of the SDP 🍓

When it's included in the Accept-Contact or Reject-Contact header field, it means a User Agent Client (UAC) wants to connect to a User Agent Server (UAS) that can support streaming with that application subtype, or cannot support it, respectively 🙌

This tag is only about the streaming media types a user agent can support. It says nothing about the functionality the user agent provides, or about the MIME types it can send or receive in SIP messages or emails. Let's say a SIP user agent can support 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 the MIME type "application/example". When a UA includes the sip.app-subtype media feature tag in a Contact header field with the value "example", it means the UA can handle a SIP INVITE that contained an SDP with an application media line and format of "example". It does NOT mean the SIP user agent is a chess app, or that it can accept SIP requests with bodies of type "application/example" 🙈 To say a user agent can accept SIP requests with bodies of type "application/example", the agent would use the "type" media feature tag defined in [RFC3840] 💜

Here's the consequence: as new streaming media type formats get defined (like game stream formats, whiteboard session formats, and so on), they SHOULD be defined using the SDP application stream and use a MIME application subtype ✨

4. Example 🍰

Here's a quick SIP REGISTER fragment showing this tag in action 👀 The REGISTER says the UA can take part in application media sessions that exchange objects of type "application/example".

REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
 ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
 ;uri-user="<Y1>"
 ;uri-domain="example.com"
 ;audio
 ;schemes="sip"
 ;mobility="fixed"
 ;class="personal"
 ;+sip.app-subtype="example"

That registration means an INVITE like this one would be accepted by the UA:

INVITE sip:Y@example.com SIP/2.0
To: sip:Y@example.com
Content-Type: application/sdp
Content-Length: ...

v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
c=IN IP4 192.0.1.2
t=0 0
m=audio 49170 RTP/AVP 0
m=application 8493 udp example

The SDP in that INVITE sets up an audio session and an application session that runs over UDP and exchanges "application/example" object formats 🎉

5. Security Considerations 🔐

Heads up, this section is serious business, so no cap, read it carefully 🙈

When it's present in a REGISTER request, this media feature tag reveals the set of supported application media streams. That information can be sensitive, since it can give insight into the capabilities of a product. RFC 3840 already covers these considerations, and they apply here too. Applications that use 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. So mechanisms for conveying the feature tag SHOULD provide a mechanism for guaranteeing authenticity 💀

6. IANA Considerations 🌸

The IANA Considerations text wasn't in the excerpt I was given, so there's nothing for me to rewrite here yet 🥺

7. References 📚

7.1. Normative References

The reference list text wasn't in the excerpt I was given, so there's nothing for me to rewrite here yet 🥺

7.2. Informative References

The reference list text wasn't in the excerpt I was given, so there's nothing for me to rewrite here yet 🥺

6. IANA Considerations ✨

okay so IANA gets a new feature tag bestie 🎀 this spec adds it to the SIP Media Feature Tag Registration Tree from RFC 3840 [RFC3840]. here's the full registration, no cap 💅

Media feature tag name:  sip.app-subtype

ASN.1 Identifier:  1.3.6.1.8.4.24

Summary of the media feature indicated by this tag:  This feature tag
   indicates the MIME application subtypes supported by the agent for
   purposes of streaming media.

Values appropriate for use with this feature tag:  Token (equality
   relationship).

The feature tag is intended primarily for use in the following
   applications, protocols, services, or negotiation mechanisms:
   This feature tag is most useful in a communications application,
   for describing the capabilities of a device, such as a phone or
   PDA.

Examples of typical use:  Routing a call to a phone that can support
   a multiplayer game.

Related standards or documents:  RFC 5688

Security Considerations:  Security considerations for this media
   feature tag are discussed in Section 5 of RFC 5688.

the vibe is: a phone or PDA that can handle a multiplayer game gets the call routed to it 🎮📞 main character energy 🦋

---

7. References 🌸

7.1. Normative References 💖

okay these are the ones you actually need to read to get this spec 🫶

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
           with Session Description Protocol (SDP)", RFC 3264,
           June 2002.

[RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
           "Indicating User Agent Capabilities in the Session
           Initiation Protocol (SIP)", RFC 3840, August 2004.

[RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
           Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
           Description Protocol", RFC 4566, July 2006.

7.2. Informative References 🧚

these are the extra reads if you're curious and want the full lore 📚✨

[RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
           A., Peterson, J., Sparks, R., Handley, M., and E.
           Schooler, "SIP: Session Initiation Protocol", RFC 3261,
           June 2002.

[RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
           Event Notification", RFC 3265, June 2002.

[RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
           Preferences for the Session Initiation Protocol (SIP)",
           RFC 3841, August 2004.

[RFC2506]  Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
           Registration Procedure", BCP 31, RFC 2506, March 1999.

---

Author's Address 🍓

the author is Jonathan Rosenberg, the whole crew behind this spec 👑 reach out here 💜

Jonathan Rosenberg
Skype
Monmouth, NJ
USA

EMail: jdrosen@jdrosen.net
URI:   http://www.jdrosen.net