draft-ietf-sipping-service-identification-02.txt   draft-ietf-sipping-service-identification-03.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational July 14, 2008 Intended status: Informational August 4, 2008
Expires: January 15, 2009 Expires: February 5, 2009
Identification of Communications Services in the Session Initiation Identification of Communications Services in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-service-identification-02 draft-ietf-sipping-service-identification-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on February 5, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document considers the problem of service identification in the This document considers the problem of service identification in the
Session Initiation Protocol (SIP). Service identification is the Session Initiation Protocol (SIP). Service identification is the
process of determining the user-level use case that is driving the process of determining the user-level use case that is driving the
skipping to change at page 2, line 34 skipping to change at page 2, line 34
5.1. Services are a By-Product of Signaling . . . . . . . . . . 11 5.1. Services are a By-Product of Signaling . . . . . . . . . . 11
5.2. Identical Signaling Produces Identical Services . . . . . 12 5.2. Identical Signaling Produces Identical Services . . . . . 12
5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 14 5.3. Do What I Say, not What I Mean . . . . . . . . . . . . . . 14
5.4. Explicit Service Identifiers are Redundant . . . . . . . . 14 5.4. Explicit Service Identifiers are Redundant . . . . . . . . 14
5.5. URIs are Key for Differentiated Signaling . . . . . . . . 14 5.5. URIs are Key for Differentiated Signaling . . . . . . . . 14
6. Perils of Declarative Service Identification . . . . . . . . . 15 6. Perils of Declarative Service Identification . . . . . . . . . 15
6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Fraud . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Systematic Interoperability Failures . . . . . . . . . . . 16 6.2. Systematic Interoperability Failures . . . . . . . . . . . 16
6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 18 6.3. Stifling of Service Innovation . . . . . . . . . . . . . . 18
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7.1. Use Derived Service Identification . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.2. Design for Heterogeneity . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Informational References . . . . . . . . . . . . . . . . . . . 20 7.4. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.5. Device Dispatch . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. Informational References . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
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 19, line 17 skipping to change at page 19, line 17
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.
o Systems needing to perform service identification must examine 7.1. Use Derived Service Identification
existing signaling constructs to identify the service based on
fields that exist within the signaling message already.
o If it appears that the signaling currently defined in standards is Derived service identification - where an identifier for a service is
obtained by inspection of the signaling and other contextual data
(such as subscriber profile) is reasonable, and when done properly,
does not lead to the perils described above. However, declarative
service identification - where user agents indicate what the service
is, separate from the rest of the signaling - leads to the perils
described above.
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 because sufficient signaling to convey what is needed, or may be because
request URIs should be used for differentiation. request URIs should be used for differentiation and they are not
being used. By applying the litmus tests described in Section 5.3,
network designers can determine if the system is attempting to
perform declarative service identification or not.
o When performing derived service identification, domains should be 7.2. Design for Heterogeneity
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.
o Presence can help a great deal with providing unique URIs for When performing derived service identification, domains should be
different services. When a user wishes to contact another user, aware that sessions may arrive from different networks and different
and knows only the AOR for the target (which is usually the case), endpoints. Consequently, the service identification algorithm must
the user can fetch the presence document for the target. That be complete - meaning it computes the best answer for any possible
document, in turn, can contain numerous service URI for contacting signaling message that might be received.
the target with different services. Those URI can then be used in
the Request-URI for differentiation. When possible, this is the
best solution to the problem.
o Service identifiers themselves are not bad; derived service In a homogeneous environment, the process of service identification
identification allows each domain to cache the results of the is easy. The service provider will know the set of services they are
service identification process for usage by another network providing, and based on the specific calls flows for each specific
element within the same domain. However, service identifiers are service, can construct rules to differentiate one service from
fundamentally useful within a particular domain, and any such another. However, when two different providers interconnect,
header must be stripped at a network boundary. assumptions about what services are used, and how they are signaled,
no longer apply. To provide the best user experience possible, a
provider doing service identification needs to perform a 'best-match'
operation, such that any legal SIP signaling - not just the specific
call flows running within their own network - is mapped to the
appropriate service.
o Device dispatch should be done following the principles of 7.3. Presence
[RFC3841], using implicit preferences based on the signaling. For
example, [I-D.rosenberg-sip-app-media-tag] defines a new UA Presence can help a great deal with providing unique URIs for
capability that can be used to dispatch requests based on different services. When a user wishes to contact another user, and
different types of application media streams. knows only the AOR for the target (which is usually the case), the
user can fetch the presence document for the target. That document,
in turn, can contain numerous service URI for contacting the target
with different services. Those URI can then be used in the Request-
URI for differentiation. When possible, this is the best solution to
the problem.
7.4. Intra-Domain
Service identifiers themselves are not bad; derived service
identification allows each domain to cache the results of the service
identification process for usage by another network element within
the same domain. However, service identifiers are fundamentally
useful within a particular domain, and any such header must be
stripped at a network boundary. Consequently, the process of service
identification and their associated service identifiers is always an
intra-domain operation.
7.5. Device Dispatch
Device dispatch should be done following the principles of [RFC3841],
using implicit preferences based on the signaling. For example,
[I-D.rosenberg-sip-app-media-tag] defines a new UA capability that
can be used to dispatch requests based on different types of
application media streams.
However, it is is a mistake to try and use a service identifier as a
UA capability. Consider a service called "multimedia telephony"
which adds video to the existing PSTN experience. A user has two
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
the telephony device include a UA capability [RFC3840] called
"multimedia telephony" in its registration. Then, a calling
multimedia telephony device can then include the Accept-Contact
header field [RFC3841] containing this feature tag. The proxy
serving the called party, applying the basic algorithms of [RFC3841]
will correctly route the call to the terminating device.
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
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
such a case, the call may be delivered to both devices, yielded a
poorer user experience. Thats because device dispatch was done using
declarative service identification.
The best way to avoid this problem is to use feature tags which can
be matched to well defined signaling features - media types, required
SIP extensions and so on. In particular, the golden rule is that the
granularity of feature tags must be equivalent to the granularity of
individual features that can be signaled in SIP.
8. Security Considerations 8. Security Considerations
Oftentimes, the service associated with a request is utilized for Oftentimes, the service associated with a request is utilized for
purposes such as authorization, accounting, and billing. When purposes such as authorization, accounting, and billing. When
service identification is not done properly, the possibility of service identification is not done properly, the possibility of
unauthorized service use and network fraud is introduced. It is for unauthorized service use and network fraud is introduced. It is for
this reason, discussed extensively in Section 6.1, that the usage of this reason, discussed extensively in Section 6.1, that the usage of
explicit service identifiers inserted by a UA is not recommended. explicit service identifiers inserted by a UA is not recommended.
skipping to change at page 21, line 36 skipping to change at page 22, line 45
November 2007. November 2007.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[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,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
 End of changes. 13 change blocks. 
41 lines changed or deleted 107 lines changed or added

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