RFC 5897

Identification of Communications Services in the Session Initiation Protocol (SIP)

📅 published June 2010, from ietf

RFC 5897: Identification of Communications Services in the Session Initiation Protocol (SIP) ✨

  • Number: RFC 5897
  • Author: J. Rosenberg (jdrosen.net) 💖
  • Category: Informational 🎀
  • Date: June 2010 🌸
  • ISSN: 2070-1721
  • Obsoletes / Updates: the title block lists neither, so this doc doesn't replace or update any other RFC 🦋

Abstract

okay bestie, this doc is about service identification in SIP 🧚 basically it's about figuring out the user-level use case that's driving the signaling a user agent (UA) is sending. the doc talks about why anyone would want that, lays out some architecture principles behind it, and calls out the perils when it's done wrong 😭 we're talking fraud, interoperability failures, and stifling innovation. then it ends with a set of recommended practices for doing it right 💅

Status of This Memo

this document is not an Internet Standards Track spec, it's published for informational purposes 📚

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🌈

info on the current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5897 ✨

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

this doc 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 publication date. please actually read those, they spell out your rights and restrictions for this doc 🙈 any Code Components pulled out of this doc have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💜

Table of Contents

   1. Introduction ....................................................3
   2. Services and Service Identification .............................4
   3. Example Services ................................................6
      3.1. IPTV vs. Multimedia ........................................6
      3.2. Gaming vs. Voice Chat ......................................7
      3.3. Gaming vs. Voice Chat #2 ...................................7
      3.4. Configuration vs. Pager Messaging ..........................7
   4. Using Service Identification ....................................8
      4.1. Application Invocation in the User Agent ...................8
      4.2. Application Invocation in the Network ......................9
      4.3. Network Quality-of-Service Authorization ..................10
      4.4. Service Authorization .....................................10
      4.5. Accounting and Billing ....................................11
      4.6. Negotiation of Service ....................................11
      4.7. Dispatch to Devices .......................................11
   5. Key Principles of Service Identification .......................12
      5.1. Services Are a By-Product of Signaling ....................12
      5.2. Identical Signaling Produces Identical Services ...........13
      5.3. Do What I Say, Not What I Mean ............................14
      5.4. Declarative Service Identifiers Are Redundant .............15
      5.5. URIs Are Key for Differentiated Signaling .................15
   6. Perils of Declarative Service Identification ...................16
      6.1. Fraud .....................................................16
      6.2. Systematic Interoperability Failures ......................17
      6.3. Stifling of Service Innovation ............................18
   7. Recommendations ................................................20
      7.1. Use Derived Service Identification ........................20
      7.2. Design for SIP's Negotiative Expressiveness ...............20
      7.3. Presence ..................................................21
      7.4. Intra-Domain ..............................................21
      7.5. Device Dispatch ...........................................21
   8. Security Considerations ........................................22
   9. Acknowledgements ...............................................22
   10. Informative References ........................................22

1. Introduction 🌸

the Session Initiation Protocol (SIP) [RFC3261] is the thing that sets up and manages communications sessions between agents 📞 and SIP can handle a huge range of session types 😭 audio can go from low-bitrate voice-only all the way up to multi-channel high-fidelity music 🎶 video can be a tiny "talking-head" video chat, or a high-definition multipoint video conference, and it can also be low-bandwidth user-generated content or high-definition movie and TV content 🍿 and SIP endpoints can literally be anything: adaptors that turn an old analog telephone into Voice over IP (VoIP) 📠, dedicated hardphones, fancy hardphones with rich displays and user entry, softphones on a PC, buddy-list and presence apps on a PC, dedicated videoconferencing peripherals, and speakerphones 🎤

this breadth is SIP's greatest asset 💅 but it also brings a bunch of challenges. one of them: when an endpoint generates a SIP INVITE for a session, or receives one, that session could be in the context of any number of different use cases and endpoint types 🤯 for example, a SIP INVITE with a single audio stream could be a Push-To-Talk session between mobile devices, a VoIP session between softphones, or audio-based access to stored content on a server 🎧

each of those use cases is a different service ✨ the service is the user-visible use case that's driving the behavior of the user agents and servers in the SIP network 👑

the differing services SIP can offer have made implementors and system designers hunt for ways to do service identification 🔍 that's the process of determining and/or signaling the specific use case driving the signaling a user agent generates. at first glance, this seems harmless and easy 🙃 it's tempting to just define a new header, like "Service-ID" (Service-ID), and have the user agent fill it with well-known tokens that say what the service is. then it could be used for any number of purposes 💖 a token placed into signaling for this purpose is called a service identifier 🏷️

service identification and service identifiers can be beneficial when they're used properly ✨ but when they're done improperly, service identification can lead to fraud, systemic interoperability failures, and a complete stifling of the innovation SIP was meant to enable 😭 this doc is here to explain service identification in more detail and show how those problems happen 🦋

