< draft-ietf-sipping-service-identification-03.txt   draft-ietf-sipping-service-identification-04.txt >
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Internet-Draft jdrosen.net
Intended status: Informational August 4, 2008 Intended status: Informational March 23, 2010
Expires: February 5, 2009 Expires: September 24, 2010
Identification of Communications Services in the Session Initiation Identification of Communications Services in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-service-identification-03 draft-ietf-sipping-service-identification-04
Abstract
This document considers the problem of service identification in the
Session Initiation Protocol (SIP). Service identification is the
process of determining the user-level use case that is driving the
signaling being utilized by the user agent. This document discusses
the uses of service identification, and outlines several
architectural principles behind the process. It identifies perils
when service identification is not done properly - including fraud,
interoperability failures and stifling of innovation. It then
outlines a set of reccomended practices for service identification.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 5, 2009. This Internet-Draft will expire on September 24, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract
This document considers the problem of service identification in the This document is subject to BCP 78 and the IETF Trust's Legal
Session Initiation Protocol (SIP). Service identification is the Provisions Relating to IETF Documents
process of determining the user-level use case that is driving the (http://trustee.ietf.org/license-info) in effect on the date of
signaling being utilized by the user agent. This document discusses publication of this document. Please review these documents
the uses of service identification, and outlines several carefully, as they describe your rights and restrictions with respect
architectural principles behind the process. It identifies perils to this document. Code Components extracted from this document must
when service identification is not done properly - including fraud, include Simplified BSD License text as described in Section 4.e of
interoperability failures and stifling of innovation. the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Services and Service Identification . . . . . . . . . . . . . 4 2. Services and Service Identification . . . . . . . . . . . . . 5
3. Example Services . . . . . . . . . . . . . . . . . . . . . . . 5 3. Example Services . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 5 3.1. IPTV vs. Multimedia . . . . . . . . . . . . . . . . . . . 7
3.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 6 3.2. Gaming vs. Voice Chat . . . . . . . . . . . . . . . . . . 7
3.3. Gaming vs. Voice Chat #2 . . . . . . . . . . . . . . . . . 6 3.3. Gaming vs. Voice Chat #2 . . . . . . . . . . . . . . . . . 8
3.4. Configuration vs. Pager Messaging . . . . . . . . . . . . 6 3.4. Configuration vs. Pager Messaging . . . . . . . . . . . . 8
4. Using Service Identification . . . . . . . . . . . . . . . . . 7 4. Using Service Identification . . . . . . . . . . . . . . . . . 9
4.1. Application Invocation in the User Agent . . . . . . . . . 7 4.1. Application Invocation in the User Agent . . . . . . . . . 9
4.2. Application Invocation in the Network . . . . . . . . . . 9 4.2. Application Invocation in the Network . . . . . . . . . . 10
4.3. Network Quality of Service Authorization . . . . . . . . . 9 4.3. Network Quality of Service Authorization . . . . . . . . . 11
4.4. Service Authorization . . . . . . . . . . . . . . . . . . 10 4.4. Service Authorization . . . . . . . . . . . . . . . . . . 11
4.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 10 4.5. Accounting and Billing . . . . . . . . . . . . . . . . . . 12
4.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 10 4.6. Negotiation of Service . . . . . . . . . . . . . . . . . . 12
4.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 11 4.7. Dispatch to Devices . . . . . . . . . . . . . . . . . . . 12
5. Key Principles of Service Identification . . . . . . . . . . . 11 5. Key Principles of Service Identification . . . . . . . . . . . 12
5.1. Services are a By-Product of Signaling . . . . . . . . . . 11 5.1. Services are a By-Product of Signaling . . . . . . . . . . 13
5.2. Identical Signaling Produces Identical Services . . . . . 12 5.2. Identical Signaling Produces Identical Services . . . . . 14
5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 14 5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 15
5.4. Explicit Service Identifiers are Redundant . . . . . . . . 14 5.4. Declarative Service Identifiers are Redundant . . . . . . 16
5.5. URIs are Key for Differentiated Signaling . . . . . . . . 14 5.5. URIs are Key for Differentiated Signaling . . . . . . . . 16
6. Perils of Declarative Service Identification . . . . . . . . . 15 6. Perils of Declarative Service Identification . . . . . . . . . 17
6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Systematic Interoperability Failures . . . . . . . . . . . 16 6.2. Systematic Interoperability Failures . . . . . . . . . . . 18
6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 18 6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 19
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Use Derived Service Identification . . . . . . . . . . . . 19 7.1. Use Derived Service Identification . . . . . . . . . . . . 20
7.2. Design for Heterogeneity . . . . . . . . . . . . . . . . . 19 7.2. Design for SIP's Negotiative Expressiveness . . . . . . . 21
7.3. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . . 22
7.5. Device Dispatch . . . . . . . . . . . . . . . . . . . . . 20 7.5. Device Dispatch . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. Informational References . . . . . . . . . . . . . . . . . . . 21 11. Informational References . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 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 hi fidelity music. It can manage video sessions,
ranging from small, "talking-head" style video chat, up to high ranging from small, "talking-head" style video chat, up to high
definition multipoint video conferencing, to low bandwidth user- definition multipoint video conferencing, to low bandwidth user-
skipping to change at page 4, line 8 skipping to change at page 5, line 8
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 explicit service invocation identification. Section 6 describes what declarative service
is, and how it can lead to fraud, interoperability failures, and invocation is, and how it can lead to fraud, interoperability
stifling of service innovation. failures, and stifling of service innovation.
Consequently, this document concludes that declarative service
identification - the process by which a user agent inserts a moniker
into a message that defines the desired service, separate from
explicit and well-defiend protocol mechanisms, is harmful.
Instead of performing declarative service identification, this
document recommends derived service identification, and gives several
reccomendations around it in Section 7:
1. The identity of a service should always be derived from the
explicit signaling in the protocol messages and other contextual
information, and never indicated by the user through a separate
identifier placed into the message.
2. The process of service identification based on signaling messages
must be designed to SIP's negotiative expressiveness, and
therefore handle heterogeneity and not assume a fixed set of use
cases.
3. Presence can help in providing URIs that can be utilized to
connect to specific services, thereby creating explicit
indications in the signaling which can be used to dervice a
service identity.
4. Service identities placed into signaling messages for the
purposes of caching the service identity are strictly for intra-
domain usage.
5. Device dispatch should be based on feature-tags which map to
well-defined SIP extensions and capabilities, and not 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
skipping to change at page 8, line 30 skipping to change at page 9, line 50
| +-----------------------------+ | | +-----------------------------+ |
| | | |
+---------------------------------+ +---------------------------------+
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
request 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 analagous to the way web servers frequently work. An HTTP server
listens on port 80 for requests, and based on the HTTP Request-URI, listens on port 80 for requests, and based on the HTTP Request-URI,
dispatches the request to a number of disparate applications. The dispatches the request to a number of disparate applications. The
same is happening here. For the example services in Section 3.2, an same is happening here. For the example services in Section 3.2, an
incoming INVITE for the gaming service would be delivered to the incoming INVITE for the gaming service would be delivered to the
gaming application software. An incoming INVITE for the voice chat gaming application software. An incoming INVITE for the voice chat
service would be delivered to the voice chat application software. service would be delivered to the voice chat application software.
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
skipping to change at page 9, line 46 skipping to change at page 11, line 14
purposes might contain an XML document that uses the token "stock" as purposes might contain an XML document that uses the token "stock" as
some kind of attribute. This configuration update would be discarded some kind of attribute. This configuration update would be discarded
by the filtering server, when it should not have been. by the filtering server, when it should not have been.
4.3. Network Quality of Service Authorization 4.3. Network Quality of Service Authorization
The IP network can provide differing levels of Quality of Service The IP network can provide differing levels of Quality of Service
(QoS) to IP packets. This service can include guaranteed throughput, (QoS) to IP packets. This service can include guaranteed throughput,
latency, or loss characteristics. Typically, the user agent will latency, or loss characteristics. Typically, the user agent will
make some kind of QoS request, either using explicit signaling make some kind of QoS request, either using explicit signaling
protocols (such as RSVP) or through marking of Diffserv value in protocols (such as RSVP [RFC2205]) or through marking of Diffserv
packets. The network will need to make a policy decision based on value in packets. The network will need to make a policy decision
whether these QoS treatments are authorized or not. One common based on whether these QoS treatments are authorized or not. One
authorization policy is to check if the user has invoked a service common authorization policy is to check if the user has invoked a
using SIP that they are authorized to invoke, and that this service service using SIP that they are authorized to invoke, and that this
requires the level of QoS treatment the user has requested. 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 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
skipping to change at page 11, line 38 skipping to change at page 13, line 12
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. Explicit 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 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
skipping to change at page 13, line 49 skipping to change at page 15, line 24
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 [I-D.ietf-sip-gruu]). Indeed, the example, a GRUU can be used [RFC5627]). Indeed, the gaming chat
gaming chat is not targeting the USER - its targeting the gaming is not targeting the USER - its targeting the gaming instance on
instance on the phone. Thus, if a special GRUU is used for the the phone. Thus, if a special GRUU is used for the gaming chat,
gaming chat, this makes the signaling different between these two this makes the signaling different between these two services.
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 which tries to
intelligently guess at what the user intended. It is contrast to "Do intelligently guess at what the user intended. It is contrast to "Do
skipping to change at page 14, line 38 skipping to change at page 16, line 13
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 which 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, its DWIM. If its the former,
its DWIS. its DWIS.
5.4. Explicit Service Identifiers are Redundant 5.4. Declarative Service Identifiers are Redundant
Because an explicit 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 an explicit 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 which is being targeted
is not, in fact, the user. Rather, it is a resource that is linked is not, in fact, the user. Rather, it is a resource that is linked
skipping to change at page 16, line 21 skipping to change at page 17, line 46
IPTV, but at the cost of multimedia conferencing. IPTV, but at the cost of multimedia conferencing.
This same principle shows up in other places. For example, in the This same principle shows up in other places. For example, in the
identification of an emergency services call identification of an emergency services call
[I-D.ietf-ecrit-framework]. It is desirable to give emergency [I-D.ietf-ecrit-framework]. It is desirable to give emergency
services calls special treatment, such as being free, authorized even services calls special treatment, such as being free, authorized even
when the user cannot otherwise make calls, and to give them priority. when the user cannot otherwise make calls, and to give them priority.
If emergency calls where indicated through something other than the If emergency calls where indicated through something other than the
target of the call being an emergency services URN [RFC5031], it target of the call being an emergency services URN [RFC5031], it
would open an avenue for fraud. The user could place any desired URI would open an avenue for fraud. The user could place any desired URI
in the request-URI, and indicate that the call is an emergency in the request-URI, and indicate separately, through a declarative
services call. This could would then get special treatment, but of identifier, that the call is an emergency services call. This could
course get routed to the target URI. The only way to prevent this would then get special treatment, but of course get routed to the
fraud is to consider an emergency call as any call whose target is an target URI. The only way to prevent this fraud is to consider an
emergency services URN. Thus, the service identification here is emergency call as any call whose target is an emergency services URN.
based on the target of the request. When the target is an emergency Thus, the service identification here is based on the target of the
services URN, the request can get special treatment. The user cannot request. When the target is an emergency services URN, the request
lie, since there is no way to separately indicate this is an can get special treatment. The user cannot lie, since there is no
emergency call, besides targeting it to an emergency URN. way to separately indicate this is an emergency call, besides
targeting it to an 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
skipping to change at page 17, line 11 skipping to change at page 18, line 36
the server in domain 2, the service identifier is unknown. the server in domain 2, the service identifier is unknown.
Consequently, the request does not get the proper QoS treatment, even Consequently, the request does not get the proper QoS treatment, even
if the call itself will succeed. if the call itself will succeed.
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, communications is still provided.
As another example, if one agent initiates a Push-To-Talk session As another example, if one agent initiates a Push-To-Talk session
(which is audio with a companion floor control mechanism), and the (which is audio with a companion floor control mechanism), and the
skipping to change at page 19, line 37 skipping to change at page 21, line 15
described above. 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 if the system is attempting to
perform declarative service identification or not. perform declarative service identification or not.
7.2. Design for Heterogeneity 7.2. Design for SIP's Negotiative Expressiveness
When performing derived service identification, domains should be One of SIP's key strengths is its ability to negotiate a common view
aware that sessions may arrive from different networks and different of a session between participants. This means that the service that
endpoints. Consequently, the service identification algorithm must is ultimately received can vary wildly, depending on the type of
be complete - meaning it computes the best answer for any possible endpoints in the call and their capabilities. Indeed, this fact
signaling message that might be received. becomes even more evident when calls are set up between domains.
As such, when performing derived service identification, domains
should be aware that sessions may arrive from different networks and
different endpoints. Consequently, the service identification
algorithm must be complete - meaning it computes the best answer for
any possible signaling message that might be received and any session
which 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 calls 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 two different providers interconnect, another. However, when different providers interconnect, or when
assumptions about what services are used, and how they are signaled, different endpoitns are introduced, assumptions about what services
no longer apply. To provide the best user experience possible, a are used, and how they are signaled, no longer apply. To provide the
provider doing service identification needs to perform a 'best-match' best user experience possible, a provider doing service
operation, such that any legal SIP signaling - not just the specific identification needs to perform a 'best-match' operation, such that
call flows running within their own network - is mapped to the any legal SIP signaling - not just the specific call flows running
appropriate service. within their own network amongst a limited set of endpoints - is
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 URI for contacting the target
with different services. Those URI can then be used in the Request- with different services. Those URI 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
skipping to change at page 20, line 36 skipping to change at page 22, line 21
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
stripped at a network boundary. Consequently, the process of service stripped at a network boundary. Consequently, the process of service
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,
[I-D.rosenberg-sip-app-media-tag] defines a new UA capability that [RFC5688] defines a new UA capability that can be used to dispatch
can be used to dispatch requests based on different types of requests based on different types of application media streams.
application media streams.
However, it is is a mistake to try and use a service identifier as a However, it is is a mistake to try and use a service identifier as a
UA capability. Consider a service called "multimedia telephony" UA capability. Consider a service called "multimedia telephony"
which adds video to the existing PSTN experience. A user has two which adds video to the existing PSTN experience. A user has two
devices, one of which is used for multimedia telephony, and the other devices, one of which is used for multimedia telephony, and the other
is used strictly for a voice-assisted game. It is tempting to have is used strictly for a voice-assisted game. It is tempting to have
the telephony device include a UA capability [RFC3840] called the telephony device include a UA capability [RFC3840] called
"multimedia telephony" in its registration. Then, a calling "multimedia telephony" in its registration. Then, a calling
multimedia telephony device can then include the Accept-Contact multimedia telephony device can then include the Accept-Contact
header field [RFC3841] containing this feature tag. The proxy header field [RFC3841] containing this feature tag. The proxy
skipping to change at page 21, line 26 skipping to change at page 23, line 12
granularity of feature tags must be equivalent to the granularity of granularity of feature tags must be equivalent to the granularity of
individual features that can be signaled in SIP. 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
explicit service identifiers inserted by a UA is not recommended. declarative service identifiers inserted by a UA is not recommended.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
10. Acknowledgements 10. Acknowledgements
This document is based on discussions with Paul Kyzivat and Andrew This document is based on discussions with Paul Kyzivat and Andrew
Allen, who contributed significantly to the ideas here. Much of the Allen, who contributed significantly to the ideas here. Much of the
content in this draft is a result of discussions amongst participants content in this draft is a result of discussions amongst participants
skipping to change at page 22, line 22 skipping to change at page 24, line 6
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-05 (work in Multimedia", draft-ietf-ecrit-framework-10 (work in
progress), February 2008. progress), July 2009.
[I-D.ietf-sip-gruu] [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol
Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[I-D.rosenberg-sip-app-media-tag] [RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media
Rosenberg, J., "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", RFC 5688,
Feature Tag for MIME Application Sub-Types", January 2010.
draft-rosenberg-sip-app-media-tag-02 (work in progress),
November 2007.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco jdrosen.net
Edison, NJ Monmouth, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
118 lines changed or deleted 166 lines changed or added

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