draft-ietf-sipping-service-identification-01.txt   draft-ietf-sipping-service-identification-02.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational February 24, 2008 Intended status: Informational July 14, 2008
Expires: August 27, 2008 Expires: January 15, 2009
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-01 draft-ietf-sipping-service-identification-02
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 35 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 August 27, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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. This document discusses signaling being utilized by the user agent. This document discusses
the uses of service identification, and outlines several the uses of service identification, and outlines several
architectural principles behind the process. It identifies several architectural principles behind the process. It identifies perils
perils associated with service identification, including fraud, when service identification is not done properly - including fraud,
interoperability failures and stifling of innovation. interoperability failures and stifling of innovation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Services and Service Identification . . . . . . . . . . . . . 4 2. Services and Service Identification . . . . . . . . . . . . . 4
3. Example Services . . . . . . . . . . . . . . . . . . . . . . . 5 3. Example Services . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 5 3.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 5
3.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 5 3.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 6
3.3. Configuration vs. Pager Messaging . . . . . . . . . . . . 6 3.3. Gaming vs. Voice Chat #2 . . . . . . . . . . . . . . . . . 6
4. Using Service Identification . . . . . . . . . . . . . . . . . 6 3.4. Configuration vs. Pager Messaging . . . . . . . . . . . . 6
4.1. Application Invocation in the User Agent . . . . . . . . . 6 4. Using Service Identification . . . . . . . . . . . . . . . . . 7
4.2. Application Invocation in the Network . . . . . . . . . . 8 4.1. Application Invocation in the User Agent . . . . . . . . . 7
4.3. Network Quality of Service Authorization . . . . . . . . . 8 4.2. Application Invocation in the Network . . . . . . . . . . 9
4.4. Service Authorization . . . . . . . . . . . . . . . . . . 9 4.3. Network Quality of Service Authorization . . . . . . . . . 9
4.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 9 4.4. Service Authorization . . . . . . . . . . . . . . . . . . 10
4.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 9 4.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 10
4.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 10 4.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 10
5. Key Principles of Service Identification . . . . . . . . . . . 10 4.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 11
5.1. Services are a By-Product of Signaling . . . . . . . . . . 10 5. Key Principles of Service Identification . . . . . . . . . . . 11
5.2. Identical Signaling Produces Identical Services . . . . . 11 5.1. Services are a By-Product of Signaling . . . . . . . . . . 11
5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 12 5.2. Identical Signaling Produces Identical Services . . . . . 12
5.4. Explicit Service Identifiers are Redundant . . . . . . . . 12 5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 14
6. Perils of Explicit Identifiers . . . . . . . . . . . . . . . . 13 5.4. Explicit Service Identifiers are Redundant . . . . . . . . 14
6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. URIs are Key for Differentiated Signaling . . . . . . . . 14
6.2. Systematic Interoperability Failures . . . . . . . . . . . 14 6. Perils of Declarative Service Identification . . . . . . . . . 15
6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 15 6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Systematic Interoperability Failures . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Informational References . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 19 11. Informational References . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] defines mechanisms The Session Initiation Protocol (SIP) [RFC3261] defines mechanisms
for initiating and managing communications sessions between agents. for initiating and managing communications sessions between agents.
SIP 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-
skipping to change at page 3, line 30 skipping to change at page 3, line 30
This breadth of applicability is SIP's 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 Each of these different use cases represents a different service.
designers to seek techniques for service identification. Service The service is the user-visible use case that is driving the behavior
identification is the process of determining and/or signaling the of the user-agents and servers in the SIP network.
specific use case that is driving the signaling being generated by a
user agent. At first glance, this seems harmless and easy enough.
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
which define what the service is. It could then be consumed for any
number of purposes. A service identifier placed into the signaling
is called an explicit service identifier.
Explicit service identifiers have many problems, however. They are The differing services possible with SIP has driven implementors and
redundant with the signaling itself (which is the ultimate expression system designers to seek techniques for service identification.
of the service that is desired), and are an example of Do-What-I-Mean Service identification is the process of determining and/or signaling
(DWIM). Consequently, their usage can lead to fraud, systemic the specific use case that is driving the signaling being generated
interoperability failures, and a complete stifling of the innovation by a user agent. At first glance, this seems harmless and easy
that SIP was meant to achieve. The purpose of this document is to enough. It is tempting to define a new header, "Service-ID", for
describe service identification in more detail and describe how these example, and have a user agent populate it with any number of well-
problems arise. known tokens which define what the service is. It could then be
consumed for any number of purposes. A service identifier placed
into the signaling is called a service identifier.
Service identification and service identifiers, when used properly,
can be beneficial. However, when done improperly, service
identification 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 2 begins by defining a service and the service identification Section 2 begins by defining a service and the service identification
problem. Section 3 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 4 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 5 discusses the key architectural principles of service Next, Section 5 discusses the key architectural principles of service
identification. Section 6 describes how explicit service identifiers identification. Section 6 describes what explicit service invocation
can lead to fraud, interoperability failures, and stifling of service is, and how it can lead to fraud, interoperability failures, and
innovation. stifling of service innovation.
2. 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 [RFC4479] 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. describes. Services are described in Section 3.3 of RFC 4479.
Essentially, the service is the user-visible use case that is driving Essentially, the service is the user-visible use case that is driving
skipping to change at page 4, line 46 skipping to change at page 4, line 48
another (for example, an IM that gets sent whenever a user makes a another (for example, an IM that gets sent whenever a user makes a
call), and so on. call), and so on.
In some cases, there is very little difference in the underlying In some cases, there is very little difference in the underlying
technology that will support two different services, and in other technology that will support two different services, and in other
cases, there are big differences. However, for purposes of this cases, there are big differences. However, for purposes of this
discussion, the key definition is that two services are distinct when discussion, the key definition is that two services are distinct when
there is a perceived difference by the user in the two services. there is a perceived difference by the user in the two services.
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:
of the underlying service which is driving a particular signaling
exchange, (2) associating that service with some kind of moniker, and 1. determination of the underlying service which is driving a
(3) attaching that moniker to a signaling message (typically a SIP particular signaling exchange,
INVITE), and then utilizing it for various purposes within the
network. Service identification can be done in the endpoints, in 2. associating that service with a service identifier, and
which case the UA would insert the moniker directly into the
signaling message based on its awareness of the service. Or, it can 3. attaching that moniker to a signaling message (typically a SIP
be done within a server in the network (such as a proxy), based on INVITE)
inspection of the SIP message, or based on hints placed into the
message by the user. Once service identification is performed, the service identifier can
then be used for various purposes within the network. Service
identification can be done in the endpoints, in which case the UA
would insert the moniker directly into the signaling message based on
its awareness of the service. Or, it can be done within a server in
the network (such as a proxy), based on inspection of the SIP
message, or based on hints placed into the message by the user.
When service identification is performed entirely by inspecting the
signaling, this is called derived service identification. When it is
done based on knowledge known only by the invoking user agent, it is
called declarative service identification. Declarative service
identification can only be done in user agents, by definition.
3. 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. In
cases where it is hard to differentiate, service identification - and
in particular, declarative service identification - appears highly
attractive (and indeed, required).
3.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.
skipping to change at page 6, line 13 skipping to change at page 6, line 31
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) [RFC4975]. In both cases, the caller would send an Protocol (MSRP) [RFC4975]. In both cases, the caller would send an
INVITE to the Address of Record (AOR) of the target user. However, INVITE to the Address of Record (AOR) of the target user. However,
these represent fairly different services, in terms of user these represent fairly different services, in terms of user
experience. experience.
3.3. Configuration vs. Pager Messaging 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. However, the client
application allows the user to chat with their opponent. The chat
session is a simple voice session setup 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. However, different user experiences are
needed. For example, we desire traditional telephony features (such
as call forwarding and call screening) to be applied in the telephone
service, but not in the gaming chat service.
3.4. Configuration vs. Pager Messaging
The SIP MESSAGE method [RFC3428] provides a way to send one-shot The SIP MESSAGE method [RFC3428] provides a way to send one-shot
messages to a particular AOR. This specification is primarily aimed messages to a particular AOR. This specification is primarily aimed
at Short Message Service (SMS) style messaging, commonly found in at Short Message Service (SMS) style messaging, commonly found in
wireless phones. Receipt of a MESSAGE request would cause the wireless phones. Receipt of a MESSAGE request would cause the
messaging application on a phone to launch, allowing the user to messaging application on a phone to launch, allowing the user to
browse message 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
skipping to change at page 7, line 41 skipping to change at page 8, line 38
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. This software architecture is request to the appropriate service. This software architecture is
analagous to the way web servers frequently work. An HTTP server analagous to the way web servers frequently work. An HTTP server
listens on port 80 for requests, and based on the HTTP Request-URI, listens on port 80 for requests, and based on the HTTP Request-URI,
dispatches the request to a number of disparate applications. The dispatches the request to a number of disparate applications. The
same is happening here. For the example services in Section 3.2, an same is happening here. For the example services in Section 3.2, an
incoming INVITE for the gaming service would be delivered to the incoming INVITE for the gaming service would be delivered to the
gaming application software. An incoming INVITE for the voice chat gaming application software. An incoming INVITE for the voice chat
service would be delivered to the voice chat application software. service would be delivered to the voice chat application software.
For the examples in Section 3.3, a MESSAGE request for user to user The example in Section 3.3 is similar. For the examples in
messaging would be delivered to the messaging or SMS app, and a Section 3.4, a MESSAGE request for user to user messaging would be
MESSAGE request containing configuration data would be delivered to a delivered to the messaging or SMS app, and a MESSAGE request
configuration update application. containing configuration data would be delivered to a configuration
update application.
Unlike the web, however, in all three use cases, the user initiating Unlike the web, however, in all three use cases, the user initiating
communications has only a single identifier for the recipient - their communications has (or appears to have - more below) only a single
AOR. Consequently, the SIP Request-URI cannot be used for identifier for the recipient - their AOR. Consequently, the SIP
dispatching, as it is identical in all three cases. Request-URI cannot be used for dispatching, as it is identical in all
three cases.
4.2. Application Invocation in the Network 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
skipping to change at page 8, line 28 skipping to change at page 9, line 28
be processed by the content rights management server. Indeed, in be processed by the content rights management server. Indeed, in
these cases, it's 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 it's 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 3.3 might need to pass Similarly, a MESSAGE request from Section 3.4 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.
skipping to change at page 10, line 28 skipping to change at page 11, line 28
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.
5. Key Principles of Service Identification 5. Key Principles of Service Identification
In this section, we describe three key principles of service In this section, we describe several key principles of service
identification: identification:
1. Services are a by-product of signaling 1. Services are a by-product of signaling
2. Identical signaling produces identical services 2. Identical signaling produces identical services
3. Explicit service identifiers are an example of Do-What-I-Mean 3. Declarative service identification is an example of Do-What-I-
(DWIM) Mean (DWIM)
4. Explicit service identifiers are redundant 4. Explicit service identifiers are redundant
5. URIs are a key mechanism for producing differentiated signaling
5.1. Services are a By-Product of Signaling 5.1. Services are a By-Product of Signaling
Almost always, the first solution that people consider is to add some Declarative service identification - the addition of a service
kind of field to the signaling messages which indicates what the identifier by clients in order to inform other entities what the
service is. This field would then be inserted by the user agent, and service is - is a very compelling solution to solving the use cases
then can be used by the proxies and other user agent as a service described above. It provides a clear way for each of the use cases
identifier. to be differentiated. On the other hand, derived service
identification appears "hard" since the signaling appears to be the
same for these different services.
This approach, however, misses a key point, which cannot be stressed Declarative service identification misses a key point, which cannot
enough, and which represents the core architectural principle to be be stressed enough, and which represents the core architectural
understood here: principle to be understood here:
A service is the by-product of the signaling and the context A service is the by-product of the signaling and the context
around it (the user profile, time-of-day and so on) - the effects around it (the user profile, time-of-day and so on) - the effects
of the signaling message once launched into the network. The of the signaling message once launched into the network. The
service identity is therefore always derivable from the signaling service identity is therefore always derivable from the signaling
and its context without additional identifiers. and its context without additional identifiers. In other words,
derived service identification is always possible when signaling
is being properly handled.
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.
It may seem that delayed offers (SIP INVITE requests that lack SDP)
make it impossible to perform derived service identification. After
all, in some of the cases above, the differentiation was done using
the SDP in the request. What if its not there? The answer is simple
- if its not there, and the SDP is being offered by the called party,
you cannot in fact know the service at the time of the INVITE. Thats
the whole point of delayed offer - to give the called party the
chance to offer up what it wants for the session. In cases where
service identification is needed at request time, delayed offer
cannot be used.
5.2. Identical Signaling Produces Identical Services 5.2. Identical Signaling Produces Identical Services
This principle is a natural conclusion of the previous assertion. If This principle is a natural conclusion of the previous assertion. If
a service is the byproduct of signaling, how can a user have a service is the byproduct of signaling, how can a user have
different experiences and different services when the signaling different experiences and different services when the signaling
message is the same? They cannot. message is the same? They cannot.
But how can that be? From the examples in Section 3, it would seem But how can that be? From the examples in Section 3, it would seem
that there are services which are different, but have identical that there are services which are different, but have identical
signaling. If we hold true to the assertion, there is in fact only signaling. If we hold true to the assertion, there is in fact only
one logical conclusion: 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 one or more of the following is true:
has been overlooked, or something has been implied from the
signaling which should have been signaled explicitly. 1. there is in fact something different that has been overlooked
2. something has been implied from the signaling which 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 us take each of the example services in To illustrate this, let us take each of the example services in
Section 3 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 3.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
skipping to change at page 12, line 17 skipping to change at page 13, line 42
a difference. The MSRP messages for the gaming session carry a difference. The MSRP messages for the gaming session carry
content which is game specific, whereas the MSRP messages for the content which is game specific, whereas the MSRP messages for the
voice chat are just regular text, meant for rendering to a user. voice chat are just regular text, meant for rendering to a user.
Thus, the MSRP session in the SDP will indicate the specific Thus, the MSRP session in the SDP will indicate the specific
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.
Gaming vs. Voice CHat #2: In this case, both sessions involve only
voice, and both are targeted at the same AOR. Indeed, there truly
is nothing different - if indeed the signaling works this way.
However, there is an alternative mechanism for performing the
signaling. For the gaming session, the proprietary protocol can
be used to exchange a URI that can be used to identify the voice
chat function on the phone that is associated with the game (for
example, a GRUU can be used [I-D.ietf-sip-gruu]). Indeed, the
gaming chat is not targeting the USER - its targeting the gaming
instance on the phone. Thus, if a special GRUU is used for the
gaming chat, this makes the signaling different between these two
services.
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.
5.3. Do What I Say, not What I Mean 5.3. Do What I Say, not What I Mean
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.
"Do What I Mean", abbreviated as DWIM, is a concept in computer "Do What I Mean", abbreviated as DWIM, is a concept in computer
science. It is sometimes used to describe a function which tries to science. It is sometimes used to describe a function which tries to
intelligently guess at what the user intended. It is contrast to "Do intelligently guess at what the user intended. It is contrast to "Do
What I Say", or DWIS, which describes a function that behaves What I Say", or DWIS, which describes a function that behaves
concretely based on the inputs provided. Systems built on the DWIM concretely based on the inputs provided. Systems built on the DWIM
concept can have unexpected behaviors because they are driven by concept can have unexpected behaviors because they are driven by
unstated rules. unstated rules.
An explicit service identifier is an example of a DWIM approach. An Declarative service identification is an example of DWIM. The
explicit service identifier itself has no well-defined impact on the service identifier has no well-defined impact on the state machinery
state machinery or protocols in the system; it has various side- or protocols in the system; it has various side-effects based on an
effects based on an assumption of what is meant by the service assumption of what is meant by the service identifier. Derived
identifier. Interpretation of the signaling directly is an service identification, on the other hand, is an expression of the
expression of the principle of DWIS - the behavior of the system is principle of DWIS - the behavior of the system is based entirely on
based entirely on the specifics of the protocol and are well defined the specifics of the protocol and are well defined by the protocol
by the protocol specification. specification. The service identifier is just a short hand for
summarizing things that are well defined by signaling.
As a litmus test to differentiate the two cases, consider the
following question. If a request contained a service identifier, and
that request were processed by a domain which didn't understand the
concept of service identifiers at all, would the request be rejected
if that service were not supported, or would it complete but do the
wrong thing? If it is the latter case, its DWIM. If its the former,
its DWIS.
5.4. Explicit Service Identifiers are Redundant 5.4. Explicit Service Identifiers are Redundant
Because an explicit service identifier is, by definition, inside of Because an explicit service identifier is, by definition, inside of
the signaling message, and because the signaling itself completely the signaling message, and because the signaling itself completely
defines the behavior of the service, another natural conclusion is defines the behavior of the service, another natural conclusion is
that an explicit service identifier is redundant with the signaling that an explicit service identifier is redundant with the signaling
itself. It says nothing that could not otherwise be derived from itself. It says nothing that could not or should not otherwise be
examination of the signaling. derived from examination of the signaling.
6. Perils of Explicit Identifiers 5.5. URIs are Key for Differentiated Signaling
Based on these principles, several perils of an explicit service In the IPTV example and in the second gaming example, it was
identifier can be described. They are: ultimately the Request-URI that was (or should be) different between
the two services. This is important. In many cases where services
appear the same, it is because the resource which is being targeted
is not, in fact, the user. Rather, it is a resource that is linked
with the user. This resource might be an instance of a software
application on the particular device of a user, or a resource in the
network which acts on behalf of the user.
1. Explicit identifiers can be used for fraud The Request-URI is an infinitely large namespace for identifying
these resources. It is an ideal mechanism for providing
differentiation when there would otherwise be none.
2. Explicit identifiers can hurt interoperability Returning again to the example in Section 3.3, we can see that 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 on which
the user is playing the game. The software instance does indeed live
only on that phone, whereas the user themselves can be contacted 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 apply since the target of the request is completely
different.
3. Explicit identifiers can stifle service innovation 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 6.1. Fraud
Explicit service identifiers can lead to fraud. If a provider uses Declarative service identification can lead to fraud. If a provider
the service identifier for billing and accounting purposes, or for uses the service identifier for billing and accounting purposes, or
authorization purposes, it opens an avenue for attack. The user can for authorization purposes, it opens an avenue for attack. The user
construct the signaling message so that its actual effect (which is can construct the signaling message so that its actual effect (which
the service the user will receive), is what the user desires, but the is the service the user will receive), is what the user desires, but
user places a service identifier into the request (which is what is the user places a service identifier into the request (which is what
used for billing and authorization) that identifies a cheaper is used for billing and authorization) that identifies a cheaper
service, or one that the user is authorized to receive. In such a service, or one that the user is authorized to receive. In such a
case, the user will be billed for something they did not receive. case, the user will be billed for something they did not receive.
If, however, the domain administrator derived the service identifier If, however, the domain administrator derived the service identifier
from the signaling itself, the user cannot lie. If they did lie, from the signaling itself (derived service identification), the user
they wouldn't get the desired service. 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. The user gets the service associated with multimedia conferencing. The user gets the service associated with
IPTV, 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 identification of an emergency services call
[I-D.ietf-ecrit-framework]. It is desirable to give emergency [I-D.ietf-ecrit-framework]. It is desirable to give emergency
skipping to change at page 14, line 13 skipping to change at page 16, line 33
course get routed to the target URI. The only way to prevent this course get routed to the target URI. The only way to prevent this
fraud is to consider an emergency call as any call whose target is an fraud is to consider an emergency call as any call whose target is an
emergency services URN. Thus, the service identification here is emergency services URN. Thus, the service identification here is
based on the target of the request. When the target is an emergency based on the target of the request. When the target is an emergency
services URN, the request can get special treatment. The user cannot services URN, the request can get special treatment. The user cannot
lie, since there is no way to separately indicate this is an lie, since there is no way to separately indicate this is an
emergency call, besides targeting it to an emergency URN. emergency call, besides targeting it to an emergency URN.
6.2. Systematic Interoperability Failures 6.2. Systematic Interoperability Failures
How can inclusion of an explicit service identifier cause loss of How can declarative service identification cause loss of
interoperability? When such an identifier is used to drive interoperability? When an identifier is used to drive functionality
functionality - such as dispatch on the phones, in the network, or - such as dispatch on the phones, in the network, or QoS
QoS authorization, it means that the wrong thing can happen when this 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 perform 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 server in domain 2, the service identifier is unknown. the server in domain 2, the service identifier is unknown.
Consequently, the request does not get the proper QoS treatment, even Consequently, the request does not get the proper QoS treatment, even
if the call itself will succeed. if the call itself will succeed.
Explicit service identifiers, used between domains, cause If, on the other hand, derived service identification were used, the
service identifier could be removed by domain 2, and then recomputed
based on the signaling to match its own notion of services. In this
case, domain 2 could derive the "text telephony" identifier, and the
request completes successfully.
declarative service identification, used between domains, causes
interoperability failures unless all interconnected domains agree on interoperability failures unless all interconnected domains agree on
exactly the same set of services and how to name them. Of course, exactly the same set of services and how to name them. Of course,
lack of service identifiers does not guarantee service 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
skipping to change at page 15, line 7 skipping to change at page 17, line 33
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. That is why
services need to be derived by signaling - because the signaling
itself provides negotiation and interoperability between different
domains.
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 Declarative service identification will result in inconsistencies
inconsistencies between those service identifiers and the results of between its service identifiers and the results of any SIP
any SIP negotiation that might otherwise be applied in the session. negotiation that might otherwise be applied in the session.
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 (which is the case for declarative service identification), 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 [RFC4485] 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 declarative service identification needs to be
avoided. avoided.
6.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 offering to their customers, and each do the same thing. This is
because each provider has become dependent on inclusion of the proper because each provider has become dependent on inclusion of the proper
service identifier in the request, in order for the overall treatment service identifier in the request, in order for the overall treatment
of the request to proceed correctly. This is, in a very real sense, 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 anathema to the entire notion of SIP, which is built on the idea that
heterogeneous domains can interconnect and still get heterogeneous domains can interconnect and still get
interoperability. interoperability.
Explicit service identifiers lead to a requirement for homogeneity in Declarative service identification leads to a requirement for
service definitions across providers that interconnect, ruining the homogeneity in service definitions across providers that
very service heterogeneity that SIP was meant to bring. interconnect, ruining the 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
skipping to change at page 16, line 43 skipping to change at page 19, line 25
7. Recommendations 7. Recommendations
From these principles, several recommendations can be made: From these principles, several recommendations can be made:
o Systems needing to perform service identification must examine o Systems needing to perform service identification must examine
existing signaling constructs to identify the service based on existing signaling constructs to identify the service based on
fields that exist within the signaling message already. fields that exist within the signaling message already.
o If it appears that the signaling currently defined in standards is o If it appears that the signaling currently defined in standards is
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, or may because
work should be undertaken to fill this gap. request URIs should be used for differentiation.
o The usage of an explicit service identifier does make sense as a o When performing derived service identification, domains should be
way to cache a decision made by a network element, for usage by aware that sessions may arrive from different networks and
another network element within the same domain. However, service different endpoints. Consequently, the service identification
identifiers are fundamentally useful within a particular domain, algorithm must be complete - meaning it computes the best answer
and any such header must be stripped at a network boundary. for any possible signaling message that might be received.
o Presence can help a great deal with providing unique URIs for
different services. 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. Those URI can then be used in
the Request-URI for differentiation. When possible, this is the
best solution to the problem.
o Service identifiers themselves are not bad; derived service
identification allows each domain to cache the results of the
service identification process for usage 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.
o Device dispatch should be done following the principles of o Device dispatch should be done following the principles of
[RFC3841], using implicit preferences based on the signaling. For [RFC3841], using implicit preferences based on the signaling. For
example, [I-D.rosenberg-sip-app-media-tag] defines a new UA example, [I-D.rosenberg-sip-app-media-tag] defines a new UA
capability that can be used to dispatch requests based on capability that can be used to dispatch requests based on
different types of application media streams. 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
unauthorized service use and network fraud is introduced. It is for unauthorized service use and network fraud is introduced. It is for
this reason, discussed extensively in Section 6.1, that the usage of this reason, discussed extensively in Section 6.1, that the usage of
explicit service identifiers inserted by a UA is not recommended. explicit service identifiers inserted by a UA is not recommended.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 18, line 23 skipping to change at page 21, line 13
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-04 (work in Multimedia", draft-ietf-ecrit-framework-05 (work in
progress), November 2007. progress), February 2008.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[I-D.rosenberg-sip-app-media-tag] [I-D.rosenberg-sip-app-media-tag]
Rosenberg, J., "A Session Initiation Protocol (SIP) Media Rosenberg, J., "A Session Initiation Protocol (SIP) Media
Feature Tag for MIME Application Sub-Types", Feature Tag for MIME Application Sub-Types",
draft-rosenberg-sip-app-media-tag-02 (work in progress), draft-rosenberg-sip-app-media-tag-02 (work in progress),
November 2007. November 2007.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
 End of changes. 45 change blocks. 
156 lines changed or deleted 282 lines changed or added

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