Section 2 starts by defining a service and the service identification problem 📖 Section 3 gives some concrete examples of services and why they can be tricky to identify 🎮 Section 4 explores the ways a service identification can be used within a network 🌐 next, Section 5 covers the key architectural principles of service identification 🧩 and Section 6 describes what declarative service invocation is, and how it can lead to fraud, interoperability failures, and stifling of service innovation 💀

so this doc concludes that declarative service identification is harmful 🚫 declarative service identification is the process where a user agent puts a moniker into a message to define the desired service, separate from explicit and well-defined protocol mechanisms 🙅‍♀️

instead of declarative service identification, this doc recommends derived service identification 🌈 and it gives several recommendations around it in Section 7 💅

  1. The identity of a service should always be derived from the explicit signaling in the protocol messages and other contextual information, and never indicated by the user through a separate identifier placed into the message. 🫶
  2. The process of service identification based on signaling messages must be designed to SIP's negotiative expressiveness, and therefore handle heterogeneity and not assume a fixed set of use cases. 🧚
  3. Presence can help in providing URIs that can be utilized to connect to specific services, thereby creating explicit indications in the signaling that can be used to derive a service identity. 🦋
  4. Service identities placed into signaling messages for the purposes of caching the service identity are strictly for intra-domain usage. 🔒
  5. Device dispatch should be based on feature tags that map to well-defined SIP extensions and capabilities. Service dispatch should not be based on abstract service identifiers. 🎀

2. Services and Service Identification ✨

Okay so identifying services in SIP is not a new problem, bestie 💅. It got a LOT of attention in the context of presence. The presence data model for SIP [RFC4479] treats the service as one of the core notions that presence describes 🦋. Services are described in Section 3.3 of RFC 4479.

Basically, a service is the user-visible use case that drives how the user agents and servers in the SIP network behave. "User-visible" just means there's a difference in user experience between two services that are different. That experience can be part of the call or outside of it. Inside a call, it can come from different media types (an audio call vs. a video chat), different content within a media type (stored content, like a movie or TV session), different devices (a wireless device for "telephony" vs. a PC app for "voice chat"), different user interfaces (a buddy-list view of voice on a PC app vs. a software emulation of a hardphone), different communities you can reach (voice chat with other users on the same voice chat client vs. voice communications with any endpoint on the Public Switched Telephone Network (PSTN)), or different apps the user invokes (manually picking a Push-To-Talk app from a wireless phone vs. a telephony app). Outside of a call, the difference can be billing (cheaper for one service than another), a notification feature for one and not the other (like an IM that gets sent whenever a user makes a call), and so on 🎀.

Sometimes two services run on almost identical tech, and sometimes they're super different. But for this discussion, the key definition is that two services are distinct when the user perceives a difference between them 💜.

This naturally leads to wanting service identification. Service identification is defined as the process of:

  1. determining the underlying service that is driving a particular signaling exchange,
  2. associating that service with a service identifier, and
  3. attaching that moniker to a signaling message (typically a SIP INVITE).

Once service identification is performed, the service identifier can be used for all sorts of things in the network 🧚. Service identification can happen in the endpoints, where the UA inserts the moniker directly into the signaling message based on its awareness of the service. Or it can happen within a server in the network (like a proxy), based on inspection of the SIP message, or based on hints the user placed into the message.

When service identification is done entirely by inspecting the signaling, it's called derived service identification. When it's based only on knowledge possessed by the invoking user agent, it's called declarative service identification. Declarative service identification can only be done in user agents, by definition 🔥.

3. Example Services

It is so useful to look at several example services, especially ones that seem hard to tell apart 🙈. When something is hard to differentiate, service identification (and in particular, declarative service identification) looks highly attractive (and honestly, required 😭).

3.1. IPTV vs. Multimedia

IP Television (IPTV) is using IP networks to access traditional TV content, like movies and shows 📺. SIP can be used to set up a session to a media server in a network, which then serves up multimedia content and streams it as audio and video towards the client. Whether SIP is ideal for IPTV is honestly a good question, but that discussion is outside the scope of this doc 🤷.

Now consider multimedia conferencing. The user accesses a voice and video conference at a conference server. The user might join in listen-only mode, where they receive audio and video streams but don't send anything 🎧.

These two services (IPTV and listen-only multimedia conferencing) clearly look like different services. They have different user experiences and applications. A user is unlikely to ever be confused about whether a session is IPTV or listen-only multimedia conferencing. Honestly, they're likely to have different software applications or endpoints for the two services 💅.

However, these two look remarkably alike based on the signaling 😵. Both use audio and video. Both could use the same codecs. Both are unidirectional streams (from a server in the network to the client). So it would appear on the surface that there's no way to tell them apart by inspecting the signaling alone.

3.2. Gaming vs. Voice Chat

Picture an interactive game played between two users from their mobile devices 🎮. The game involves the users sending each other game moves using a messaging channel, in addition to voice. In another service, users have a voice and IM chat conversation using a buddy-list application on their PC.

