draft-ietf-sipping-service-identification-04.txt   rfc5897.txt 
SIPPING J. Rosenberg Internet Engineering Task Force (IETF) J. Rosenberg
Internet-Draft jdrosen.net Request for Comments: 5897 jdrosen.net
Intended status: Informational March 23, 2010 Category: Informational June 2010
Expires: September 24, 2010 ISSN: 2070-1721
Identification of Communications Services in the Session Initiation Identification of Communications Services
Protocol (SIP) in the Session Initiation Protocol (SIP)
draft-ietf-sipping-service-identification-04
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 (UA). This document
the uses of service identification, and outlines several discusses the uses of service identification, and outlines several
architectural principles behind the process. It identifies perils architectural principles behind the process. It identifies perils
when service identification is not done properly - including fraud, when service identification is not done properly -- including fraud,
interoperability failures and stifling of innovation. It then interoperability failures, and stifling of innovation. It then
outlines a set of reccomended practices for service identification. outlines a set of recommended practices for service identification.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on September 24, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5897.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Services and Service Identification . . . . . . . . . . . . . 5 2. Services and Service Identification .............................4
3. Example Services . . . . . . . . . . . . . . . . . . . . . . . 7 3. Example Services ................................................6
3.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 7 3.1. IPTV vs. Multimedia ........................................6
3.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 7 3.2. Gaming vs. Voice Chat ......................................7
3.3. Gaming vs. Voice Chat #2 . . . . . . . . . . . . . . . . . 8 3.3. Gaming vs. Voice Chat #2 ...................................7
3.4. Configuration vs. Pager Messaging . . . . . . . . . . . . 8 3.4. Configuration vs. Pager Messaging ..........................7
4. Using Service Identification . . . . . . . . . . . . . . . . . 9 4. Using Service Identification ....................................8
4.1. Application Invocation in the User Agent . . . . . . . . . 9 4.1. Application Invocation in the User Agent ...................8
4.2. Application Invocation in the Network . . . . . . . . . . 10 4.2. Application Invocation in the Network ......................9
4.3. Network Quality of Service Authorization . . . . . . . . . 11 4.3. Network Quality-of-Service Authorization ..................10
4.4. Service Authorization . . . . . . . . . . . . . . . . . . 11 4.4. Service Authorization .....................................10
4.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 12 4.5. Accounting and Billing ....................................11
4.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 12 4.6. Negotiation of Service ....................................11
4.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 12 4.7. Dispatch to Devices .......................................11
5. Key Principles of Service Identification . . . . . . . . . . . 12 5. Key Principles of Service Identification .......................12
5.1. Services are a By-Product of Signaling . . . . . . . . . . 13 5.1. Services Are a By-Product of Signaling ....................12
5.2. Identical Signaling Produces Identical Services . . . . . 14 5.2. Identical Signaling Produces Identical Services ...........13
5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 15 5.3. Do What I Say, Not What I Mean ............................14
5.4. Declarative Service Identifiers are Redundant . . . . . . 16 5.4. Declarative Service Identifiers Are Redundant .............15
5.5. URIs are Key for Differentiated Signaling . . . . . . . . 16 5.5. URIs Are Key for Differentiated Signaling .................15
6. Perils of Declarative Service Identification . . . . . . . . . 17 6. Perils of Declarative Service Identification ...................16
6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Fraud .....................................................16
6.2. Systematic Interoperability Failures . . . . . . . . . . . 18 6.2. Systematic Interoperability Failures ......................17
6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 19 6.3. Stifling of Service Innovation ............................18
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 20 7. Recommendations ................................................20
7.1. Use Derived Service Identification . . . . . . . . . . . . 20 7.1. Use Derived Service Identification ........................20
7.2. Design for SIP's Negotiative Expressiveness . . . . . . . 21 7.2. Design for SIP's Negotiative Expressiveness ...............20
7.3. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Presence ..................................................21
7.4. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . . 22 7.4. Intra-Domain ..............................................21
7.5. Device Dispatch . . . . . . . . . . . . . . . . . . . . . 22 7.5. Device Dispatch ...........................................21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations ........................................22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements ...............................................22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Informative References ........................................22
11. Informational References . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
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 high-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 and ranging from low-
generated content, up to high definition movie and TV content. SIP bandwidth user-generated content, up to high-definition movie and TV
endpoints can be anything - adaptors that convert an old analog content. SIP endpoints can be anything -- adaptors that convert an
telephone to Voice over IP (VoIP), dedicated hardphones, fancy old analog telephone to Voice over IP (VoIP), dedicated hardphones,
hardphones with rich displays and user entry capabilities, softphones fancy hardphones with rich displays and user entry capabilities,
on a PC, buddylist and presence applications on a PC, dedicated softphones on a PC, buddy-list and presence applications on a PC,
videoconferencing peripherals, and speakerphones. dedicated videoconferencing peripherals, and speakerphones.
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.
Each of these different use cases represents a different service. Each of these different use cases represents a different service.
The service is the user-visible use case that is driving the behavior The service is the user-visible use case that is driving the behavior
of the user-agents and servers in the SIP network. of the user agents and servers in the SIP network.
The differing services possible with SIP has driven implementors and The differing services possible with SIP have driven implementors and
system designers to seek techniques for service identification. system designers to seek techniques for service identification.
Service identification is the process of determining and/or signaling Service identification is the process of determining and/or signaling
the specific use case that is driving the signaling being generated the specific use case that is driving the signaling being generated
by a user agent. At first glance, this seems harmless and easy by a user agent. At first glance, this seems harmless and easy
enough. It is tempting to define a new header, "Service-ID", for 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- 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 known tokens that define what the service is. It could then be
consumed for any number of purposes. A service identifier placed consumed for any number of purposes. A token placed into the
into the signaling is called a service identifier. signaling for this purpose is called a service identifier.
Service identification and service identifiers, when used properly, Service identification and service identifiers, when used properly,
can be beneficial. However, when done improperly, service can be beneficial. However, when done improperly, service
identification can lead to fraud, systemic interoperability failures, identification can lead to fraud, systemic interoperability failures,
and a complete stifling of the innovation that SIP was meant to and a complete stifling of the innovation that SIP was meant to
achieve. The purpose of this document is to describe service achieve. The purpose of this document is to describe service
identification in more detail and describe how these problems arise. 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 what declarative service identification. Section 6 describes what declarative service
invocation is, and how it can lead to fraud, interoperability invocation is, and how it can lead to fraud, interoperability
failures, and stifling of service innovation. failures, and stifling of service innovation.
Consequently, this document concludes that declarative service Consequently, this document concludes that declarative service
identification - the process by which a user agent inserts a moniker identification -- the process by which a user agent inserts a moniker
into a message that defines the desired service, separate from into a message that defines the desired service, separate from
explicit and well-defiend protocol mechanisms, is harmful. explicit and well-defined protocol mechanisms -- is harmful.
Instead of performing declarative service identification, this Instead of performing declarative service identification, this
document recommends derived service identification, and gives several document recommends derived service identification, and gives several
reccomendations around it in Section 7: recommendations around it in Section 7:
1. The identity of a service should always be derived from the 1. The identity of a service should always be derived from the
explicit signaling in the protocol messages and other contextual explicit signaling in the protocol messages and other contextual
information, and never indicated by the user through a separate information, and never indicated by the user through a separate
identifier placed into the message. identifier placed into the message.
2. The process of service identification based on signaling messages 2. The process of service identification based on signaling messages
must be designed to SIP's negotiative expressiveness, and must be designed to SIP's negotiative expressiveness, and
therefore handle heterogeneity and not assume a fixed set of use therefore handle heterogeneity and not assume a fixed set of use
cases. cases.
3. Presence can help in providing URIs that can be utilized to 3. Presence can help in providing URIs that can be utilized to
connect to specific services, thereby creating explicit connect to specific services, thereby creating explicit
indications in the signaling which can be used to dervice a indications in the signaling that can be used to derive a service
service identity. identity.
4. Service identities placed into signaling messages for the 4. Service identities placed into signaling messages for the
purposes of caching the service identity are strictly for intra- purposes of caching the service identity are strictly for intra-
domain usage. domain usage.
5. Device dispatch should be based on feature-tags which map to 5. Device dispatch should be based on feature tags that map to well-
well-defined SIP extensions and capabilities, and not abstract defined SIP extensions and capabilities. Service dispatch should
service identifiers. not be based on abstract service identifiers.
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
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
"voice-chat"), different user interfaces (a buddy list view of voice "voice chat"), different user interfaces (a buddy-list view of voice
on a PC application vs. a software emulation of a hard phone), on a PC application vs. a software emulation of a hardphone),
different communities that can be accessed (voice chat with other different communities that can be accessed (voice chat with other
users that have the same voice chat client, vs. voice communications users that have the same voice chat client vs. voice communications
with any endpoint on the PSTN), or different applications that are with any endpoint on the Public Switched Telephone Network (PSTN)),
invoked by the user (manually selecting a push-to-talk application or different applications that are invoked by the user (manually
from a wireless phone vs. a telephony application). Outside of a selecting a Push-To-Talk application from a wireless phone vs. a
call, the difference in user experience can be a billing one (cheaper telephony application). Outside of a call, the difference in user
for one service than other), a notification feature for one and not experience can be a billing one (cheaper for one service than
another (for example, an IM that gets sent whenever a user makes a another), a notification feature for one and not another (for
call), and so on. example, an IM that gets sent whenever a user makes a 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 the 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: Service identification is defined as the process of:
1. determination of the underlying service which is driving a 1. determining the underlying service that is driving a particular
particular signaling exchange, signaling exchange,
2. associating that service with a service identifier, and 2. associating that service with a service identifier, and
3. attaching that moniker to a signaling message (typically a SIP 3. attaching that moniker to a signaling message (typically a SIP
INVITE) INVITE).
Once service identification is performed, the service identifier can Once service identification is performed, the service identifier can
then be used for various purposes within the network. Service then be used for various purposes within the network. Service
identification can be done in the endpoints, in which case the UA identification can be done in the endpoints, in which case the UA
would insert the moniker directly into the signaling message based on 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 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 the network (such as a proxy), based on inspection of the SIP
message, or based on hints placed into the message by the user. message, or based on hints placed into the message by the user.
When service identification is performed entirely by inspecting the When service identification is performed entirely by inspecting the
signaling, this is called derived service identification. When it is signaling, this is called derived service identification. When it is
done based on knowledge known only by the invoking user agent, it is done based on knowledge possessed only by the invoking user agent, it
called declarative service identification. Declarative service is called declarative service identification. Declarative service
identification can only be done in user agents, by definition. 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. In ones that appear difficult to differentiate from each other. In
cases where it is hard to differentiate, service identification - and cases where it is hard to differentiate, service identification --
in particular, declarative service identification - appears highly and in particular, declarative service identification -- appears
attractive (and indeed, required). 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.
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 listen-only multimedia conferencing, These two services -- IPTV and listen-only multimedia conferencing --
clearly appear as different services. They have different user clearly appear as different services. They have different user
experiences and applications. A user is unlikely to ever be confused experiences and applications. A user is unlikely to ever be confused
about whether a session is IPTV or listen-only multimedia about whether a session is IPTV or listen-only multimedia
conferencing. Indeed, they are likely to have different software conferencing. Indeed, they are likely to have different software
applications or endpoints for the two 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.
3.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) [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. Gaming vs. Voice Chat #2 3.3. Gaming vs. Voice Chat #2
Consider a variation on the example in Section 3.2. In this Consider a variation on the example in Section 3.2. In this
variation, two users are playing an interactive game between their variation, two users are playing an interactive game between their
phones. However, the game itself is set up and controlled using a phones. However, the game itself is set up and controlled using a
proprietary mechanism - not using SIP at all. However, the client proprietary mechanism -- not using SIP at all. However, the client
application allows the user to chat with their opponent. The chat application allows the user to chat with their opponent. The chat
session is a simple voice session setup between the players. session is a simple voice session set up between the players.
Compare this with a basic telephone call between the two users. Both Compare this with a basic telephone call between the two users. Both
involve a single audio session. Both use the same codecs. They involve a single audio session. Both use the same codecs. They
appear to be identical. However, different user experiences are appear to be identical. However, different user experiences are
needed. For example, we desire traditional telephony features (such needed. For example, we desire traditional telephony features (such
as call forwarding and call screening) to be applied in the telephone as call forwarding and call screening) to be applied in the telephone
service, but not in the gaming chat service. service, but not in the gaming chat service.
3.4. Configuration vs. Pager Messaging 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 the message history and respond.
However, MESSAGE is sometimes used for the delivery of content to a However, a MESSAGE request is sometimes used for the delivery of
device for other purposes. For example, some providers use it to content to a device for other purposes. For example, some providers
deliver configuration updates, such as new phone settings or use it to deliver configuration updates, such as new phone settings
parameters, or to indicate that a new version of firmware is or 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, the MESSAGE method
since, in existing wireless networks, SMS is used for this purpose, gets used since, in existing wireless networks, SMS is used for this
and MESSAGE is the SIP equivalent of SMS. purpose, and the MESSAGE request 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.
4. 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. This section discusses the primary uses. utilized for, if known. This section discusses the primary uses.
skipping to change at page 9, line 25 skipping to change at page 8, line 30
In some of the examples above, there were multiple software In some of the examples above, there were multiple software
applications executing on the host. One common way of achieving this applications executing on the host. One common way of achieving this
is to utilize a common SIP user agent implementation that listens for is to utilize a common SIP user agent implementation that listens for
requests on a single port. When an incoming INVITE or MESSAGE requests on a single port. When an incoming INVITE or MESSAGE
arrives, it must be delivered to the appropriate application arrives, it must be delivered to the appropriate application
software. When each service is bound to a distinct software software. When each service is bound to a distinct software
application, it would seem that the service identity is needed to application, it would seem that the service identity is needed to
dispatch the message to the appropriate piece of software. This is dispatch the message to the appropriate piece of software. This is
shown in Figure 1. shown in Figure 1.
+---------------------------------+ +---------------------------------+
| | | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| | UI | | UI | | | | UI | | UI | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| | | | | | | | | | | |
| | Service 1 | | Service 2 | | | | Service 1 | | Service 2 | |
| | | | | | | | | | | |
| +-------------+ +-------------+ | | +-------------+ +-------------+ |
| +-----------------------------+ | | +-----------------------------+ |
| | | | | | | |
| | SIP | | | | SIP | |
| | Layer | | | | Layer | |
| | | | | | | |
| +-----------------------------+ | | +-----------------------------+ |
| | | |
+---------------------------------+ +---------------------------------+
Physical Device Physical Device
Figure 1 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
requests to the appropriate service. This software architecture is requests to the appropriate service. This software architecture is
analagous to the way web servers frequently work. An HTTP server analogous 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.
The example in Section 3.3 is similar. For the examples in The example in Section 3.3 is similar. For the examples in
Section 3.4, a MESSAGE request for user to user messaging would be Section 3.4, a MESSAGE request for user-to-user messaging would be
delivered to the messaging or SMS app, and a MESSAGE request delivered to the messaging or SMS app, and a MESSAGE request
containing configuration data would be delivered to a configuration containing configuration data would be delivered to a configuration
update application. 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 (or appears to have - more below) only a single communications has (or appears to have -- more below) only a single
identifier for the recipient - their AOR. Consequently, the SIP identifier for the recipient -- their AOR. Consequently, the SIP
Request-URI cannot be used for dispatching, as it is identical in all Request-URI cannot be used for dispatching, as it is identical in all
three cases. 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
skipping to change at page 10, line 44 skipping to change at page 9, line 50
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.4 might need to pass Similarly, a MESSAGE request as described in Section 3.4 might need
through a message server for filtering when it is associated with to pass through a message server for filtering when it is associated
chat, but not when it is associated with config. Consider a filter with chat, but not when it is associated with a configuration update.
which gets applied to MESSAGE requests, and that filter runs in a
server in the network. The filter operation prevents user Joe from
sending messages to user Bob that contain the words "stock" or
"purchase", due to some regulations that disallow Joe and Bob from
discussing stock trading. However, a MESSAGE for configuration
purposes might contain an XML document that uses the token "stock" as
some kind of attribute. This configuration update would be discarded
by the filtering server, when it should not have been.
4.3. Network Quality of Service Authorization Consider a filter that gets applied to MESSAGE requests, and that
filter runs in a server in the network. The filter operation
prevents user Joe from sending messages to user Bob that contain the
words "stock" or "purchase", due to some regulations that disallow
Joe and Bob from discussing stock trading. However, a MESSAGE for
configuration purposes might contain an XML document that uses the
token "stock" as some kind of attribute. This configuration update
would be discarded by the filtering server, when it should not have
been.
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 [RFC2205]) or through marking of Diffserv protocols (such as the Resource ReSerVation Protocol (RSVP)
value in packets. The network will need to make a policy decision [RFC2205]) or through marking of a Diffserv value in packets. The
based on whether these QoS treatments are authorized or not. One network will need to make a policy decision based on whether or not
common authorization policy is to check if the user has invoked a these QoS treatments are authorized. One common authorization policy
service using SIP that they are authorized to invoke, and that this is to check if the user has invoked a service using SIP that they are
service requires the level of QoS treatment the user has requested. authorized to invoke, and that this service 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 3.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 in 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 choose 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.
4.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
skipping to change at page 12, line 24 skipping to change at page 11, line 28
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.
4.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 choose 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, a 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 3.2. They initiate a session to a target AOR, but the described in Section 3.2. The user initiates a session to a target
devices used by that user can only support voice chat. The called AOR, but the devices used by the target can only support voice chat.
device returns, in its call acceptance, an indication that only voice The called device returns, in its call acceptance, an indication that
chat can be used. Consequently, voice chat gets utilized for the only voice chat can be used. Consequently, voice chat gets utilized
session. for the session.
4.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
service, and the other that cannot, the INVITE should be dispatched gaming service, and another that cannot -- the INVITE should be
to the device which supports the gaming session. dispatched to the device that supports the gaming session.
5. Key Principles of Service Identification 5. Key Principles of Service Identification
In this section, we describe several 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. Declarative service identification is an example of Do-What-I- 3. Declarative service identification is an example of "Do What I
Mean (DWIM) Mean" (DWIM)
4. Declarative service identifiers are redundant 4. Declarative service identifiers are redundant
5. URIs are a key mechanism for producing differentiated signaling 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
Declarative service identification - the addition of a service Declarative service identification -- the addition of a service
identifier by clients in order to inform other entities what the identifier by clients in order to inform other entities of what the
service is - is a very compelling solution to solving the use cases service is -- is a very compelling solution to solving the use cases
described above. It provides a clear way for each of the use cases described above. It provides a clear way for each of the use cases
to be differentiated. On the other hand, derived service to be differentiated. On the other hand, derived service
identification appears "hard" since the signaling appears to be the identification appears "hard", since the signaling appears to be the
same for these different services. same for these different services.
Declarative service identification misses a key point, which cannot Declarative service identification misses a key point, which cannot
be stressed enough, and which represents the core architectural be stressed enough, and which represents the core architectural
principle to be understood here: principle to be understood here:
A service is the by-product of the signaling and the context A service is the byproduct of the signaling and the context around
around it (the user profile, time-of-day and so on) - the effects it (the user profile, time of day, and so on) -- the effects of
of the signaling message once launched into the network. The the signaling message once it is 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. In other words, and its context without additional identifiers. In other words,
derived service identification is always possible when signaling derived service identification is always possible when signaling
is being properly handled. 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 the Session Description
streaming, the *result* of sending such an INVITE is that an IPTV Protocol (SDP) for audio and video streaming, the *result* of sending
session occurs. The entire purpose of the INVITE is to establish such an INVITE is that an IPTV session occurs. The entire purpose of
such a session, and therefore, invoke the service. Thus, a service the INVITE is to establish such a session, and therefore, invoke the
is not something that is different from the rest of the signaling service. Thus, a service is not something that is different from the
message. A service is what the user gets after the network and other rest of the signaling message. A service is what the user gets after
user agents have processed a signaling message. the network and other user agents have processed a signaling message.
It may seem that delayed offers (SIP INVITE requests that lack SDP) It may seem that delayed offers (SIP INVITE requests that lack SDP)
make it impossible to perform derived service identification. After make it impossible to perform derived service identification. After
all, in some of the cases above, the differentiation was done using 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 the SDP in the request. What if it's not there? The answer is
- if its not there, and the SDP is being offered by the called party, simple -- if it's not there, and the SDP is being offered by the
you cannot in fact know the service at the time of the INVITE. Thats called party, you cannot in fact know the service at the time of the
the whole point of delayed offer - to give the called party the INVITE. That's the whole point of delayed offer -- to give the
chance to offer up what it wants for the session. In cases where called party the chance to offer up what it wants for the session.
service identification is needed at request time, delayed offer In cases where service identification is needed at request time,
cannot be used. 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 that 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 one or more of the following is true: the same, it is because one or more of the following is true:
1. there is in fact something different that has been overlooked 1. there is in fact something different that has been overlooked
2. something has been implied from the signaling which should 2. something has been implied from the signaling, when in fact it
have been signaled explicitly should have been signaled explicitly
3. the signaling mechanism should be changed so that there is, in 3. the signaling mechanism should be changed so that there is, in
fact, something that is different 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 described in
appear to have identical signaling. They both involve audio and Section 3.1 appear to have identical signaling. They both involve
video streams, both of which are unidirectional. Both might audio and video streams, both of which are unidirectional. Both
utilize the same codecs. However, there is another important might utilize the same codecs. However, there is another
difference in the signaling - the target URI. In the case of important difference in the signaling -- the target URI. In the
IPTV, the request is targeted at a media server or to a particular case of IPTV, the request is targeted at a media server or to a
piece of content to be viewed. In the case of multimedia particular piece of content to be viewed. In the case of
conferencing, the target is a conference server. The multimedia 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 Request-URI
URI, and figure out whether it is targeted for a conference server and figure out whether it is targeted for a conference server or a
or a content server, and use that to derive the service associated content server, and use that to derive the service associated with
with the request. the request.
Gaming vs. Voice Chat: Though both sessions involve MSRP and voice, Gaming vs. Voice Chat: Though both sessions involve MSRP and voice,
and both are targeted to the same AOR of the called user, there is and both are targeted to the same AOR of the called user, there is
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 that 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 Gaming vs. Voice Chat #2: In this case, both sessions involve only
voice, and both are targeted at the same AOR. Indeed, there truly voice, and both are targeted at the same AOR. Indeed, there truly
is nothing different - if indeed the signaling works this way. is nothing different -- if indeed the signaling works this way.
However, there is an alternative mechanism for performing the However, there is an alternative mechanism for performing the
signaling. For the gaming session, the proprietary protocol can signaling. For the gaming session, the proprietary protocol can
be used to exchange a URI that can be used to identify the voice 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 chat function on the phone that is associated with the game (for
example, a GRUU can be used [RFC5627]). Indeed, the gaming chat example, a Globally Routable User Agent URI (GRUU) can be used
is not targeting the USER - its targeting the gaming instance on [RFC5627]). Indeed, the gaming chat is not targeting the USER --
the phone. Thus, if a special GRUU is used for the gaming chat, it's targeting the gaming instance on the phone. Thus, if a
this makes the signaling different between these two services. 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
"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 that tries to
intelligently guess at what the user intended. It is contrast to "Do intelligently guess at what the user intended. It is in contrast to
What I Say", or DWIS, which describes a function that behaves "Do 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.
Declarative service identification is an example of DWIM. The Declarative service identification is an example of DWIM. The
service identifier has no well-defined impact on the state machinery service identifier has no well-defined impact on the state machinery
or protocols in the system; it has various side-effects based on an or protocols in the system; it has various side effects based on an
assumption of what is meant by the service identifier. Derived assumption of what is meant by the service identifier. Derived
service identification, on the other hand, is an expression of the service identification, on the other hand, is an expression of the
principle of DWIS - the behavior of the system is based entirely on principle of DWIS -- the behavior of the system is based entirely on
the specifics of the protocol and are well defined by the protocol the specifics of the protocol and are well defined by the protocol
specification. The service identifier is just a short hand for specification. The service identifier is just a shorthand for
summarizing things that are well defined by signaling. summarizing things that are well defined by signaling.
As a litmus test to differentiate the two cases, consider the As a litmus test to differentiate the two cases, consider the
following question. If a request contained a service identifier, and following question. If a request contained a service identifier, and
that request were processed by a domain which didn't understand the that request were processed by a domain that didn't understand the
concept of service identifiers at all, would the request be rejected concept of service identifiers at all, would the request be rejected
if that service were not supported, or would it complete but do the 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, wrong thing? If it is the latter case, it's DWIM. If it's the
its DWIS. former, it's DWIS.
5.4. Declarative Service Identifiers are Redundant 5.4. Declarative Service Identifiers Are Redundant
Because a declarative service identifier is, by definition, inside of Because a declarative 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 a declarative service identifier is redundant with the signaling that a declarative service identifier is redundant with the signaling
itself. It says nothing that could not or should not otherwise be itself. It says nothing that could not or should not otherwise be
derived from examination of the signaling. derived from examination of the signaling.
5.5. URIs are Key for Differentiated Signaling 5.5. URIs Are Key for Differentiated Signaling
In the IPTV example and in the second gaming example, it was In the IPTV example and in the second gaming example, it was
ultimately the Request-URI that was (or should be) different between ultimately the Request-URI that was (or should be) different between
the two services. This is important. In many cases where services the two services. This is important. In many cases where services
appear the same, it is because the resource which is being targeted appear the same, it is because the resource that is being targeted is
is not, in fact, the user. Rather, it is a resource that is linked not, in fact, the user. Rather, it is a resource that is linked with
with the user. This resource might be an instance of a software the user. This resource might be an instance of a software
application on the particular device of a user, or a resource in the application on the particular device of a user, or a resource in the
network which acts on behalf of the user. network that acts on behalf of the user.
The Request-URI is an infinitely large namespace for identifying The Request-URI is an infinitely large namespace for identifying
these resources. It is an ideal mechanism for providing these resources. It is an ideal mechanism for providing
differentiation when there would otherwise be none. differentiation when there would otherwise be none.
Returning again to the example in Section 3.3, we can see that it 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 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. 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 gaming chat session should really only go to the phone on which
the user is playing the game. The software instance does indeed live the user is playing the game. The software instance does indeed live
only on that phone, whereas the user themselves can be contacted many only on that phone, whereas the user themselves can be contacted in
ways. We don't want telephony features invoked for the gaming chat many ways. We don't want telephony features invoked for the gaming
session because those features only make sense when someone is trying chat session, because those features only make sense when someone is
to communicate with the USER. When someone is trying to communicate trying to communicate with the USER. When someone is trying to
with a software instance that acts on behalf of the user, a different communicate with a software instance that acts on behalf of the user,
set of rules apply since the target of the request is completely a different set of rules apply, since the target of the request is
different. completely different.
6. Perils of Declarative Service Identification 6. Perils of Declarative Service Identification
Based on these principles, several perils of declarative service Based on these principles, several perils of declarative service
identification can be described. They are: identification can be described. They are:
1. Declarative service identification can be used for fraud 1. Declarative service identification can be used for fraud
2. Declarative service identification can hurt interoperability 2. Declarative service identification can hurt interoperability
skipping to change at page 17, line 25 skipping to change at page 16, line 28
6.1. Fraud 6.1. Fraud
Declarative service identification can lead to fraud. If a provider Declarative service identification can lead to fraud. If a provider
uses the service identifier for billing and accounting purposes, or uses the service identifier for billing and accounting purposes, or
for authorization purposes, it opens an avenue for attack. The user for authorization purposes, it opens an avenue for attack. The user
can construct the signaling message so that its actual effect (which can construct the signaling message so that its actual effect (which
is the service the user will receive), is what the user desires, but is the service the user will receive), is what the user desires, but
the user places a service identifier into the request (which is what the user places a service identifier into the request (which is what
is 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 not authorized to receive. In such
case, the user will be billed for something they did not receive. a case, the user will receive service, and not be billed properly for
it.
If, however, the domain administrator derived the service identifier If, however, the domain administrator derived the service identifier
from the signaling itself (derived service identification), the user from the signaling itself (derived service identification), the user
cannot lie. If they did lie, 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 that 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 [ECRIT-FRAMEWORK]. It
[I-D.ietf-ecrit-framework]. It is desirable to give emergency is desirable to give emergency services calls special treatment, such
services calls special treatment, such as being free, authorized even as being free and authorized even when the user cannot otherwise make
when the user cannot otherwise make calls, and to give them priority. calls, and to give them priority. If emergency calls were indicated
If emergency calls where indicated through something other than the through something other than the target of the call being an
target of the call being an emergency services URN [RFC5031], it emergency services URN [RFC5031], it would open an avenue for fraud.
would open an avenue for fraud. The user could place any desired URI The user could place any desired URI in the request-URI, and indicate
in the request-URI, and indicate separately, through a declarative separately, through a declarative identifier, that the call is an
identifier, that the call is an emergency services call. This could emergency services call. This would then get special treatment but
would then get special treatment, but of course get routed to the of course would get routed to the target URI. The only way to
target URI. The only way to prevent this fraud is to consider an prevent this fraud is to consider an emergency call as any call whose
emergency call as any call whose target is an emergency services URN. target is an emergency services URN. Thus, the service
Thus, the service identification here is based on the target of the identification here is based on the target of the request. When the
request. When the target is an emergency services URN, the request target is an emergency services URN, the request can get special
can get special treatment. The user cannot lie, since there is no treatment. The user cannot lie, since there is no way to separately
way to separately indicate this is an emergency call, besides indicate that this is an emergency call, besides targeting it to an
targeting it to an emergency URN. emergency URN.
6.2. Systematic Interoperability Failures 6.2. Systematic Interoperability Failures
How can declarative service identification cause loss of How can declarative service identification cause loss of
interoperability? When an identifier is used to drive functionality interoperability? When an identifier is used to drive functionality
- such as dispatch on the phones, in the network, or QoS -- such as dispatch on the phones, in the network, or 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.
2 provides their users with a service they call, "text telephony", Domain 2 provides their users with a service they call "text
which is a voice service on a wireless device that also allows the telephony", which is a voice service on a wireless device that also
user to send text messages. Consider the case where domain 1 and allows the user to send text messages. Consider the case where
domain 2 both have their user agents insert a service identifiers domain 1 and domain 2 both have their user agents insert a service
into the request, and then use that to perform QoS authorization, identifier into the request, and then use that to perform QoS
accounting, and invocation of applications in the network and in the authorization, accounting, and invocation of applications in the
device. The user in domain 1 calls the user in domain 2, and inserts network and in the device. The user in domain 1 calls the user in
the identifier "Voice Chat" into the INVITE. When this arrives at domain 2, and inserts the identifier "Voice Chat" into the INVITE.
the server in domain 2, the service identifier is unknown. When this arrives at the server in domain 2, the service identifier
Consequently, the request does not get the proper QoS treatment, even is unknown. Consequently, the request does not get the proper QoS
if the call itself will succeed. treatment, even if the call itself will succeed.
If, on the other hand, derived service identification were used, the If, on the other hand, derived service identification were used, the
service identifier could be removed by domain 2, and then recomputed service identifier could be removed by domain 2, and then recomputed
based on the signaling to match its own notion of services. In this based on the signaling to match its own notion of services. In this
case, domain 2 could derive the "text telephony" identifier, and the case, domain 2 could derive the "text telephony" identifier, and the
request completes successfully. request completes successfully.
Declarative service identification, used between domains, causes 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, communication 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, if 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. That is why service identifier is no longer really appropriate. That is why
services need to be derived by signaling - because the signaling services need to be derived by signaling -- because the signaling
itself provides negotiation and interoperability between different itself provides negotiation and interoperability between different
domains. domains.
This illustrates another key aspect of the interoperability problem. This illustrates another key aspect of the interoperability problem.
Declarative service identification will result in inconsistencies Declarative service identification will result in inconsistencies
between its service identifiers and the results of any SIP between its service identifiers and the results of 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
(which is the case for declarative service identification), it (which is the case for declarative service identification), it
becomes equivalent to including a token in the Proxy-Require and 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 declarative service identification needs 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 service providers end up with the same
the same set of services, and give them the same names, becomes set of services, and give those services the same names, becomes
decreasingly small as the number of providers grow. Indeed, it would smaller and smaller as the number of providers grow. Indeed, it
almost certainly require a centralized authority to identify what the would almost certainly require a centralized authority to identify
services are, how they work, and what they are named. This, in turn, what the services are, how they work, and what they are named. This,
leads to a requirement for complete homogeneity in order to in turn, 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.
Declarative service identification leads to a requirement for Declarative service identification leads to a requirement for
homogeneity in service definitions across providers that homogeneity in service definitions across providers that
interconnect, ruining the very service heterogeneity that SIP was interconnect, ruining the very service heterogeneity that SIP was
meant to bring. 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 agree on 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.
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 accounting, and
QoS. A new provider gets the idea for a new service, say, avatar- provide QoS. A new provider gets the idea for a new service (say,
enhanced multimedia conversation. In this service, there is audio "avatar-enhanced multimedia conversation"). In this service, there
and video, but there is a third stream, which renders an avatar. A is audio and video, but there is a third stream, which renders an
caller can press buttons on their phone, to cause the avatar on the avatar. A caller can press buttons on their phone, to cause the
other person's device to show emotion, make noise, and so on. This avatar on the other person's device to show emotion, make noise, and
is similar to the way emoticons are used today in IM. This service so on. This is similar to the way emoticons are used today in IM.
is enabled by adding a third media stream (and consequently, third This service is enabled by adding a third media stream (and
m-line) to the SDP. consequently, a third m-line) to the SDP.
Normally, this service would be backwards compatible with a regular Normally, this service would be backwards-compatible with a regular
audio-video endpoint, which would just reject the third media stream. audio-video endpoint, which would just reject the third media stream.
However, because a large network has been deployed that is expecting However, because a large network has been deployed that is expecting
to see the token, "multimedia conversation" and its associated audio+ to see the token, "multimedia conversation" and its associated audio+
video service, it is nearly impossible for the new provider to roll video service, it is nearly impossible for the new provider to roll
out this new service. If they did, it would fail completely, or out this new service. If they did, it would fail completely, or
partially fail, when their users call users in other provider partially fail, when their users call users in other provider
domains. domains.
7. Recommendations 7. Recommendations
From these principles, several recommendations can be made. From these principles, several recommendations can be made.
7.1. Use Derived Service Identification 7.1. Use Derived Service Identification
Derived service identification - where an identifier for a service is Derived service identification -- where an identifier for a service
obtained by inspection of the signaling and other contextual data is obtained by inspection of the signaling and of other contextual
(such as subscriber profile) is reasonable, and when done properly, data (such as subscriber profile) -- is reasonable, and when done
does not lead to the perils described above. However, declarative properly, does not lead to the perils described above. However,
service identification - where user agents indicate what the service declarative service identification -- where user agents indicate what
is, separate from the rest of the signaling - leads to the perils the service is, separate from the rest of the signaling -- leads to
described above. the perils described above.
If it appears that the signaling currently defined in standards is 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, or may be because sufficient signaling to convey what is needed, or may be because
request URIs should be used for differentiation and they are not request URIs should be used for differentiation and they are not
being used. By applying the litmus tests described in Section 5.3, being used. By applying the litmus tests described in Section 5.3,
network designers can determine if the system is attempting to network designers can determine whether or not the system is
perform declarative service identification or not. attempting to perform declarative service identification.
7.2. Design for SIP's Negotiative Expressiveness 7.2. Design for SIP's Negotiative Expressiveness
One of SIP's key strengths is its ability to negotiate a common view One of SIP's key strengths is its ability to negotiate a common view
of a session between participants. This means that the service that of a session between participants. This means that the service that
is ultimately received can vary wildly, depending on the type of is ultimately received can vary wildly, depending on the types of
endpoints in the call and their capabilities. Indeed, this fact endpoints in the call and their capabilities. Indeed, this fact
becomes even more evident when calls are set up between domains. becomes even more evident when calls are set up between domains.
As such, when performing derived service identification, domains As such, when performing derived service identification, domains
should be aware that sessions may arrive from different networks and should be aware that sessions may arrive from different networks and
different endpoints. Consequently, the service identification different endpoints. Consequently, the service identification
algorithm must be complete - meaning it computes the best answer for algorithm must be complete -- meaning it computes the best answer for
any possible signaling message that might be received and any session any possible signaling message that might be received and any session
which might be set up. that might be set up.
In a homogeneous environment, the process of service identification In a homogeneous environment, the process of service identification
is easy. The service provider will know the set of services they are is easy. The service provider will know the set of services they are
providing, and based on the specific calls flows for each specific providing, and based on the specific call flows for each specific
service, can construct rules to differentiate one service from service, can construct rules to differentiate one service from
another. However, when different providers interconnect, or when another. However, when different providers interconnect, or when
different endpoitns are introduced, assumptions about what services different endpoints are introduced, assumptions about what services
are used, and how they are signaled, no longer apply. To provide the are used, and how they are signaled, no longer apply. To provide the
best user experience possible, a provider doing service best user experience possible, a provider doing service
identification needs to perform a 'best-match' operation, such that identification needs to perform a "best-match" operation, such that
any legal SIP signaling - not just the specific call flows running any legal SIP signaling -- not just the specific call flows running
within their own network amongst a limited set of endpoints - is within their own network amongst a limited set of endpoints -- is
mapped to the appropriate service. mapped to the appropriate service.
7.3. Presence 7.3. Presence
Presence can help a great deal with providing unique URIs for Presence can help a great deal with providing unique URIs for
different services. When a user wishes to contact another user, and different services. When a user wishes to contact another user, and
knows only the AOR for the target (which is usually the case), the knows only the AOR for the target (which is usually the case), the
user can fetch the presence document for the target. That document, user can fetch the presence document for the target. That document,
in turn, can contain numerous service URI for contacting the target in turn, can contain numerous service URIs for contacting the target
with different services. Those URI can then be used in the Request- with different services. Those URIs can then be used in the Request-
URI for differentiation. When possible, this is the best solution to URI for differentiation. When possible, this is the best solution to
the problem. the problem.
7.4. Intra-Domain 7.4. Intra-Domain
Service identifiers themselves are not bad; derived service Service identifiers themselves are not bad; derived service
identification allows each domain to cache the results of the service identification allows each domain to cache the results of the service
identification process for usage by another network element within identification process for usage by another network element within
the same domain. However, service identifiers are fundamentally the same domain. However, service identifiers are fundamentally
useful within a particular domain, and any such header must be useful within a particular domain, and any such header must be
skipping to change at page 22, line 24 skipping to change at page 21, line 37
identification and their associated service identifiers is always an identification and their associated service identifiers is always an
intra-domain operation. intra-domain operation.
7.5. Device Dispatch 7.5. Device Dispatch
Device dispatch should be done following the principles of [RFC3841], Device dispatch should be done following the principles of [RFC3841],
using implicit preferences based on the signaling. For example, using implicit preferences based on the signaling. For example,
[RFC5688] defines a new UA capability that can be used to dispatch [RFC5688] defines a new UA capability that can be used to dispatch
requests based on different types of application media streams. requests based on different types of application media streams.
However, it is is a mistake to try and use a service identifier as a However, it is a mistake to try and use a service identifier as a UA
UA capability. Consider a service called "multimedia telephony" capability. Consider a service called "multimedia telephony", which
which adds video to the existing PSTN experience. A user has two adds video to the existing PSTN experience. A user has two devices,
devices, one of which is used for multimedia telephony, and the other one of which is used for multimedia telephony and the other strictly
is used strictly for a voice-assisted game. It is tempting to have for a voice-assisted game. It is tempting to have the telephony
the telephony device include a UA capability [RFC3840] called device include a UA capability [RFC3840] called "multimedia
"multimedia telephony" in its registration. Then, a calling telephony" in its registration. A calling multimedia telephony
multimedia telephony device can then include the Accept-Contact device can then include the Accept-Contact header field [RFC3841]
header field [RFC3841] containing this feature tag. The proxy containing this feature tag. The proxy serving the called party,
serving the called party, applying the basic algorithms of [RFC3841] applying the basic algorithms of [RFC3841], will correctly route the
will correctly route the call to the terminating device. call to the terminating device.
However, if the calling party is not within the same domain, and the However, if the calling party is not within the same domain, and the
calling domain does not know about or use this feature tag, there calling domain does not know about or use this feature tag, there
will be no Accept-Contact header field, even if the calling party was will be no Accept-Contact header field, even if the calling party was
using a service that is a good match for 'multimedia telephony'. In using a service that is a good match for "multimedia telephony". In
such a case, the call may be delivered to both devices, yielded a such a case, the call may be delivered to both devices, but it will
poorer user experience. Thats because device dispatch was done using yield a poorer user experience. That's because device dispatch was
declarative service identification. done using declarative service identification.
The best way to avoid this problem is to use feature tags which can The best way to avoid this problem is to use feature tags that can be
be matched to well defined signaling features - media types, required matched to well-defined signaling features -- media types, required
SIP extensions and so on. In particular, the golden rule is that the SIP extensions, and so on. In particular, the golden rule is that
granularity of feature tags must be equivalent to the granularity of the granularity of feature tags must be equivalent to the granularity
individual features that can be signaled in SIP. of individual features that can be signaled in SIP.
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
declarative service identifiers inserted by a UA is not recommended. declarative service identifiers inserted by a UA is not recommended.
9. IANA Considerations 9. Acknowledgements
There are no IANA considerations associated with this specification.
10. Acknowledgements
This document is based on discussions with Paul Kyzivat and Andrew This document is based on discussions with Paul Kyzivat and
Allen, who contributed significantly to the ideas here. Much of the Andrew Allen, who contributed significantly to the ideas here. Much
content in this draft is a result of discussions amongst participants of the content in this document is a result of discussions amongst
in the SIPPING mailing list, including Dean Willis, Tom Taylor, Eric participants in the SIPPING mailing list, including Dean Willis,
Burger, Dale Worley, Christer Holmberg, and John Elwell, amongst many Tom Taylor, Eric Burger, Dale Worley, Christer Holmberg, and
others. Thanks to Spencer Dawkins, Tolga Asveren, Mahesh Anjanappa John Elwell, amongst many others. Thanks to Spencer Dawkins,
and Claudio Allochio for reviews of this document. Tolga Asveren, Mahesh Anjanappa, and Claudio Allochio for reviews of
this document.
11. Informational References 10. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006. July 2006.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)", of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006. RFC 4485, May 2006.
[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] [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-10 (work in Multimedia", Work in Progress, July 2009.
progress), July 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media [RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media
Feature Tag for MIME Application Subtypes", RFC 5688, Feature Tag for MIME Application Subtypes", RFC 5688,
January 2010. January 2010.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
skipping to change at page 24, line 38 skipping to change at page 23, line 43
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
jdrosen.net jdrosen.net
Monmouth, NJ Monmouth, NJ
US USA
Email: jdrosen@jdrosen.net EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
 End of changes. 113 change blocks. 
370 lines changed or deleted 362 lines changed or added

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