draft-ietf-sipping-service-identification-00.txt   draft-ietf-sipping-service-identification-01.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Best Current August 1, 2007 Intended status: Informational February 24, 2008
Practice Expires: August 27, 2008
Expires: February 2, 2008
Identification of Communications Services in the Session Initiation Identification of Communications Services in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-service-identification-00 draft-ietf-sipping-service-identification-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document considers the problem of service identification in the This document considers the problem of service identification in the
Session Initiation Protocol (SIP). Service identification is the Session Initiation Protocol (SIP). Service identification is the
process of determining the user-level use case that is driving the process of determining the user-level use case that is driving the
signaling being utilized by the user agent. While seemingly simple, signaling being utilized by the user agent. This document discusses
this process is quite complex, and when not addressed properly, can the uses of service identification, and outlines several
lead to fraud, interoperability problems, and stifling of innovation. architectural principles behind the process. It identifies several
perils associated with service identification, including fraud,
This document discusses these problems and makes recommendations on interoperability failures and stifling of innovation.
how to address them.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Services and Service Identification . . . . . . . . . . . . . 4
3. Services and Service Identification . . . . . . . . . . . . . 4 3. Example Services . . . . . . . . . . . . . . . . . . . . . . . 5
4. Example Services . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 5
4.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 6 3.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 5
4.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 7 3.3. Configuration vs. Pager Messaging . . . . . . . . . . . . 6
4.3. Configuration vs. Pager Messaging . . . . . . . . . . . . 7 4. Using Service Identification . . . . . . . . . . . . . . . . . 6
5. Using Service Identification . . . . . . . . . . . . . . . . . 7 4.1. Application Invocation in the User Agent . . . . . . . . . 6
5.1. Application Invocation in the User Agent . . . . . . . . . 8 4.2. Application Invocation in the Network . . . . . . . . . . 8
5.2. Application Invocation in the Network . . . . . . . . . . 9 4.3. Network Quality of Service Authorization . . . . . . . . . 8
5.3. Network Quality of Service Authorization . . . . . . . . . 9 4.4. Service Authorization . . . . . . . . . . . . . . . . . . 9
5.4. Service Authorization . . . . . . . . . . . . . . . . . . 10 4.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 9
5.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 10 4.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 9
5.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 10 4.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 10
5.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 11 5. Key Principles of Service Identification . . . . . . . . . . . 10
6. Key Principles of Service Identification . . . . . . . . . . . 11 5.1. Services are a By-Product of Signaling . . . . . . . . . . 10
6.1. Services are a By-Product of Signaling . . . . . . . . . . 11 5.2. Identical Signaling Produces Identical Services . . . . . 11
6.2. Perils of Explicit Identifiers . . . . . . . . . . . . . . 13 5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 12
6.2.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Explicit Service Identifiers are Redundant . . . . . . . . 12
6.2.2. Systematic Interoperability Failures . . . . . . . . . 14 6. Perils of Explicit Identifiers . . . . . . . . . . . . . . . . 13
6.2.3. Stifling of Service Innovation . . . . . . . . . . . . 16 6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Systematic Interoperability Failures . . . . . . . . . . . 14
6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 15
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Informational References . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informational References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [2] defines mechanisms for The Session Initiation Protocol (SIP) [RFC3261] defines mechanisms
initiating and managing communications sessions between agents. SIP for initiating and managing communications sessions between agents.
allows for a broad array of session types between agents. It can SIP allows for a broad array of session types between agents. It can
manage audio sessions, ranging from low bitrate voice-only up to manage audio sessions, ranging from low bitrate voice-only up to
multi-channel hi fidelity music. It can manage video sessions, multi-channel hi fidelity music. It can manage video sessions,
ranging from small, "talking-head" style video chat, up to high ranging from small, "talking-head" style video chat, up to high
definition multipoint video conferencing, to low bandwidth user- definition multipoint video conferencing, to low bandwidth user-
generated content, up to high definition movie and TV content. SIP generated content, up to high definition movie and TV content. SIP
endpoints can be anything - adaptors that convert an old analog endpoints can be anything - adaptors that convert an old analog
telephone to Voice over IP (VoIP), dedicated hardphones, fancy telephone to Voice over IP (VoIP), dedicated hardphones, fancy
hardphones with rich displays and user entry capabilities, softphones hardphones with rich displays and user entry capabilities, softphones
on a PC, buddylist and presence applications on a PC, dedicated on a PC, buddylist and presence applications on a PC, dedicated
videoconferencing peripherals, and speakerphones. videoconferencing peripherals, and speakerphones.
This breadth of applicability is SIPs greatest asset, but it also This breadth of applicability is SIP's greatest asset, but it also
introduces numerous challenges. One of these is that, when an introduces numerous challenges. One of these is that, when an
endpoint generates a SIP INVITE for a session, or receives one, that endpoint generates a SIP INVITE for a session, or receives one, that
session can potentially be within the context of any number of session can potentially be within the context of any number of
different use cases and endpoint types. For example, a SIP INVITE different use cases and endpoint types. For example, a SIP INVITE
with a single audio stream could represent a Push-To-Talk session with a single audio stream could represent a Push-To-Talk session
between mobile devices, a VoIP session between softphones, or audio- between mobile devices, a VoIP session between softphones, or audio-
based access to stored content on a server. based access to stored content on a server.
These differing use cases have driven implementors and system These differing use cases have driven implementors and system
designers to seek techniques for service identification. Service designers to seek techniques for service identification. Service
identification is the process of determining and/or signaling the identification is the process of determining and/or signaling the
specific use case that is driving the signaling being generated by a specific use case that is driving the signaling being generated by a
user agent. At first glance, this seems harmless and easy enough. user agent. At first glance, this seems harmless and easy enough.
It is tempting to define a new header, "Service-ID", for example, and It is tempting to define a new header, "Service-ID", for example, and
have a user agent populate it with any number of well-known tokens have a user agent populate it with any number of well-known tokens
which define what the service is. This information could then be which define what the service is. It could then be consumed for any
consumed for any number of purposes. number of purposes. A service identifier placed into the signaling
is called an explicit service identifier.
However, as this document will demonstrate, service identification is Explicit service identifiers have many problems, however. They are
a very complex and difficult process, and can very easily lead to redundant with the signaling itself (which is the ultimate expression
fraud, systemic interoperability failures, and a complete stifling of of the service that is desired), and are an example of Do-What-I-Mean
the innovation that SIP was meant to achieve. (DWIM). Consequently, their usage can lead to fraud, systemic
interoperability failures, and a complete stifling of the innovation
that SIP was meant to achieve. The purpose of this document is to
describe service identification in more detail and describe how these
problems arise.
Section 3 begins by defining a service and the service identification Section 2 begins by defining a service and the service identification
problem. Section 4 gives some concrete examples of services and why problem. Section 3 gives some concrete examples of services and why
they can be challenging to identify. Section 5 explores the ways in they can be challenging to identify. Section 4 explores the ways in
which a service identification can be utilized within a network. which a service identification can be utilized within a network.
Next, Section 6 discusses the key architectural principles of service Next, Section 5 discusses the key architectural principles of service
identification, and how explicit service identifiers can lead to identification. Section 6 describes how explicit service identifiers
fraud, interoperability failures, and stifling of service innovation. can lead to fraud, interoperability failures, and stifling of service
innovation.
2. Terminology
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 [1].
3. Services and Service Identification 2. Services and Service Identification
The problem of identifying services within SIP is not a new one. The The problem of identifying services within SIP is not a new one. The
problem has been considered extensively in the context of presence. problem has been considered extensively in the context of presence.
In particular, the presence data model for SIP [3] defines the In particular, the presence data model for SIP [RFC4479] defines the
concept of a service as one of the core notions that presence concept of a service as one of the core notions that presence
describes. Services are described in Section 3.3 of RFC 4479, which describes. Services are described in Section 3.3 of RFC 4479.
has this to say on the topic:
3.3. Service
Each presentity has access to a number of services. Each of these
represents a point of reachability for communications that can be
used to interact with the user. Examples of services are telephony
(that is, traditional circuit-based telephone service), push-to-talk,
instant messaging, Short Message Service (SMS), and Multimedia
Message Service (MMS).
It is difficult to give a precise definition for service. One
reasonable approach is to model each software or hardware agent in
the system as a service. If a user starts a softphone application on
their PC, then that represents a service. If a user has a videophone
device, then that represents another service. This is effectively a
physical view of services. This definition, however, starts to fall
apart when a service is spread across multiple software agents or
devices. For example, a SIP URI representing an address-of-record
can be routed to a softphone or a videophone, or both. In that case,
one might attempt instead to define a service based on its address on
the network. This definition also falls apart when modeling devices
or applications that receive calls and dispatch them to different
"helpers" based on potentially complex logic. For example, a
cellular telephone might house multiple SIP applications, each of
which can "register" different handlers based on the method or even
body type of the request. Each of those applications or handlers can
rightfully be considered a service, but it doesn't have an address on
the network distinct from the others.
Because of this inherent difficulty in precisely defining a service,
the data model doesn't try to constrain what can be considered a
service. Rather, anything can be considered a service so long as it
exhibits a set of key properties defined by this model. In
particular, each service is associated with characteristics that
identify the nature and capabilities of that service, with reach
information that indicates how to connect to the service, with status
information representing the state of that service, and relative
information that describes the ways in which that service relates to
others associated with the presentity.
As a consequence, in this model, services are not explicitly
enumerated. There is no central registry where one finds identifiers
for each service. Consequently, each service does not have a single
"service" attribute with values such as "ptt" or "telephony". That
doesn't mean that these consolidated monikers aren't useful; indeed,
they represent an essential summary of what the service is. Such
summarization is useful in creating icons that allow a user to choose
one service over another. A watcher is free to create such
summarization information from any of the information associated with
a service. The reach information often provides valuable information
for creating such a summarization. Oftentimes, the scheme of the URI
is synonymous with the view of what a service is. An "sms" URI [14]
clearly indicates SMS, for example. For some URIs, there may be many
services available, for example, SIP or tel [15], in which case the
scheme is less meaningful as a way of creating a summary. The reach
information could also indicate that certain application software has
to be invoked (such as a videogame), in which case that aspect of the
reach information would be useful for generating an iconic
representation of the game.
Essentially, the service is the user-visible use case that is driving Essentially, the service is the user-visible use case that is driving
the behavior of the user-agents and servers in the SIP network. the behavior of the user-agents and servers in the SIP network.
Being user-visible means that there is a difference in user Being user-visible means that there is a difference in user
experience between two services that are different. That user experience between two services that are different. That user
experience can be part of the call, or outside of the call. Within a experience can be part of the call, or outside of the call. Within a
call, the user experience can be based on different media types (an call, the user experience can be based on different media types (an
audio call vs. a video chat), different content within a particular audio call vs. a video chat), different content within a particular
media type (stored content, such as a movie or TV session), different media type (stored content, such as a movie or TV session), different
devices (a wireless device for "telephony" vs. a PC application for devices (a wireless device for "telephony" vs. a PC application for
skipping to change at page 6, line 21 skipping to change at page 5, line 7
This leads naturally to the desire to perform service identification. This leads naturally to the desire to perform service identification.
Service identification is defined as the process of (1) determination Service identification is defined as the process of (1) determination
of the underlying service which is driving a particular signaling of the underlying service which is driving a particular signaling
exchange, (2) associating that service with some kind of moniker, and exchange, (2) associating that service with some kind of moniker, and
(3) attaching that moniker to a signaling message (typically a SIP (3) attaching that moniker to a signaling message (typically a SIP
INVITE), and then utilizing it for various purposes within the INVITE), and then utilizing it for various purposes within the
network. Service identification can be done in the endpoints, in network. Service identification can be done in the endpoints, in
which case the UA would insert the moniker directly into the which case the UA would insert the moniker directly into the
signaling message based on its awareness of the service. Or, it can signaling message based on its awareness of the service. Or, it can
be done within a proxy in the network, based on inspection of the SIP be done within a server in the network (such as a proxy), based on
message, or based on hints placed into the message by the user. inspection of the SIP message, or based on hints placed into the
message by the user.
4. Example Services 3. Example Services
It is very useful to consider several example services, especially It is very useful to consider several example services, especially
ones that appear difficult to differentiate from each other. ones that appear difficult to differentiate from each other.
4.1. IPTV vs. Multimedia 3.1. IPTV vs. Multimedia
IP Television (IPTV) is the usage of IP networks to access IP Television (IPTV) is the usage of IP networks to access
traditional television content, such as movies and shows. SIP can be traditional television content, such as movies and shows. SIP can be
utilized to establish a session to a media server in a network, which utilized to establish a session to a media server in a network, which
then serves up multimedia content and streams it as an audio and then serves up multimedia content and streams it as an audio and
video stream towards the client. Whether SIP is ideal for IPTV is, video stream towards the client. Whether SIP is ideal for IPTV is,
in itself, a good question. However, such a discussion is outside in itself, a good question. However, such a discussion is outside
the scope of this document. the scope of this document.
Consider multimedia conferencing. The user accesses a voice and Consider multimedia conferencing. The user accesses a voice and
video conference at a conference server. The user might join in video conference at a conference server. The user might join in
listen-only mode, in which case the user receives audio and video listen-only mode, in which case the user receives audio and video
streams, but does not send. streams, but does not send.
These two services - IPTV and multimedia conferencing, clearly appear These two services - IPTV and listen-only multimedia conferencing,
as different services. They have different user experiences and clearly appear as different services. They have different user
applications. A user is unlikely to ever be confused about whether a experiences and applications. A user is unlikely to ever be confused
session is IPTV or multimedia conferencing. Indeed, they are likely about whether a session is IPTV or listen-only multimedia
to have different software applications or endpoints for the two conferencing. Indeed, they are likely to have different software
services. applications or endpoints for the two services.
However, these two services look remarkably alike based on the However, these two services look remarkably alike based on the
signaling. Both utilize audio and video. Both could utilize the signaling. Both utilize audio and video. Both could utilize the
same codecs. Both are unidirectional streams (from a server in the same codecs. Both are unidirectional streams (from a server in the
network to the client). Thus, it would appear on the surface that network to the client). Thus, it would appear on the surface that
there is no way to differentiate them, based on inspection of the there is no way to differentiate them, based on inspection of the
signaling alone. signaling alone.
4.2. Gaming vs. Voice Chat 3.2. Gaming vs. Voice Chat
Consider an interactive game, played between two users from their Consider an interactive game, played between two users from their
mobile devices. The game involves the users sending each other game mobile devices. The game involves the users sending each other game
moves, using a messaging channel, in addition to voice. In another moves, using a messaging channel, in addition to voice. In another
service, users have a voice and IM chat conversation using a buddy service, users have a voice and IM chat conversation using a buddy
list application on their PC. list application on their PC.
In both services, there are two media streams - audio and messaging. In both services, there are two media streams - audio and messaging.
The audio uses the same codecs. Both use the Message Session Relay The audio uses the same codecs. Both use the Message Session Relay
Protocol (MSRP) [5]. In both cases, the caller would send an INVITE Protocol (MSRP) [RFC4975]. In both cases, the caller would send an
to the AOR of the target user. However, these represent fairly INVITE to the Address of Record (AOR) of the target user. However,
different services, in terms of user experience. these represent fairly different services, in terms of user
experience.
4.3. Configuration vs. Pager Messaging 3.3. Configuration vs. Pager Messaging
The SIP MESSAGE method [8] provides a way to send one-shot messages The SIP MESSAGE method [RFC3428] provides a way to send one-shot
to a particular AOR. This specification is primarily aimed at Short messages to a particular AOR. This specification is primarily aimed
Message Service (SMS) style messaging, commonly found in wireless at Short Message Service (SMS) style messaging, commonly found in
phones. Receipt of a MESSAGE request would cause the messaging wireless phones. Receipt of a MESSAGE request would cause the
application on a phone to launch, allowing the user to browse message messaging application on a phone to launch, allowing the user to
history and respond. browse message history and respond.
However, MESSAGE is sometimes used for the delivery of content to a However, MESSAGE is sometimes used for the delivery of content to a
device for other purposes. For example, some providers use it to device for other purposes. For example, some providers use it to
deliver configuration updates, such as new phone settings or deliver configuration updates, such as new phone settings or
parameters, or to indicate that a new version of firmware is parameters, or to indicate that a new version of firmware is
available. Though not designed for this purpose, MESSAGE gets used available. Though not designed for this purpose, MESSAGE gets used
since, in existing wireless networks, SMS are used for this purpose, since, in existing wireless networks, SMS is used for this purpose,
and MESSAGE is the SIP equivalent of SMS. and MESSAGE is the SIP equivalent of SMS.
Consequently, the MESSAGE request sent to a phone can be for two Consequently, the MESSAGE request sent to a phone can be for two
different services. One would require invocation of a messaging app, different services. One would require invocation of a messaging app,
whereas the other would be consumed by the software in the phone, whereas the other would be consumed by the software in the phone,
without any user interaction at all. without any user interaction at all.
5. Using Service Identification 4. Using Service Identification
It is important to understand what the service identity would be It is important to understand what the service identity would be
utilized for, if known. The discussions in Section 4 give some hints utilized for, if known. This section discusses the primary uses.
to the possible usages. Here, we explicitly discuss them. These are application invocation in user agents and the network,
Quality of Service authorization, service authorization, accounting
and billing, service negotiation, and device dispatch.
5.1. Application Invocation in the User Agent 4.1. Application Invocation in the User Agent
In some of the examples above, there were multiple software In some of the examples above, there were multiple software
applications running within a single user agent. When an incoming applications executing on the host. One common way of achieving this
INVITE or MESSAGE arrives, it must be delivered to the appropriate is to utilize a common SIP user agent implementation that listens for
application software. When each service is bound to a distinct requests on a single port. When an incoming INVITE or MESSAGE
software application, it would seem that the service identity is arrives, it must be delivered to the appropriate application
needed to dispatch the message to the appropriate piece of software. software. When each service is bound to a distinct software
This is shown in Figure 2. 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 | | | | UI | | UI | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| | | | | | | | | | | |
| | Service 1 | | Service 2 | | | | Service 1 | | Service 2 | |
| | | | | | | | | | | |
skipping to change at page 8, line 37 skipping to change at page 7, line 29
| | | | | | | |
| | SIP | | | | SIP | |
| | Layer | | | | Layer | |
| | | | | | | |
| +-----------------------------+ | | +-----------------------------+ |
| | | |
+---------------------------------+ +---------------------------------+
Physical Device Physical Device
Figure 2 Figure 1
The role of the SIP layer is to parse incoming messages, handle the The role of the SIP layer is to parse incoming messages, handle the
SIP state machinery for transactions and dialogs, and then dispatch SIP state machinery for transactions and dialogs, and then dispatch
request to the appropriate service. For the example services in request to the appropriate service. This software architecture is
Section 4.2, an incoming INVITE for the gaming service would be analagous to the way web servers frequently work. An HTTP server
delivered to the gaming application software. An incoming INVITE for listens on port 80 for requests, and based on the HTTP Request-URI,
the voice chat service would be delivered to the voice chat dispatches the request to a number of disparate applications. The
application software. For the examples in Section 4.3, a MESSAGE same is happening here. For the example services in Section 3.2, an
request for user to user messaging would be delivered to the incoming INVITE for the gaming service would be delivered to the
messaging or SMS app, and a MESSAGE request containing configuration gaming application software. An incoming INVITE for the voice chat
data would be delivered to a configuration update application. service would be delivered to the voice chat application software.
For the examples in Section 3.3, 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.
5.2. Application Invocation in the Network Unlike the web, however, in all three use cases, the user initiating
communications has 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
Another usage of a service identifier would be to cause servers in Another usage of a service identifier would be to cause servers in
the SIP network to provide additional processing, based on the the SIP network to provide additional processing, based on the
service. For example, an INVITE issued by a user agent for IPTV service. For example, an INVITE issued by a user agent for IPTV
would pass through a server that does some kind of content rights would pass through a server that does some kind of content rights
management, authorizing whether the user is allowed to access that management, authorizing whether the user is allowed to access that
content. On the other hand, an INVITE issued by a user for content. On the other hand, an INVITE issued by a user for
multimedia conferencing would pass through a server providing multimedia conferencing would pass through a server providing
"traditional" telephony features, such as outbound call screening and "traditional" telephony features, such as outbound call screening and
call recording. It would make no sense for the INVITE associated call recording. It would make no sense for the INVITE associated
with IPTV to have outbound call screening and call recording applied, with IPTV to have outbound call screening and call recording applied,
and it would make no sense for the multimedia conferencing INVITE to and it would make no sense for the multimedia conferencing INVITE to
be processed by the content rights management server. Indeed, in be processed by the content rights management server. Indeed, in
these cases, its not just an efficiency issue (invoking servers when these cases, it's not just an efficiency issue (invoking servers when
not needed), but rather, truly incorrect behavior can occur. For not needed), but rather, truly incorrect behavior can occur. For
example, if an outbound call screening application is set to block example, if an outbound call screening application is set to block
outbound calls to everything except for the phone numbers of friends outbound calls to everything except for the phone numbers of friends
and family, an IPTV request that gets processed by such a server and family, an IPTV request that gets processed by such a server
would be blocked (as its not targeted to the AOR of a friend or would be blocked (as it's not targeted to the AOR of a friend or
family member). This would block a user's attempt to access IPTV family member). This would block a user's attempt to access IPTV
services, when that was not the goal at all. services, when that was not the goal at all.
Similarly, a MESSAGE request from Section 4.3 might need to pass Similarly, a MESSAGE request from Section 3.3 might need to pass
through a message server for filtering when it is associated with through a message server for filtering when it is associated with
chat, but not when it is associated with config. Consider a filter chat, but not when it is associated with config. Consider a filter
which gets applied to MESSAGE requests, and that filter runs in a which gets applied to MESSAGE requests, and that filter runs in a
server in the network. The filter operation prevents user Joe from server in the network. The filter operation prevents user Joe from
sending messages to user Bob that contain the words "stock" or sending messages to user Bob that contain the words "stock" or
"purchase", due to some regulations that disallow Joe and Bob from "purchase", due to some regulations that disallow Joe and Bob from
discussing stock trading. However, a MESSAGE for configuration discussing stock trading. However, a MESSAGE for configuration
purposes might contain an XML document that uses the token "stock" as purposes might contain an XML document that uses the token "stock" as
some kind of attribute. This configuration update would be discarded some kind of attribute. This configuration update would be discarded
by the filtering server, when it should not have been. by the filtering server, when it should not have been.
5.3. Network Quality of Service Authorization 4.3. Network Quality of Service Authorization
The IP network can provide differing levels of Quality of Service The IP network can provide differing levels of Quality of Service
(QoS) to IP packets. This service can include guaranteed throughput, (QoS) to IP packets. This service can include guaranteed throughput,
latency, or loss characteristics. Typically, the user agent will latency, or loss characteristics. Typically, the user agent will
make some kind of QoS request, either using explicit signaling make some kind of QoS request, either using explicit signaling
protocols (such as RSVP) or through marking of Diffserv value in protocols (such as RSVP) or through marking of Diffserv value in
packets. The network will need to make a policy decision based on packets. The network will need to make a policy decision based on
whether these QoS treatments are authorized or not. One common whether these QoS treatments are authorized or not. One common
authorization policy is to check if the user has invoked a service authorization policy is to check if the user has invoked a service
using SIP that they are authorized to invoke, and that this service using SIP that they are authorized to invoke, and that this service
requires the level of QoS treatment the user has requested. requires the level of QoS treatment the user has requested.
For example, consider IPTV and multimedia conferencing as described For example, consider IPTV and multimedia conferencing as described
in Section 4.1. IPTV is a non-real time service. Consequently, in Section 3.1. IPTV is a non-real time service. Consequently,
media traffic for IPTV would be authorized for bandwidth guarantees, media traffic for IPTV would be authorized for bandwidth guarantees,
but not for latency or loss guarantees. On the other hand, but not for latency or loss guarantees. On the other hand,
multimedia conferencing is real time. Its traffic would require multimedia conferencing is real time. Its traffic would require
bandwidth, loss and latency guarantees from the network. bandwidth, loss and latency guarantees from the network.
Consequently, if a user should make an RSVP reservation for a media Consequently, if a user should make an RSVP reservation for a media
stream, and ask for latency guarantees for that stream, the network stream, and ask for latency guarantees for that stream, the network
would like to be able to authorize it if the service was multimedia would like to be able to authorize it if the service was multimedia
conferencing, but not if it was IPTV. This would require the server conferencing, but not if it was IPTV. This would require the server
performing the QoS authorization to know the service associated with performing the QoS authorization to know the service associated with
the INVITE that set up the session. the INVITE that set up the session.
5.4. Service Authorization 4.4. Service Authorization
Frequently, a network administrator will want to authorize whether a Frequently, a network administrator will want to authorize whether a
user is allowed to invoke a particular service. Not all users will user is allowed to invoke a particular service. Not all users will
be authorized to use all services that are provided. For example, a be authorized to use all services that are provided. For example, a
user may not be authorized to access IPTV services, whereas they are user may not be authorized to access IPTV services, whereas they are
authorized to utilize multimedia processing. A user might not be authorized to utilize multimedia processing. A user might not be
able to utilize a multiplayer gaming service, whereas they are able to utilize a multiplayer gaming service, whereas they are
authorized to utilize voice chat services. authorized to utilize voice chat services.
Consequently, when an INVITE arrives at a proxy in the network, the Consequently, when an INVITE arrives at a server in the network, the
proxy will need to determine what the requested service is, so that server will need to determine what the requested service is, so that
the proxy can make an authorization decision. the server can make an authorization decision.
5.5. Accounting and Billing 4.5. Accounting and Billing
Service authorization and accounting/billing go hand in hand. Service authorization and accounting/billing go hand in hand. One of
Presumably, one of the primary reasons for authorizing that a user the primary reasons for authorizing that a user can utilize a service
can utilize a service is that they are being billed differently based is that they are being billed differently based on the type of
on the type of service. Consequently, one of the goals of a service service. Consequently, one of the goals of a service identity is to
identity is to be able to include it in accounting records, so that be able to include it in accounting records, so that the appropriate
the appropriate billing model can be applied. billing model can be applied.
For example, in the case of IPTV, a service provider can bill based For example, in the case of IPTV, a service provider can bill based
on the content (US $5 per movie, perhaps), whereas for multimedia on the content (US $5 per movie, perhaps), whereas for multimedia
conferencing, they can bill by the minute. This requires the conferencing, they can bill by the minute. This requires the
accounting streams to indicate which service was invoked for the accounting streams to indicate which service was invoked for the
particular session. particular session.
5.6. Negotiation of Service 4.6. Negotiation of Service
In some cases, when the caller initiates a session, they don't In some cases, when the caller initiates a session, they don't
actually know which service will be utilized. Rather, they might actually know which service will be utilized. Rather, they might
like to offer up all of the services they have available to the like to offer up all of the services they have available to the
called party, and then let the called party decide, or let the system called party, and then let the called party decide, or let the system
make a decision based on overlapping service capabilities. make a decision based on overlapping service capabilities.
As an example, s user can do both the game and the voice chat service As an example, a user can do both the game and the voice chat service
of Section 4.2. They initiate a session to a target AOR, but the of Section 3.2. They initiate a session to a target AOR, but the
devices used by that user can only support voice chat. Consequently, devices used by that user can only support voice chat. The called
voice chat gets utilized for the session. device returns, in its call acceptance, an indication that only voice
chat can be used. Consequently, voice chat gets utilized for the
session.
5.7. Dispatch to Devices 4.7. Dispatch to Devices
When a user has multiple devices, each with varying capabilities in When a user has multiple devices, each with varying capabilities in
terms of service, it is useful to dispatch an incoming request to the terms of service, it is useful to dispatch an incoming request to the
right device based on whether the device can support the service that right device based on whether the device can support the service that
has been requested. has been requested.
For example, if a user initiates a gaming session with voice chat, For example, if a user initiates a gaming session with voice chat,
and the target user has two devices - one that can support the gaming and the target user has two devices - one that can support the gaming
service, and the other that cannot, the INVITE should be dispatched service, and the other that cannot, the INVITE should be dispatched
to the device which supports the gaming session. to the device which supports the gaming session.
6. Key Principles of Service Identification 5. Key Principles of Service Identification
In this section, we describe some of the key principles of performing In this section, we describe three key principles of service
service identification. identification:
6.1. Services are a By-Product of Signaling 1. Services are a by-product of signaling
2. Identical signaling produces identical services
3. Explicit service identifiers are an example of Do-What-I-Mean
(DWIM)
4. Explicit service identifiers are redundant
5.1. Services are a By-Product of Signaling
Almost always, the first solution that people consider is to add some Almost always, the first solution that people consider is to add some
kind of field to the signaling messages which indicates what the kind of field to the signaling messages which indicates what the
service is. This field would then be inserted by the user agent, and service is. This field would then be inserted by the user agent, and
then can be used by the proxies and other user agent as a service then can be used by the proxies and other user agent as a service
identifier. identifier.
This approach, however, misses a key point, which cannot be stressed This approach, however, misses a key point, which cannot be stressed
enough, and which represents the core architectural principle to be enough, and which represents the core architectural principle to be
understood here: understood here:
skipping to change at page 12, line 9 skipping to change at page 11, line 20
When a user sends an INVITE request to the network, and targets that When a user sends an INVITE request to the network, and targets that
request at an IPTV server, and includes SDP for audio and video request at an IPTV server, and includes SDP for audio and video
streaming, the *result* of sending such an INVITE is that an IPTV streaming, the *result* of sending such an INVITE is that an IPTV
session occurs. The entire purpose of the INVITE is to establish session occurs. The entire purpose of the INVITE is to establish
such a session, and therefore, invoke the service. Thus, a service such a session, and therefore, invoke the service. Thus, a service
is not something that is different from the rest of the signaling is not something that is different from the rest of the signaling
message. A service is what the user gets after the network and other message. A service is what the user gets after the network and other
user agents have processed a signaling message. user agents have processed a signaling message.
This principle leads to another important conclusion: 5.2. Identical Signaling Produces Identical Services
This principle is a natural conclusion of the previous assertion. If
a service is the byproduct of signaling, how can a user have
different experiences and different services when the signaling
message is the same? They cannot.
But how can that be? From the examples in Section 3, it would seem
that there are services which are different, but have identical
signaling. If we hold true to the assertion, there is in fact only
one logical conclusion:
If two services are different, but their signaling appears to be If two services are different, but their signaling appears to be
the same, it is because there is in fact something different that the same, it is because there is in fact something different that
has been overlooked, or something has been implied from the has been overlooked, or something has been implied from the
signaling which should have been signaled explicitly. signaling which should have been signaled explicitly.
This makes sense; if a service is the byproduct of signaling, how can
a user have different experiences and different services when the
signaling message is the same? There has to be something different
in the messages, if the user experience was in fact different.
To illustrate this, let us take each of the example services in To illustrate this, let us take each of the example services in
Section 4 and investigate whether there is, or should be, something Section 3 and investigate whether there is, or should be, something
different in the signaling in each case. different in the signaling in each case.
IPTV vs. Multimedia Conferencing: The two services in Section 4.1 IPTV vs. Multimedia Conferencing: The two services in Section 3.1
appear to have identical signaling. They both involve audio and appear to have identical signaling. They both involve audio and
video streams, both of which are unidirectional. Both might video streams, both of which are unidirectional. Both might
utilize the same codecs. However, there is another important utilize the same codecs. However, there is another important
difference in the signaling - the target URI. In the case of difference in the signaling - the target URI. In the case of
IPTV, the request is targeted at a media server or to a particular IPTV, the request is targeted at a media server or to a particular
piece of content to be viewed. In the case of multimedia piece of content to be viewed. In the case of multimedia
conferencing, the target is a conference server. The conferencing, the target is a conference server. The
administrator of the domain can therefore examine the two Request- administrator of the domain can therefore examine the two Request-
URI, and figure out whether it is targeted for a conference server URI, and figure out whether it is targeted for a conference server
or a content server, and use that to derive the service associated or a content server, and use that to derive the service associated
skipping to change at page 13, line 9 skipping to change at page 12, line 21
content type that MSRP is carrying, and this type will differ in content type that MSRP is carrying, and this type will differ in
both cases. Even if the game moves look like text, since they are both cases. Even if the game moves look like text, since they are
being consumed by an automata there is an underlying schema that being consumed by an automata there is an underlying schema that
dictates their content, and therefore, this schema represents the dictates their content, and therefore, this schema represents the
actual content type that should be signaled. actual content type that should be signaled.
Configuration vs. Pager Messaging: Just as in the case of gaming vs. Configuration vs. Pager Messaging: Just as in the case of gaming vs.
voice chat, the content type of the messages differentiates the voice chat, the content type of the messages differentiates the
service that occurs as a consequence of the messages. service that occurs as a consequence of the messages.
This is ultimately an expression of the principle of DWIM vs. DWIS 5.3. Do What I Say, not What I Mean
(Do-What-I-Mean vs. Do-What-I-Say). Explicit signaling is DWIS - the
user is asking for a service by invoking the signaling that results
in the desired effect. A service identifier is DWIM - an unspecific
request for something that is ill-defined and non-interoperable.
6.2. Perils of Explicit Identifiers An explicit service identifier is a field included in the signaling
message that contains a token whose value indicates the specific
service invoked by the calling user. This would be "IPTV" or "voice
chat" or "shoot-em game" or "short message service". This explicit
identifier would typically be inserted by the originating user agent,
and carried in the signaling message.
Given that the information in the signaling message always conveys "Do What I Mean", abbreviated as DWIM, is a concept in computer
enough information to identify the service, another important science. It is sometimes used to describe a function which tries to
conclusion can be drawn: intelligently guess at what the user intended. It is contrast to "Do
What I Say", or DWIS, which describes a function that behaves
concretely based on the inputs provided. Systems built on the DWIM
concept can have unexpected behaviors because they are driven by
unstated rules.
Inclusion of an explicit service identifier within a message is, An explicit service identifier is an example of a DWIM approach. An
at best, redundant, and at worst, an avenue for fraud, loss of explicit service identifier itself has no well-defined impact on the
interoperability, and stifling of service innovation. state machinery or protocols in the system; it has various side-
effects based on an assumption of what is meant by the service
identifier. Interpretation of the signaling directly is an
expression of the principle of DWIS - the behavior of the system is
based entirely on the specifics of the protocol and are well defined
by the protocol specification.
By "explicit service identifier", we mean a field included in the 5.4. Explicit Service Identifiers are Redundant
signaling message that contains a token whose value indicates the
specific service invoked by the calling user. This would be "IPTV"
or "voice chat" or "shoot-em game" or "short message service". This
explicit identifier would typically be inserted by the originating
user agent, and carried in the signaling message.
Clearly, if the signaling message itself contains enough information Because an explicit service identifier is, by definition, inside of
to identify the service, inclusion of an extra field to say the same the signaling message, and because the signaling itself completely
thing is going to be redundant. Redundancy by itself is not a big defines the behavior of the service, another natural conclusion is
deal. However, redundancy can lead to other,more significant that an explicit service identifier is redundant with the signaling
problems. itself. It says nothing that could not otherwise be derived from
examination of the signaling.
6.2.1. Fraud 6. Perils of Explicit Identifiers
First and foremost, it can lead to fraud. If a provider uses the Based on these principles, several perils of an explicit service
service identifier for billing and accounting purposes, or for identifier can be described. They are:
1. Explicit identifiers can be used for fraud
2. Explicit identifiers can hurt interoperability
3. Explicit identifiers can stifle service innovation
6.1. Fraud
Explicit service identifiers can lead to fraud. 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 authorization purposes, it opens an avenue for attack. The user can
construct the signaling message so that its actual effect (which is construct the signaling message so that its actual effect (which is
the service the user will receive), is what the user desires, but the the service the user will receive), is what the user desires, but the
service identity (which is what is used for billing and user places a service identifier into the request (which is what is
authorization) doesn't match, and indicates a cheaper service, or one used for billing and authorization) that identifies a cheaper
that the user is authorized to receive. If, however, the service service, or one that the user is authorized to receive. In such a
identity used by the domain admistrator is derived from the signaling case, the user will be billed for something they did not receive.
itself, the user cannot lie. If they did lie, they wouldn't get the
desired service. If, however, the domain administrator derived the service identifier
from the signaling itself, the user cannot lie. If they did lie,
they wouldn't get the desired service.
Consider the example of IPTV vs. multimedia conferencing. If Consider the example of IPTV vs. multimedia conferencing. If
multimedia conferencing is cheaper, the user could send an INVITE for multimedia conferencing is cheaper, the user could send an INVITE for
an IPTV session, but include a service identifier which indicates an IPTV session, but include a service identifier which indicates
multimedia conferencing. They get the service associated with IPTV, multimedia conferencing. The user gets the service associated with
but at the cost of multimedia conferencing. IPTV, but at the cost of multimedia conferencing.
This same principle shows up in other places. For example, in the This same principle shows up in other places. For example, in the
identification of an emergency services call [6]. It is desirable to identification of an emergency services call
give emergency services calls special treatment, such as being free, [I-D.ietf-ecrit-framework]. It is desirable to give emergency
authorized even when the user cannot otherwise make calls, and to services calls special treatment, such as being free, authorized even
give them priority. If emergency calls where indicated through when the user cannot otherwise make calls, and to give them priority.
something other than the target of the call being an emergency If emergency calls where indicated through something other than the
services URN [7], it would open an avenue for fraud. The user could target of the call being an emergency services URN [RFC5031], it
place any desired URI in the request-URI, and indicate that the call would open an avenue for fraud. The user could place any desired URI
is an emergency services call. This could would then get special in the request-URI, and indicate that the call is an emergency
treatment, but of course get routed to the target URI. The only way services call. This could would then get special treatment, but of
to prevent this fraud is to consider an emergency call as any call course get routed to the target URI. The only way to prevent this
whose target is an emergency services URN. Thus, the service fraud is to consider an emergency call as any call whose target is an
identification here is based on the target of the request. When the emergency services URN. Thus, the service identification here is
target is an emergency services URN, the request can get special based on the target of the request. When the target is an emergency
treatment. The user cannot lie, since there is no way to separately services URN, the request can get special treatment. The user cannot
indicate this is an emergency call, besides targeting it to an lie, since there is no way to separately indicate this is an
emergency URN. emergency call, besides targeting it to an emergency URN.
6.2.2. Systematic Interoperability Failures 6.2. Systematic Interoperability Failures
How can inclusion of an explicit service identifier cause loss of How can inclusion of an explicit service identifier cause loss of
interoperability? When such an identifier is used to drive interoperability? When such an identifier is used to drive
functionality - such as dispatch on the phones, in the network, or functionality - such as dispatch on the phones, in the network, or
QoS authorization, it means that the wrong thing can happen when this QoS authorization, it means that the wrong thing can happen when this
field is not set properly. Consider a user in domain 1, calling a field is not set properly. Consider a user in domain 1, calling a
user in domain 2. Domain 1 provides the user with a service they user in domain 2. Domain 1 provides the user with a service they
call "voice chat", which utilizes voice and IM for real time call "voice chat", which utilizes voice and IM for real time
conversation, driven off of a buddy list application on a PC. Domain conversation, driven off of a buddy list application on a PC. Domain
2 provides their users with a service they call, "text telephony", 2 provides their users with a service they call, "text telephony",
which is a voice service on a wireless device that also allows the which is a voice service on a wireless device that also allows the
user to send text messages. Consider the case where domain 1 and user to send text messages. Consider the case where domain 1 and
domain 2 both have their user agents insert a service identifiers domain 2 both have their user agents insert a service identifiers
into the request, and then use that to derive QoS authorization, into the request, and then use that to derive QoS authorization,
accounting, and invocation of applications in the network and in the accounting, and invocation of applications in the network and in the
device. The user in domain 1 calls the user in domain 2, and inserts device. The user in domain 1 calls the user in domain 2, and inserts
the identifier "Voice Chat" into the INVITE. When this arrives at the identifier "Voice Chat" into the INVITE. When this arrives at
the proxy in domain 2, the service is unknown. Consequently, the the server in domain 2, the service identifier is unknown.
request does not get the proper QoS treatment. When it gets Consequently, the request does not get the proper QoS treatment, even
delivered to the User Agent of the user in domain 2, the user agent if the call itself will succeed.
does not see a service it understands, and so consequently, does not
know to dispatch the request to the right application software.
Thus, this call has completely failed, even when it could have
succeeded. This illustrates the following key point:
Explicit service identifiers, used between domains, cause Explicit service identifiers, used between domains, cause
interoperability failures unless all interconnected domains agree interoperability failures unless all interconnected domains agree on
on exactly the same set of services and how to name them. exactly the same set of services and how to name them. Of course,
lack of service identifiers does not guarantee service
Of course, lack of service identifiers does not guarantee service
interoperability. However, SIP was built with rich tools for interoperability. However, SIP was built with rich tools for
negotiation of capabilities at a finely granular level. One user negotiation of capabilities at a finely granular level. One user
agent can make a call using audio and video, but if the receiving UA agent can make a call using audio and video, but if the receiving UA
only supports audio, SIP allows both sides to negotiate down to the only supports audio, SIP allows both sides to negotiate down to the
lowest common denominator. Thus, communications is still provided. lowest common denominator. Thus, communications is still provided.
As another example, if one agent initiates a Push-To-Talk session As another example, if one agent initiates a Push-To-Talk session
(which is audio with a companion floor control mechanism), and the (which is audio with a companion floor control mechanism), and the
other side only did regular audio, SIP would be able to negotiate other side only did regular audio, SIP would be able to negotiate
back down to a regular voice call. As another example, if a calling back down to a regular voice call. As another example, if a calling
user agent is running a high-definition video conferencing endpoint, user agent is running a high-definition video conferencing endpoint,
and the called user agent supports just a regular video endpoint, the and the called user agent supports just a regular video endpoint, the
codecs themselves can negotiate downward to a lower rate, picture codecs themselves can negotiate downward to a lower rate, picture
size, and so on. Thus, interoperability is achieved. Interestingly, size, and so on. Thus, interoperability is achieved. Interestingly,
the final "service" may no longer be well characterized by the the final "service" may no longer be well characterized by the
service identifier that would have been placed in the original service identifier that would have been placed in the original
INVITE. For example, in this case, of the original INVITE from the INVITE. For example, in this case, of the original INVITE from the
caller had contained the service identifier, "hi-fi video", but the caller had contained the service identifier, "hi-fi video", but the
video gets negotiated down to a lower rate and picture size, the video gets negotiated down to a lower rate and picture size, the
service identifier is no longer really appropriate. service identifier is no longer really appropriate.
This illustrates another key aspect of the interoperability problem: This illustrates another key aspect of the interoperability problem.
Usage of explicit service identifiers in the request will result in
Usage of explicit service identifiers in the request will result inconsistencies between those service identifiers and the results of
in inconsistencies with results of any SIP negotiation that might any SIP negotiation that might otherwise be applied in the session.
otherwise be applied in the session.
Of course, there are cases where negotiating to a common baseline is
not what is desired. SIP provides tools (such as Require), to force
the call to fail unless the desired capabilities are supported.
However, this is not recommended as a general rule [4].
When a service identifier becomes something that both proxies and the When a service identifier becomes something that both proxies and the
user agent need to understand in order to properly treat a request, user agent need to understand in order to properly treat a request,
it becomes equivalent to including a token in the Proxy-Require and it becomes equivalent to including a token in the Proxy-Require and
Require header fields of every single SIP request. The very reason Require header fields of every single SIP request. The very reason
that RFC 4485 frowns upon usage of Require and certainly Proxy- that [RFC4485] frowns upon usage of Require and certainly Proxy-
Require is the huge impact on interoperability it causes. It is for Require is the huge impact on interoperability it causes. It is for
this same reason that explicit service identifiers need to be this same reason that explicit service identifiers need to be
avoided: avoided.
The usage of explicit service identifiers is equivalent to the
usage of Require and Proxy-Require in the request, and has the
same negative impact on interoperability as those headers have.
6.2.3. Stifling of Service Innovation 6.3. Stifling of Service Innovation
The probability that any two pair of service providers end up with The probability that any two pair of service providers end up with
the same set of services, and give them the same names, becomes the same set of services, and give them the same names, becomes
decreasingly small as the number of providers grow. Indeed, it would decreasingly small as the number of providers grow. Indeed, it would
almost certainly require a centralized authority to identify what the almost certainly require a centralized authority to identify what the
services are, how they work, and what they are named. This, in turn, services are, how they work, and what they are named. This, in turn,
leads to a requirement for complete homogeneity in order to leads to a requirement for complete homogeneity in order to
facilitate interconnection. Two providers cannot usefully facilitate interconnection. Two providers cannot usefully
interconnect unless they agree on the set of services they are interconnect unless they agree on the set of services they are
offering to their customers, and each do the same thing. This is, in offering to their customers, and each do the same thing. This is
a very real sense, anathema to the entire notion of SIP, which is because each provider has become dependent on inclusion of the proper
built on the idea that heterogeneous domains can interconnect and service identifier in the request, in order for the overall treatment
still get interoperability: of the request to proceed correctly. This is, in a very real sense,
anathema to the entire notion of SIP, which is built on the idea that
heterogeneous domains can interconnect and still get
interoperability.
Explicit service identifiers lead to a requirement for homogeneity Explicit service identifiers lead to a requirement for homogeneity in
in service definitions across providers that interconnect, ruining service definitions across providers that interconnect, ruining the
the very service heterogeneity that SIP was meant to bring. very service heterogeneity that SIP was meant to bring.
Indeed, Metcalfe's law says that the value of a network grows with Indeed, Metcalfe's law says that the value of a network grows with
the square of the number of participants. As a consequence of this, the square of the number of participants. As a consequence of this,
once a bunch of large domains did get together, agree on a set of once a bunch of large domains did get together, agree on a set of
services, and then a set of well-known identifiers for those services, and then a set of well-known identifiers for those
services, it would force other providers to also deploy the same services, it would force other providers to also deploy the same
services, in order to obtain the value that interconnection brings. services, in order to obtain the value that interconnection brings.
This, in turn, will stifle innovation, and quickly force the set of This, in turn, will stifle innovation, and quickly force the set of
services in SIP to become fixed and never expand beyond the ones services in SIP to become fixed and never expand beyond the ones
initially agreed upon. This, too, is anathema to the very framework initially agreed upon. This, too, is anathema to the very framework
on which SIP is built, and defeats much of the purpose of why on which SIP is built, and defeats much of the purpose of why
providers have chosen to deploy SIP in their own networks: providers have chosen to deploy SIP in their own networks:
Metcalfe's law, when combined with explicit service identifiers,
will stifle the ability of providers to develop new SIP services,
since they have no hope of interconnecting them with anyone else.
Consider the following example. Several providers get together, and Consider the following example. Several providers get together, and
standardize on a bunch of service identifiers. One of these uses standardize on a bunch of service identifiers. One of these uses
audio and video (say, "multimedia conversation"). This service is audio and video (say, "multimedia conversation"). This service is
successful, and is widely utilized. Endpoints look for this successful, and is widely utilized. Endpoints look for this
identifier to dispatch calls to the right software applications, and identifier to dispatch calls to the right software applications, and
the network looks for it to invoke features, perform accouting, and the network looks for it to invoke features, perform accouting, and
QoS. A new provider gets the idea for a new service, say, avatar- QoS. A new provider gets the idea for a new service, say, avatar-
enhanced multimedia conversation. In this service, there is audio enhanced multimedia conversation. In this service, there is audio
and video, but there is a third stream, which renders an avatar. A and video, but there is a third stream, which renders an avatar. A
caller can press buttons on their phone, to cause the avatar on the caller can press buttons on their phone, to cause the avatar on the
skipping to change at page 17, line 34 skipping to change at page 17, line 5
not sufficient to identify the service, it may be due to lack of not sufficient to identify the service, it may be due to lack of
sufficient signaling to convey what is needed, and new standards sufficient signaling to convey what is needed, and new standards
work should be undertaken to fill this gap. work should be undertaken to fill this gap.
o The usage of an explicit service identifier does make sense as a o The usage of an explicit service identifier does make sense as a
way to cache a decision made by a network element, for usage by way to cache a decision made by a network element, for usage by
another network element within the same domain. However, service another network element within the same domain. However, service
identifiers are fundamentally useful within a particular domain, identifiers are fundamentally useful within a particular domain,
and any such header must be stripped at a network boundary. and any such header must be stripped at a network boundary.
o Device dispatch should be done following the principles of
[RFC3841], using implicit preferences based on the signaling. For
example, [I-D.rosenberg-sip-app-media-tag] defines a new UA
capability that can be used to dispatch requests based on
different types of application media streams.
o Presence can help a great deal with service indentification. When
a user wishes to contact another user, and knows only the AOR for
the target (which is usually the case), the user can fetch the
presence document for the target. That document, in turn, can
contain numerous service URI for contacting the target with
different services. The usage of different URI for contacting
different services makes it very easy to identify the service -
it's the actual target of the request itself. When possible, this
is the best solution to the problem.
8. Security Considerations 8. Security Considerations
Oftentimes, the service associated with a request is utilized for Oftentimes, the service associated with a request is utilized for
purposes such as authorization, accounting, and billing. When purposes such as authorization, accounting, and billing. When
service identification is not done properly, the possibility of service identification is not done properly, the possibility of
network fraud is introduced. It is for this reason, discussed unauthorized service use and network fraud is introduced. It is for
extensively in Section 6.2.1, that the usage of explicit service this reason, discussed extensively in Section 6.1, that the usage of
identifiers inserted by a UA is NOT RECOMMENDED. explicit service identifiers inserted by a UA is not recommended.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
10. Acknowledgements 10. Acknowledgements
This document is based on discussions with Paul Kyzivat and Andrew This document is based on discussions with Paul Kyzivat and Andrew
Allen, who contributed significantly to the ideas here. Much of the Allen, who contributed significantly to the ideas here. Much of the
content in this draft is a result of discussions amongst participants content in this draft is a result of discussions amongst participants
in the SIPPING mailing list, including Dean Willis, Tom Taylor, Eric in the SIPPING mailing list, including Dean Willis, Tom Taylor, Eric
Burger, Dale Worley, Christer Holmberg, and John Elwell, amongst many Burger, Dale Worley, Christer Holmberg, and John Elwell, amongst many
others. others. Thanks to Spencer Dawkins, Tolga Asveren, Mahesh Anjanappa
and Claudio Allochio for reviews of this document.
11. References
11.1. Normative References 11. Informational References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Levels", BCP 14, RFC 2119, March 1997. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: July 2006.
Session Initiation Protocol", RFC 3261, June 2002.
11.2. Informational References [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006.
[3] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[4] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Extensions to the Session Initiation Protocol (SIP)", RFC 4485, Emergency and Other Well-Known Services", RFC 5031,
May 2006. January 2008.
[5] Campbell, B., "The Message Session Relay Protocol", [I-D.ietf-ecrit-framework]
draft-ietf-simple-message-sessions-19 (work in progress), Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
February 2007. "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-04 (work in
progress), November 2007.
[6] Rosen, B., "Framework for Emergency Calling in Internet [I-D.rosenberg-sip-app-media-tag]
Multimedia", draft-ietf-ecrit-framework-01 (work in progress), Rosenberg, J., "A Session Initiation Protocol (SIP) Media
March 2007. Feature Tag for MIME Application Sub-Types",
draft-rosenberg-sip-app-media-tag-02 (work in progress),
November 2007.
[7] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
draft-ietf-ecrit-service-urn-06 (work in progress), March 2007. and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
D. Gurle, "Session Initiation Protocol (SIP) Extension for Preferences for the Session Initiation Protocol (SIP)",
Instant Messaging", RFC 3428, December 2002. RFC 3841, August 2004.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 87 change blocks. 
318 lines changed or deleted 314 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/