In both services there are two media streams: audio and messaging. The audio uses the same codecs. Both use the Message Session Relay Protocol (MSRP) [RFC4975]. In both cases, the caller would send an INVITE to the Address of Record (AOR) of the target user. But these represent fairly different services, in terms of user experience 🌸.

3.3. Gaming vs. Voice Chat #2

Consider a variation on the example in Section 3.2. In this variation, two users are playing an interactive game between their phones 📱. However, the game itself is set up and controlled using a proprietary mechanism, not using SIP at all. The client application still lets the user chat with their opponent. The chat session is a simple voice session set up between the players.

Compare this with a basic telephone call between the two users. Both involve a single audio session. Both use the same codecs. They appear to be identical. But different user experiences are needed. For example, we want traditional telephony features (like call forwarding and call screening) applied in the telephone service, but not in the gaming chat service 💖.

3.4. Configuration vs. Pager Messaging

The SIP MESSAGE method [RFC3428] gives us a way to send one-shot messages to a particular AOR 💌. This specification is primarily aimed at Short Message Service (SMS)-style messaging, the kind commonly found in wireless phones. Receiving a MESSAGE request would cause the messaging app on a phone to launch, letting the user browse the message history and respond.

However, a MESSAGE request is sometimes used to deliver content to a device for other purposes. For example, some providers use it to deliver configuration updates, like new phone settings or parameters, or to indicate that a new version of firmware is available. Though it's not designed for this purpose, the MESSAGE method gets used anyway, since in existing wireless networks SMS is used for this, and the MESSAGE request is the SIP equivalent of SMS 🥹.

So the MESSAGE request sent to a phone can be for two different services. One would require invocation of a messaging app, whereas the other would be consumed by the software in the phone without any user interaction at all 🤖.

4. Using Service Identification

It's important to understand what the service identity would be used for, if known 👑. This section discusses the primary uses. These are application invocation in user agents and the network, Quality of Service authorization, service authorization, accounting and billing, service negotiation, and device dispatch.

4.1. Application Invocation in the User Agent

In some of the examples above, there were multiple software applications running on the host. One common way of achieving this is to use a common SIP user agent implementation that listens for requests on a single port. When an incoming INVITE or MESSAGE arrives, it must be delivered to the appropriate application software. When each service is bound to a distinct software application, it would seem that the service identity is needed to dispatch the message to the appropriate piece of software. This is shown in Figure 1.

                    +---------------------------------+
                    |                                 |
                    | +-------------+ +-------------+ |
                    | |     UI      | |     UI      | |
                    | +-------------+ +-------------+ |
                    | +-------------+ +-------------+ |
                    | |             | |             | |
                    | |  Service 1  | |  Service 2  | |
                    | |             | |             | |
                    | +-------------+ +-------------+ |
                    | +-----------------------------+ |
                    | |                             | |
                    | |             SIP             | |
                    | |            Layer            | |
                    | |                             | |
                    | +-----------------------------+ |
                    |                                 |
                    +---------------------------------+

                             Physical Device

                                 Figure 1

The role of the SIP layer is to parse incoming messages, handle the SIP state machinery for transactions and dialogs, and then dispatch requests to the appropriate service 🧠. This software architecture is analogous to the way web servers frequently work. An HTTP server listens on port 80 for requests, and based on the HTTP Request-URI, dispatches the request to a number of disparate applications. The same is happening here. For the example services in Section 3.2, an incoming INVITE for the gaming service would be delivered to the gaming application software. An incoming INVITE for the voice chat service would be delivered to the voice chat application software. The example in Section 3.3 is similar. For the examples in Section 3.4, a MESSAGE request for user-to-user messaging would be delivered to the messaging or SMS app, and a MESSAGE request containing configuration data would be delivered to a configuration update application.

Unlike the web, however, in all three use cases, the user initiating communications has (or appears to have -- more below) only a single identifier for the recipient, their AOR 🥺. Consequently, the SIP Request-URI cannot be used for dispatching, as it is identical in all three cases 💀.

4.2. Application Invocation in the Network 🌸

okay so another way a service identifier can be used is to make servers inside the SIP network do extra work based on which service it is 🎀 like, an INVITE from a user agent for IPTV would go through a server doing content rights management, which checks whether the user is allowed to access that content 🔐. meanwhile an INVITE for multimedia conferencing would go through a server with "traditional" telephony features, like outbound call screening and call recording 📞. it would be totally nonsensical for the IPTV INVITE to get outbound call screening and call recording, and it would be nonsensical for the multimedia conferencing INVITE to get handled by the content rights management server 🙈. and this isn't just about efficiency (calling servers when they aren't needed), because truly incorrect behavior can happen 💀. say an outbound call screening app is set to block outbound calls to everything except the phone numbers of friends and family. an IPTV request that gets processed by that server would get blocked, since it isn't targeted to the AOR of a friend or family member 😭. that would block a user from accessing IPTV, which was never the goal at all!!

also, a MESSAGE request as described in Section 3.4 might need to go through a message server for filtering when it's tied to chat, but not when it's tied to a configuration update ✨.

let's say there's a filter applied to MESSAGE requests, and it runs in a server in the network. the filter stops user Joe from sending messages to user Bob that contain the words "stock" or "purchase", because of some regulations that don't allow Joe and Bob to talk about stock trading 📈. but a MESSAGE for configuration purposes might have an XML document that uses the token "stock" as some kind of attribute 🧾. that configuration update would get thrown out by the filtering server, even though it shouldn't have been 😤.

4.3. Network Quality-of-Service Authorization 🦋

the IP network can give different levels of Quality of Service (QoS) to IP packets 🚀. this can include guaranteed throughput, latency, or loss characteristics 📊. typically, the user agent makes some kind of QoS request, either with explicit signaling protocols (like the Resource ReSerVation Protocol (RSVP) [RFC2205]) or by marking a Diffserv value in packets 🏷️. the network then needs to make a policy decision about whether these QoS treatments are authorized 🧐. one common authorization policy is to check whether the user invoked a service using SIP that they're authorized to invoke, and whether that service needs the level of QoS treatment they asked for 💜.

for example, think about IPTV and multimedia conferencing from Section 3.1 🎬. IPTV is a non-real-time service, so its media traffic would be authorized for bandwidth guarantees, but not for latency or loss guarantees 📺. multimedia conferencing, on the other hand, is real time, so its traffic would need bandwidth, loss, and latency guarantees from the network 🎤.

so if a user makes an RSVP reservation for a media stream and asks for latency guarantees for it, the network would be able to authorize that if the service is multimedia conferencing, but not if it's IPTV 🙅‍♀️. to make that call, the server doing QoS authorization would need to know which service is tied to the INVITE that set up the session 🧠.

4.4. Service Authorization 🔑

a network admin will often want to decide whether a user is allowed to invoke a particular service 👑. not everyone gets access to every service that's offered. for example, a user might not be authorized for IPTV services but still be authorized for multimedia processing 🎞️. a user might not be able to use a multiplayer gaming service but still be allowed to use voice chat services 🎮.

so when an INVITE shows up at a server in the network, that server needs to figure out what the requested service is, so it can make an authorization decision 💅.

4.5. Accounting and Billing 💸

service authorization and accounting/billing go hand in hand, bestie 🫶. one of the main reasons for authorizing a user to use a service is that they get billed differently depending on the type of service 🧾. so one of the goals of a service identity is to be included in accounting records, so the right billing model can be applied 💖.

for instance, with IPTV, a service provider can bill based on the content (US $5 per movie, perhaps 🍿), whereas for multimedia conferencing, they can bill by the minute ⏱️. this means the accounting streams need to show which service was invoked for each particular session 📒.

4.6. Negotiation of Service 🤝

sometimes, when a caller starts a session, they don't actually know which service will be used 🤷‍♀️. they might offer up all of the services they have available to the called party and let the called party choose, or let the system decide based on overlapping service capabilities 🌈.

for example, a user can do both the game and the voice chat service from Section 3.2 🎧. the user starts a session to a target AOR, but the target's devices can only support voice chat 📱. the called device sends back an indication in its call acceptance that only voice chat can be used 🙌. so voice chat is what gets used for the session 🎙️✨.

4.7. Dispatch to Devices 📲

when a user has several devices, each with different service capabilities, it's really useful to send an incoming request to the right device based on whether that device can support the requested service 🧚.

for example, say a user starts a gaming session with voice chat, and the target user has two devices -- one that can support the gaming service and one that can't 🎮. the INVITE should be sent to the device that supports the gaming session 💜.

5. Key Principles of Service Identification 👑

in this section, we go over a few key principles of service identification 💫:

  1. Services are a by-product of signaling
  2. Identical signaling produces identical services
  3. Declarative service identification is an example of "Do What I Mean" (DWIM)
  4. Declarative service identifiers are redundant
  5. URIs are a key mechanism for producing differentiated signaling

5.1. Services Are a By-Product of Signaling 🎀

declarative service identification (where clients add a service identifier to tell other entities what the service is) is a super compelling solution for the use cases we described above 🥰. it gives a clear way to tell each of those use cases apart ✨. derived service identification, on the other hand, looks "hard", because the signaling seems to be the same for these different services 😵‍💫.

declarative service identification misses a key point, and I literally cannot stress it enough, because it's the core architectural principle here 🔥:

A service is the byproduct of the signaling and the context around it (the user profile, time of day, and so on) -- the effects of the signaling message once it is launched into the network. The service identity is therefore always derivable from the signaling and its context without additional identifiers. In other words, derived service identification is always possible when signaling is being properly handled.

so when a user sends an INVITE to the network, targets it at an IPTV server, and includes the Session Description Protocol (SDP) for audio and video streaming, the result of sending that INVITE is an IPTV session 📺. the whole point of the INVITE is to set up that session and therefore invoke the service 🎯. so a service isn't something separate from the rest of the signaling message 🙅‍♀️. a service is what the user gets after the network and other user agents have processed a signaling message 🌟.

now, you might think delayed offers (SIP INVITE requests that lack SDP) make derived service identification impossible 😬. after all, in some of the cases above, the difference was made using the SDP in the request. what if it's not there? the answer is simple: if it's not there, and the SDP is being offered by the called party, you can't actually know the service at the time of the INVITE 🙃. that's the whole point of delayed offer, to give the called party a chance to offer what it wants for the session 🫧. so in cases where service identification is needed at request time, delayed offer can't be used 🚫.

5.2. Identical Signaling Produces Identical Services ✨

Okay bestie, this one is basically the natural sequel to the last principle 💅. If a service is the byproduct of signaling, how could a user have different experiences and different services when the signaling message is the same? They literally can't 🙈

But how can that be? Looking at the examples in Section 3, it seems like some services are different but have identical signaling. If we stay true to the assertion, there's really only one logical conclusion:

If two services are different, but their signaling appears to be the same, it is because one or more of the following is true:

  1. there is in fact something different that has been overlooked
  2. something has been implied from the signaling, when in fact it should have been signaled explicitly
  3. the signaling mechanism should be changed so that there is, in fact, something that is different

To illustrate this, let's take each of the example services in Section 3 and investigate whether there is, or should be, something different in the signaling in each case 🔍

IPTV vs. Multimedia Conferencing: The two services described in Section 3.1 look like they have identical signaling. Both involve audio and video streams, and both streams are unidirectional. Both might use the same codecs. BUT there's another important difference in the signaling: the target URI 🎯 With IPTV, the request is targeted at a media server or at a particular piece of content to be viewed. With multimedia conferencing, the target is a conference server. So the administrator of the domain can look at the Request-URI and figure out whether it's targeted at a conference server or a content server, and use that to derive the service associated with the request. Iconic, right? ✨

Gaming vs. Voice Chat: Though both sessions involve MSRP and voice, and both are targeted to the same AOR of the called user, there IS a difference 👀 The MSRP messages for the gaming session carry content that's game specific, whereas the MSRP messages for the voice chat are just regular text, meant for rendering to a user. So the MSRP session in the SDP will indicate the specific content type that MSRP is carrying, and this type will differ in both cases. Even if the game moves look like text, they're being consumed by an automata, so there's an underlying schema that dictates their content. That schema represents the actual content type that should be signaled 🤓

Gaming vs. Voice Chat #2: In this case, both sessions involve only voice, and both are targeted at the same AOR. Honestly? There truly is nothing different, if the signaling works this way 😭 BUT there's an alternative mechanism for doing the signaling. For the gaming session, the proprietary protocol can be used to exchange a URI that identifies the voice chat function on the phone that's associated with the game (for example, a Globally Routable User Agent URI (GRUU) can be used [RFC5627]). The gaming chat isn't targeting the USER. It's targeting the gaming instance on the phone 📱 So if a special GRUU is used for the gaming chat, the signaling becomes different between these two services. Main character energy for the signaling 💜

Configuration vs. Pager Messaging: Just like with gaming vs. voice chat, the content type of the messages is what differentiates the service that happens as a consequence of those messages 💌

5.3. Do What I Say, Not What I Mean 🎀

"Do What I Mean", abbreviated as DWIM, is a concept in computer science. It's sometimes used to describe a function that tries to intelligently guess what the user intended. It's the opposite of "Do What I Say", or DWIS, which describes a function that behaves concretely based on the inputs it's given. Systems built on DWIM can have unexpected behaviors, because they're driven by unstated rules 🙃

Declarative service identification is an example of DWIM. The service identifier has no well-defined impact on the state machinery or protocols in the system. It has various side effects based on an assumption of what the service identifier is meant to mean. Derived service identification, on the other hand, is an expression of the principle of DWIS. The behavior of the system is based entirely on the specifics of the protocol and is well defined by the protocol specification 🧚 The service identifier is just a shorthand for summarizing things that are already well defined by signaling.

Here's a litmus test to tell the two cases apart 🧪 If a request contained a service identifier, and that request were processed by a domain that didn't understand service identifiers at all, would the request be rejected if that service weren't supported? Or would it complete but do the wrong thing? If it's the latter, it's DWIM. If it's the former, it's DWIS.

5.4. Declarative Service Identifiers Are Redundant 🦋

Because a declarative service identifier is, by definition, inside the signaling message, and because the signaling itself completely defines the behavior of the service, another natural conclusion follows: a declarative service identifier is redundant with the signaling itself. It says nothing that couldn't or shouldn't otherwise be derived from examining the signaling. So why are we even carrying it around? 🤷‍♀️

5.5. URIs Are Key for Differentiated Signaling 🌈

In the IPTV example and in the second gaming example, it was ultimately the Request-URI that was (or should be) different between the two services. This is SO important 🫶 In many cases where services appear the same, it's because the resource being targeted is not actually the user. It's a resource that's linked with the user. That resource might be an instance of a software application on the user's particular device, or a resource in the network that acts on behalf of the user.

The Request-URI is an infinitely large namespace for identifying these resources. It's an ideal mechanism for providing differentiation when there would otherwise be none 🔑

Returning to the example in Section 3.3, it does make more sense to target the gaming chat session at a software instance on the user's phone, rather than at the user themselves. The gaming chat session should really only go to the phone where the user is playing the game. The software instance lives only on that phone, whereas the user can be contacted in many ways. We don't want telephony features invoked for the gaming chat session, because those features only make sense when someone is trying to communicate with the USER. When someone is trying to communicate with a software instance that acts on behalf of the user, a different set of rules applies, since the target of the request is completely different 🎮

6. Perils of Declarative Service Identification 💀

Based on these principles, several perils of declarative service identification can be described. They are:

  1. Declarative service identification can be used for fraud
  2. Declarative service identification can hurt interoperability
  3. Declarative service identification can stifle service innovation

6.1. Fraud 😭

Declarative service identification can lead to fraud, and that's a big red flag 🚩 If a provider uses the service identifier for billing and accounting purposes, or for authorization purposes, it opens an avenue for attack. The user can construct the signaling message so that its actual effect (which is the service the user will receive) is what the user wants, but the user places a service identifier into the request (which is what's used for billing and authorization) that identifies a cheaper service, or one they aren't authorized to receive. In that case, the user gets the service and doesn't get billed properly for it. Not it 💅

If, however, the domain administrator derived the service identifier from the signaling itself (derived service identification), the user cannot lie. If they did lie, they wouldn't get the service they wanted in the first place 🙅‍♀️

Consider the example of IPTV vs. multimedia conferencing. If multimedia conferencing is cheaper, the user could send an INVITE for an IPTV session but include a service identifier that indicates multimedia conferencing. The user gets the service associated with IPTV, but at the cost of multimedia conferencing. Sneaky, but not cute 😤

This same principle shows up in other places too, like in identifying an emergency services call [ECRIT-FRAMEWORK]. It's desirable to give emergency services calls special treatment, such as being free and authorized even when the user otherwise can't make calls, and to give them priority 🚨 If emergency calls were indicated through something other than the target of the call being an emergency services URN [RFC5031], it would open an avenue for fraud. The user could place any desired URI in the request-URI and indicate separately, through a declarative identifier, that the call is an emergency services call. That would get special treatment, but of course the call would still get routed to the target URI. The only way to prevent this fraud is to treat an emergency call as any call whose target is an emergency services URN. So the service identification here is based on the target of the request. When the target is an emergency services URN, the request can get special treatment. The user can't lie about it, since there's no way to separately indicate that this is an emergency call besides targeting it to an emergency URN 🆘✨

6.2. Systematic Interoperability Failures 💥

Okay so how can declarative service identification actually break interop? 🤔 When an identifier is used to drive functionality, like dispatch on the phones, in the network, or QoS authorization, the wrong thing can happen whenever that field isn't set properly. 😭

Picture a user in domain 1 calling a user in domain 2. 📞 Domain 1 has a service they call "voice chat," which uses voice and IM for real-time conversation, driven off a buddy-list app on a PC. 💻 Domain 2 has a service they call "text telephony," which is a voice service on a wireless device that also lets you send text messages. 📱 Now say both domains have their user agents insert a service identifier into the request, and then use it for QoS authorization, accounting, and invoking applications in the network and on the device. 👀 The user in domain 1 calls the user in domain 2 and puts the identifier "Voice Chat" into the INVITE. 🎀 When that arrives at the server in domain 2, the service identifier is unknown to it. 🙈 So the request doesn't get the proper QoS treatment, even though the call itself might still succeed. 💅

Now, if derived service identification were used instead, domain 2 could strip the service identifier and then recompute it from the signaling so it matches domain 2's own idea of services. ✨ In that case, domain 2 could derive the "text telephony" identifier, and the request completes successfully. 🥳

Declarative service identification, used between domains, causes interoperability failures unless every interconnected domain agrees on exactly the same set of services and how to name them. 🫠 Now, lacking service identifiers doesn't guarantee service interoperability either. 🙃 BUT SIP was built with rich tools for negotiating capabilities at a super granular level, so it's not all doom! 🌈 One user agent can make a call using audio and video, and if the receiving UA only supports audio, SIP lets both sides negotiate down to the lowest common denominator. 🫶 Communication still happens. Another example: if one agent starts a Push-To-Talk session (which is audio with a companion floor control mechanism) and the other side only does regular audio, SIP can negotiate back down to a regular voice call. 📢 And if a calling user agent is running a high-definition video conferencing endpoint while the called user agent only supports a regular video endpoint, the codecs themselves can negotiate down to a lower rate, picture size, and so on. 🎞️ Interoperability is achieved! 🎉

Here's the interesting bit: the final "service" may no longer match the service identifier that would have been placed in the original INVITE. 🤯 For instance, if the caller's original INVITE contained the service identifier "hi-fi video", but the video gets negotiated down to a lower rate and picture size, that identifier is no longer really appropriate. 🙈 That's exactly why services need to be derived from signaling, because the signaling itself provides the negotiation and interoperability between different domains. 🦋

This shows another key part of the interoperability problem. Declarative service identification will produce inconsistencies between its service identifiers and the results of any SIP negotiation that might otherwise be applied in the session. 😬

When a service identifier becomes something that both proxies and the user agent need to understand in order to properly treat a request (which is exactly the case for declarative service identification), it's basically the same as putting a token in the Proxy-Require and Require header fields of every single SIP request. 💀 The very reason [RFC4485] side-eyes the use of Require (and really Proxy-Require) is the huge impact it has on interoperability. 🙅‍♀️ For that same reason, declarative service identification needs to be avoided. 🚫💖

6.3. Stifling of Service Innovation 🫣

The chance that any two service providers end up with the same set of services and give those services the same names gets smaller and smaller as the number of providers grows. 📉 Honestly, it would almost certainly take a centralized authority to decide what the services are, how they work, and what they're called. 🏛️ That in turn leads to a need for complete homogeneity just so things can interconnect. 😩 Two providers can't really interconnect unless they agree on the set of services they offer their customers and each do the same thing. 🙃 Why? Because each provider has become dependent on the proper service identifier being in the request, so the overall treatment of the request can proceed correctly. 🥲 This is, in a very real sense, anathema to the whole notion of SIP, which is built on the idea that heterogeneous domains can interconnect and still get interoperability. 🌸

Declarative service identification leads to a need for homogeneity in service definitions across the providers that interconnect, which totally ruins the service heterogeneity SIP was meant to bring. 💔

And get this: Metcalfe's Law says the value of a network grows with the square of the number of participants. 📈 So once a bunch of large domains got together, agreed on a set of services, and then agreed on a set of well-known identifiers for those services, other providers would be forced to deploy the same services too, just to get the value that interconnection brings. 😤 That in turn will stifle innovation and quickly lock the set of services in SIP in place, never letting it expand beyond the ones initially agreed upon. 🧊 This is also anathema to the very framework SIP is built on, and it defeats much of the purpose of why providers chose to deploy SIP in their own networks. 🙅‍♀️✨

Let's look at an example. 👀 Several providers get together and standardize a bunch of service identifiers. One of them uses audio and video (let's say "multimedia conversation"). It's successful and widely used. 🎥 Endpoints look for this identifier to dispatch calls to the right software applications, and the network looks for it to invoke features, perform accounting, and provide QoS. 🧠 Then a new provider gets the idea for a new service (let's say "avatar-enhanced multimedia conversation"). 🧚 In this service there's audio and video, plus a third stream that renders an avatar. A caller can press buttons on their phone to make the avatar on the other person's device show emotion, make noise, and so on. 🤡 It's similar to how emoticons are used in IM today. 😊 The service is enabled by adding a third media stream (and therefore a third m-line) to the SDP. 🎀

Normally, this service would be backwards-compatible with a regular audio-video endpoint, which would just reject the third media stream. 🤷‍♀️ BUT, because a large network has been deployed that expects to see the token "multimedia conversation" and its associated audio+video service, it's nearly impossible for the new provider to roll out this new service. 😭 If they tried, it would fail completely, or partially fail, whenever their users call users in other provider domains. 💔🙈

7. Recommendations 📝

From these principles, several recommendations can be made. 🫶

7.1. Use Derived Service Identification 🦋

Derived service identification (where an identifier for a service is obtained by inspecting the signaling and other contextual data, such as the subscriber profile) is reasonable, and when done properly, it doesn't lead to the perils described above. ✅ Declarative service identification, on the other hand (where user agents indicate what the service is, separate from the rest of the signaling), does lead to the perils described above. 🚩

If it looks like the signaling currently defined in standards isn't sufficient to identify the service, it might be because there isn't enough signaling to convey what's needed, or because request URIs should be used for differentiation and aren't being used. 🔍 By applying the litmus tests described in Section 5.3, network designers can figure out whether or not the system is attempting declarative service identification. 🧪💅

7.2. Design for SIP's Negotiative Expressiveness 🗣️

One of SIP's biggest strengths is its ability to negotiate a common view of a session between participants. 🤝 This means the service that's ultimately received can vary wildly, depending on the types of endpoints in the call and their capabilities. 🌈 This fact becomes even more obvious when calls are set up between domains. 🌍

So when performing derived service identification, domains should be aware that sessions may arrive from different networks and different endpoints. 🧭 As a result, the service identification algorithm must be complete, meaning it computes the best answer for any possible signaling message that might be received and any session that might be set up. 💯

In a homogeneous environment, service identification is easy. 😌 The service provider knows the set of services they provide, and based on the specific call flows for each service, they can build rules to tell one service from another. 🧩 But when different providers interconnect, or when different endpoints are introduced, assumptions about which services are used and how they're signaled no longer hold. 🙃 To give users the best experience possible, a provider doing service identification needs to perform a "best-match" operation, so that any legal SIP signaling (not just the specific call flows running inside their own network among a limited set of endpoints) gets mapped to the appropriate service. 🎯✨

7.3. Presence 💜

Presence can help a lot with providing unique URIs for different services. 🙌 When a user wants to contact another user and only knows the AOR for the target (which is usually the case), the user can fetch the presence document for the target. 📄 That document can contain numerous service URIs for contacting the target with different services. 🔗 Those URIs can then be used in the Request-URI for differentiation. 🪄 When possible, this is the best solution to the problem. 🏆

7.4. Intra-Domain 🏠

Service identifiers themselves aren't bad! 🥰 Derived service identification lets each domain cache the results of the service identification process for use by another network element within the same domain. 🧁 However, service identifiers are fundamentally useful within a particular domain, and any such header must be stripped at a network boundary. 🚧 So the process of service identification, and its associated service identifiers, is always an intra-domain operation. 🫧

7.5. Device Dispatch 🎀

Okay so device dispatch should be done following the principles of [RFC3841], using implicit preferences based on the signaling. For example, [RFC5688] defines a new UA capability that can be used to dispatch requests based on different types of application media streams. ✨

BUT bestie, it is a mistake to try and use a service identifier as a UA capability 🙈 Picture a service called "multimedia telephony", which adds video to the existing PSTN experience. A user has two devices: one is used for multimedia telephony and the other is strictly for a voice-assisted game 🎮 It's super tempting to have the telephony device include a UA capability [RFC3840] called "multimedia telephony" in its registration. Then a calling multimedia telephony device can include the Accept-Contact header field [RFC3841] containing this feature tag. The proxy serving the called party, applying the basic algorithms of [RFC3841], will correctly route the call to the terminating device 💅

Here's the tea though ☕ If the calling party is not within the same domain, and the calling domain does not know about or use this feature tag, there will be no Accept-Contact header field. That's true even if the calling party was using a service that is a total match for "multimedia telephony" 😭 In that case, the call may be delivered to both devices, which is a much poorer user experience. That's because device dispatch was done using declarative service identification 💀

The best way to avoid this problem is to use feature tags that can be matched to well-defined signaling features, like media types, required SIP extensions, and so on 🦋 In particular, the golden rule is that the granularity of feature tags must be equivalent to the granularity of individual features that can be signaled in SIP 👑

8. Security Considerations 🔒

Oftentimes, the service associated with a request is used for things like authorization, accounting, and billing 💸 When service identification is not done properly, the door opens to unauthorized service use and network fraud. It's for this reason, discussed extensively in Section 6.1, that the usage of declarative service identifiers inserted by a UA is not recommended. This one is seriously important, no cap 🚨

9. Acknowledgements 🫶

This document is based on discussions with Paul Kyzivat and Andrew Allen, who contributed significantly to the ideas here. Much of the content in this document came out of discussions amongst participants in the SIPPING mailing list, including Dean Willis, Tom Taylor, Eric Burger, Dale Worley, Christer Holmberg, and John Elwell, amongst many others. Thanks to Spencer Dawkins, Tolga Asveren, Mahesh Anjanappa, and Claudio Allochio for reviews of this document 💜

10. Informative References 📚

[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.

[RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
           July 2006.

[RFC4485]  Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
           of Extensions to the Session Initiation Protocol (SIP)",
           RFC 4485, May 2006.

[RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
           Session Relay Protocol (MSRP)", RFC 4975, September 2007.

[RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
           Emergency and Other Well-Known Services", RFC 5031,
           January 2008.

[ECRIT-FRAMEWORK]
           Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
           "Framework for Emergency Calling using Internet
           Multimedia", Work in Progress, July 2009.

[RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
           Agent URIs (GRUUs) in the Session Initiation Protocol
           (SIP)", RFC 5627, October 2009.

[RFC5688]  Rosenberg, J., "A Session Initiation Protocol (SIP) Media
           Feature Tag for MIME Application Subtypes", RFC 5688,
           January 2010.

[RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
           and D. Gurle, "Session Initiation Protocol (SIP) Extension
           for Instant Messaging", RFC 3428, December 2002.

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

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

[RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
           Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
           Functional Specification", RFC 2205, September 1997.

Author's Address 🌸

Jonathan Rosenberg
jdrosen.net
Monmouth, NJ
USA

EMail: jdrosen@jdrosen.net
URI:   http://www.jdrosen.net
📦 where this page comes from