Internet DRAFT - draft-donovan-sipping-service-override
draft-donovan-sipping-service-override
SIPPING S. Donovan
Internet-Draft C. Sivachelvan
Expires: December 25, 2006 Cisco Systems
June 23, 2006
The Service-State Header
draft-donovan-sipping-service-override-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of 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
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document proposes a new header for the Session Initiation
Protocol. This header, the Service-State header, is used to
communicate application state between two SIP elements.
Note: The name of the file will be updated to be consistent with the
proposed header name in the next revision of the draft.
Donovan & Sivachelvan Expires December 25, 2006 [Page 1]
Internet-Draft The Service-State Header June 2006
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Donovan & Sivachelvan Expires December 25, 2006 [Page 2]
Internet-Draft The Service-State Header June 2006
2. Introduction
RFC 3261 [1] proposes a deployment architecture for SIP based network
referred to as the SIP trapezoid. This model shown in the following
figure, shows the relationship between the SIP clients and the SIP
proxy servers involved in routing of requests between the clients.
+------+ +------+
|Alice | SIP | Bob |
|Domain|-----------|Domain|
|Proxy | |Proxy |
+------+ +------+
/ \
/SIP SIP\
/ \
+------+ +------+
|Alice | RTP | Bob |
|Client|-------------------|Client|
| | | |
+------+ +------+
In this model, Alice's clients sends all SIP communication through
Alice's proxy. Bob's client does the same. As a result, a SIP
request from Alice's client to Bob's client flows from Alice's client
through Alice's proxy, then through Bob's proxy and then to Bob's
client. The proxies play a number of roles for the client. These
roles are discussed in RFC 3261.
Deployments of SIP based networks have extended on the SIP trapezoid
model to allow for the separation between the basic routing functions
of the proxies required in the basic SIP trapezoid model and
applications that are involved in the delivery of SIP based services.
The extended SIP trapezoid model looks as follows:
Donovan & Sivachelvan Expires December 25, 2006 [Page 3]
Internet-Draft The Service-State Header June 2006
+------+ +------+
|Alice | | Bob |
| Appl | | Appl |
|Server| |Server|
+------+ +------+
| |
|SIP SIP|
| |
+------+ +------+
|Alice | SIP | Bob |
|Domain|-----------|Domain|
|Proxy | |Proxy |
+------+ +------+
/ \
/SIP SIP\
/ \
+------+ +------+
|Alice | Media | Bob |
|Client|-------------------|Client|
| | | |
+------+ +------+
In this model, there is an application server associated with Alice
and an application server associated with Bob. Service requests are
optionally routed through the application server to apply application
specific logic. Note that in this architecture, there can be
multiple application servers for Alice and multiple for Bob.
This document proposes and extension to SIP. This extension defines
a mechanism for the application server to includes state in the SIP
messages flowing between the proxy and the application server. This
state can be used by the proxy when it is determining how to route
the SIP requests after they have been handled by the application
server.
Donovan & Sivachelvan Expires December 25, 2006 [Page 4]
Internet-Draft The Service-State Header June 2006
3. The Extended SIP Trapezoid
The Extended SIP Trapezoid is a SIP deployment architecture that
facilitates the separation of SIP routing functions from SIP
application functions.
This architecture allows application developers to focus on the
application logic without the need to understand the intricacies of
the SIP protocol.
This model separates the processing of the proxies in the classical
SIP trapezoid into two logical functions, the Service Manager (SM)
and the Application Server (AS). In general, both the SM and the AS
are specialized SIP proxies handling unique functionality. However,
both can also be implemented as B2BUAs should it be required to meet
individual deployment scenarios. In addition, the AS can be deployed
as a redirect server if it fits the requirements of the application
being deployed.
The following figure shows the extended SIP trapezoid architecture.
+------+ +------+
| | | |
| oAS | | tAS |
| | | |
+------+ +------+
| |
|SIP SIP|
| |
+------+ +------+
| | SIP | |
| oSM |-----------| tSM |
| | | |
+------+ +------+
/ \
/SIP SIP\
/ \
+------+ +------+
| | Media | |
| oUA |-------------------| tUA |
| | | |
+------+ +------+
The following is a description of each of the elements in the
architecture:
Donovan & Sivachelvan Expires December 25, 2006 [Page 5]
Internet-Draft The Service-State Header June 2006
o oUA - Originating User Agent - The user agent for the client
originating the service request.
o oSM - Originating Server Manager - The Service Manager responsible
for the handling of service requests for the oUA. This can either
be statically assigned to the oUA or dynamically assigned when the
oUA registers.
o oAS - Originating Application Server - An Application Server
applying an originating application, an application for the
originating user, to the service request. There can be zero, one
or more oASs invoked for an individual service request.
o tSM - Terminating Service Manager - The Service Manager
responsible for the handling of service requests for the target
user. As with the oSM, this can either be statically assigned to
the tUA or dynamically assigned when the tUA registers.
o tAS - Terminating Application Server - An Application Server
applying a terminating application, an application for the target
user, to the service request. There can be zero, one or more tASs
invoked for an individual service request.
o tUA - Terminating User Agent - The user agent that is the target
of the service request. If the tUA is registered then service
requests to the target URI are routed to the tUA.
In this model, the Service Manager is responsible for the following:
o Authentication of the originator of service requests;
o Authorization of service requests;
o Routing of service requests to Application Servers;
This is based on the context of the service request. This
context can include things like the content of the service
request and provisioned data about the originator or target of
the service request.
The SM can chose to route a service request to multiple
Application Servers. This is referred to as chaining of
applications
o Routing of service requests between the originating SM and the
terminating SM;
Donovan & Sivachelvan Expires December 25, 2006 [Page 6]
Internet-Draft The Service-State Header June 2006
o Routing of service requests to the target URI. This can be to a
SIP end-point using SIP Registrar state, to a proxy in another
administrative domain or to a gateway device for requests that are
targeted for a non SIP destination (for example, a SIP to ISUP
gateway).
The Application Server applies application specific logic to the
service request before sending (via a proxy or B2BUA model) the
request back to the SM. This can include applying application
specific routing, retargeting the request to one or more users,
redirecting the request to a new user and rejecting the request.
The following is the general model for interactions between the SM
and the AS:
+------+ +------+
| | | |
| oAS | | tAS |
| | | |
+------+ +------+
^ | ^ |
2| |3 5| |6
| v | v
+------+ +------+
| | 4 | |
| oSM |---------->| tSM |
| | | |
+------+ +------+
^ |
1| |7
| v
+------+ +------+
| | | |
| oUA | | tUA |
| | | |
+------+ +------+
The following steps are taken in handling of a service request in
this model:
1. A service request is routed to the oSM. There may be zero, one
or more other SIP proxies between the oUA and the oSM. This
service request is authenticated either by the oSM or by a SIP
element that handled the request prior to the oSM.
2. The oSM authorized the service request and, based on the contents
of the service request and other inputs, such as a subscriber
Donovan & Sivachelvan Expires December 25, 2006 [Page 7]
Internet-Draft The Service-State Header June 2006
profile for the originator of the service request, determines
where to route the request. In this case, the request is routed
to the oAS. Note that the oSM might route the service request to
multiple oASs.
3. The oAS processes the service request and routes it back to the
oSM.
4. The oSM determines that there are no other Application Servers
that need to handle the service request. As a result, the oSM
routes the request to the tSM. If the request was targeted for a
different domain then the oSM would have routed the request to
the appropriate server for the target domain. If it had
determined that the request should be routed through multiple
application servers then it would have proxied the request to the
next AS.
5. The tSM uses the content of the request and other information,
such as a subscriber profile for the target of the request, to
determine where to route the request. In this case, the tSM
determines that the request needs to be routed to the tAS. As
was the case for originating applications, the tSM can route the
request to multiple terminating applications.
6. The tAS processes the service request and routes it back to the
tSM.
7. The tSM determines that there are no additional terminating
applications to which the request is to be routed and, as such,
routes the request to the tUA. This is done by routing to the
contacts registered to the target URI contained in the request-
URI.
3.1. Definitions
Originator Identity (OID) - The identity of the originator or a
service request. The OID is determined based on authentication of
the user and is indicated in the P-Asserted-ID [3] header or in the
Identity [4] header.
Request Target - The target of a request is the URI contained in the
request-URI.
Request Retargeting - A request is retargeted if the request-URI is
modified but the request is still meant to be routed to the same
user. Contact routing is an example of request retargeting.
Redirection - A request is redirected if the user to which the
Donovan & Sivachelvan Expires December 25, 2006 [Page 8]
Internet-Draft The Service-State Header June 2006
request is to be routed is changed. Call forwarding is an example of
redirection. In this case, a call from Alice to Bob is forwarded, or
redirected, by Bob to Carol. This represents two separate "call
legs", one from Alice to Bob and one from Bob to Carol. In some
scenarios, applications need to be applied to these two call legs
separately.
The reference to a call leg above is not meant to map to the
concept of a call leg in the PSTN, where there is a media path
established for each call leg. It is also not meant to map to the
concept of a dialog in SIP, as redirection can result in multiple
of these call legs within a single dialog. This call leg is a
virtual concept to reflect that Alice called Bob is a separate
call from the redirection that results in a call from Bob to
Carol.
Donovan & Sivachelvan Expires December 25, 2006 [Page 9]
Internet-Draft The Service-State Header June 2006
4. Interaction between the oSM and oAS
In the basic case, the oAS will apply application logic to the
request. The oAS can then do one of the following:
o Reject the request due to application specific logic.
o Redirect the request using the appropriate 300-class response.
o Handle the request as a UAS.
o Proxy the request back to the oSM.
o Re-originate the request back to the oSM, acting as a B2BUA.
In the cases where the oAS returns the request to the oSM, it can
also change information contained in the request. For instance, the
oSM could retarget the request, changing the address in the request-
URI.
An example service for this model is an outbound call blocking (OCB)
service. For instance, a service provider might offer a service to a
user to have all calls to paid services (for example, 900 numbers in
World Zone 1) blocked. If this service is active for the originating
user then the OCB service would reject a service request if it were
to a paid service. If not, it would proxy the request unchanged.
Note: Normal SIP proxy changes would still be applied by the oAS.
Unchanged in this context means the originating and target
identities are not changed.
There are also instances were the oAS will retarget the request by
changing the Request URI.
A private numbering plan service is an example where this would be
the case. In this case the oAS would examine digits in the
Request-URI and modify them based on the numbering plan. This
might result in a short private dialing string being modified to a
fully qualified E.164 number.
4.1. oSM Handling of a retargeted request
The oSM had the following alternatives for handling the retargeting
of a request by the oAS:
o Continue originating processing for the OID
Donovan & Sivachelvan Expires December 25, 2006 [Page 10]
Internet-Draft The Service-State Header June 2006
This is the most likely scenario.
o Skip to the end of originating processing for the OID
o Restart originating processing for the OID
An outbound call blocking feature is an example of when this
might be required.
In order to understand the correct action to take, the oSM might need
information on why the request was retargeted. There is currently no
mechanism in SIP for doing so. This is one of the motivations for
the extension proposed in this document.
Donovan & Sivachelvan Expires December 25, 2006 [Page 11]
Internet-Draft The Service-State Header June 2006
5. Interaction between tSM and tAS
As with the oAS, in the basic case, the tAS will apply application
logic to the request. The tAS can then do one of the following:
o Reject the request due to application specific logic.
o Redirect the request using the appropriate 300-class response.
o Handle the request as a UAS.
o Proxy the request back to the tSM.
o Re-originate the request back to the tSM, acting as a B2BUA.
In the basic case, the tAS will apply application logic to the
request and either reject the request or proxy the request back to
the tSM with the identities of the originator and target unchanged.
An example service where this might apply is an incoming call
screening (ICS) service. For instance, a service provider might
offer a service to allow a user to maintain a list of addresses from
which the target user will not accept calls. If this service is
active for the target user then the ICS service would reject a
service request if the OID is included in the targets screening list.
If not, it would proxy the request unchanged.
Note: Normal SIP proxy changes would still be applied by the tAS.
Unchanged in this context means the originating and target
identities are not changed.
There are instances where the tAS will retarget the request by
changing the value of the Request-URI.
For example, a service provider might offer a service where a user
can have multiple phone numbers (alias's) or other URIs for a
single device. The tAS would retarget the request from an alias
URI to the "master" URI for the device.
There are also instances where the tAS will redirect the request.
This results in the value of the Request-URI being changed. It also
results in the identity of the redirecting user being included in the
proxied request as the OID for the call leg from the redirecting user
to the new target URI.
Note: One method for indicating the identity of the redirecting
user is the use of the Diversion header defined in [5]. It is
also possible that use of the History mechanism defined in [6]
Donovan & Sivachelvan Expires December 25, 2006 [Page 12]
Internet-Draft The Service-State Header June 2006
could be used.
Call forwarding, in its various flavors, are example services that
result in redirection.
Second Note: This is different from redirecting the request using
a SIP defined 300-class redirection response. An application
would handle the redirection directly, as discussed here, if it
needs to be in the path of responses to the request or if it needs
to be in the path of mid-dialog requests for requests that result
in dialogs being established. Sending a 300-class response takes
the AS out of the signaling path for responses and subsequent mid-
dialog requests.
5.1. tSM handling of changed OID
Changing of the OID, by adding a new OID, for example by using a
Diversion header, to the existing OID(s) is one method that the tSM
can identify the request as having been redirected. The handling
options for this are outlined in the section on tSM handling of a
redirected request.
5.2. tSM handling of retargeting
The tSM has the following options for handling the case where the tAS
retargets a request:
o Continue terminating processing for the original target URI
This is the most likely alternative
o Skip to the end of terminating processing for the original target
URI and continue with contact routing. This has the result of not
routing the request to other tASs that would have been invoked
otherwise.
o Restart terminating processing for the new Request-URI
This might me necessary of the service profiles for the
original target URI and the new retargeted URI are different.
For instance, the service profile for the original target URI
might only result in the retargeting where the service profile
for the new target URI might have call forwarding logic
associated with it.
Donovan & Sivachelvan Expires December 25, 2006 [Page 13]
Internet-Draft The Service-State Header June 2006
5.3. tSM handling of redirection
The tSM has the following options for the handling of the case where
the tAS redirects a request:
o Abort terminating processing for the original target Request-URI
and initiate originating processing for the redirecting OID.
For instance, the OCB feature might be invoked to determine if
the redirecting user, as indicated by the redirecting OID, is
authorized to make a call to the new address included in the
Request-URI.
The following diagram illustrates this type of handling of a
redirection:
+------+ +------+ +------+ +------+
| | | | | | | |
| oAS1 | | tAS2 | | oAS2 | | tAS3 |
| | | | | | | |
+------+ +------+ +------+ +------+
^ | ^ | ^ | ^ |
2| |3 5| |6 8| |9 11| |12
| v | v | v | v
+------+ +------+ +------+ +------+
| | 4 | | 7 | | 10 | |
| oSM1 |---------->| tSM2 |---------->| oSM2 |---------->| tSM3 |
| | | | | | | |
+------+ +------+ +------+ +------+
^ |
1| |13
| v
+------+ +------+
| | | |
| oUA1 | | tUA3 |
| | | |
+------+ +------+
o Abort terminating processing for the target Request-URI and route
the request to the new Request-URI
This skips originating processing for the call from the
redirecting OID to the new target.
Donovan & Sivachelvan Expires December 25, 2006 [Page 14]
Internet-Draft The Service-State Header June 2006
The following diagram illustrates this type of handling of a
redirection:
+------+ +------+ +------+
| | | | | |
| oAS1 | | tAS2 | | tAS3 |
| | | | | |
+------+ +------+ +------+
^ | ^ | ^ |
2| |3 5| |6 8| |9
| v | v | v
+------+ +------+ +------+
| | 4 | | 7 | |
| oSM1 |---------->| tSM2 |---------->| tSM3 |
| | | | | |
+------+ +------+ +------+
^ |
1| |10
| v
+------+ +------+
| | | |
| oUA1 | | tUA3 |
| | | |
+------+ +------+
In order to understand the correct action to take, the tSM might need
information on why the request was retargeted. There is currntly no
mechanism in SIP for doing so. This is one of the motivations for
the extension proposed in this document.
5.4. SM selection of next application
One of the jobs of the SM is to determine what applications to invoke
for a given service request. The selection of the initial
application can be done based on the context known at the time that
the service request was received. As stated previously, this can be
based on the content of the service request. It can also be based on
provisioned data about the user that originated the request or the
user that is the target of the request.
The challenge becomes determining the application that should be
invoked after the first, or more generally, after any application has
finished handling a request. This decision can take the original
context of the service request into consideration. However, there
are situations where the decision also needs to be made based on the
results of application, or applications, that have already handled
the request.
Donovan & Sivachelvan Expires December 25, 2006 [Page 15]
Internet-Draft The Service-State Header June 2006
For example, consider the case where the following is the desired
application logic for a given service request:
1. Invoke application 1
2. If application 1 is successful with result of foo then invoke
application 2
3. If application 1 is successful with result of bar then invoke
application 3
As another example, consider the case where the following logic is
the desired application logic:
1. If application 1 is not successful for reason foo then invoke
application 2
2. If application 1 is not successful for reason bar then invoke
appliation 3
3. If application 1 is not successful for all other reasons then
reject the service request with reason xyz.
One of the purposes of this document is to define a standard
mechanism for the AS to communicate success or failure of an
application along with result state to the SM.
Donovan & Sivachelvan Expires December 25, 2006 [Page 16]
Internet-Draft The Service-State Header June 2006
6. Proposed Service-State Header
This document proposes an extension to the Session Initiation
Protocol to facilitate the interaction between the Service Manager
function and the Application Server function.
This extension give the AS a mechanism to inform the SM of the action
that the AS took with the request. This information can then, in
turn, be used by SM to determine what it should do next with the
request.
The extension proposed is the Service-State header.
6.1. Service-State Header Syntax
The following is the proposed syntax for the Service-State header:
Service-State-extension = "Service-State" HCOLON svc-params
*(SEMI svc-params)
svc-params = (svc-token / svc-extension)
svc-token = "state" EQUAL gen-value
svc-extension = token [ EQUAL gen-value ]
gen-value = token / quoted-string
6.2. Use of the Service-State header
The Service-State header is optionally inserted by the AS into
requests and responses sent from the AS to the SM.
The Service-State header can be carried in any request or response
sent from the AS to SM, with the exception of the CANCEL request.
The content of the state token and any semantics associated with it
is outside the scope of this specification.
Definition of the syntax and semantics associated with the state
token is a local policy issue. It requires consistent definition
between the AS and the SM.
6.3. Behavior of SM
The SM can receive the Service-State header in a SIP message in the
following cases:
o Failure Responses - 400, 500 and 600 class responses.
Donovan & Sivachelvan Expires December 25, 2006 [Page 17]
Internet-Draft The Service-State Header June 2006
o Redirect Responses - 300 class responses.
o Success Responses - 200 class responses.
o Proxied Requests
o B2BUAed Requests
The action taken in each of these cases depends on the content of the
state token in the Service-State header. The definition of that
action is outside the scope of this specification.
6.4. Removal of Service-State header
In all cases the oSM and the tSM MUST remove the Service-State header
before routing the request or response to the next hop. This
includes cases:
o The SM routes a request to another AS.
o The oSM routes a request to the tSM.
o The SM routes a request to another SIP server.
o The SM routes a request to the tUA.
o The SM routes a response upstream.
Donovan & Sivachelvan Expires December 25, 2006 [Page 18]
Internet-Draft The Service-State Header June 2006
7. Security Considerations
Use of the state included in the Service-State header by the SM can
affect the service received by users of the system. As such, the SM
should only take actions using the information in the Service-State
header if the application is trusted.
Note that this is not a security concern that is unique to the
Service-State header. It is inherent in the Extended SIP Trapezoid
deployment architecture that splits functions between the SM and the
AS.
The mechanism for establishing trust between the SM and the AS is
outside the scope of this specification.
8. References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, J., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06.txts (work in progress),
October 2005.
[5] Levy, S. and B. Byerly, "Diversion Indication in SIP", Internet-
Draft http://www.softarmor.com/wgdb/docs/
draft-levy-sip-diversion-08.txt, August 2004.
[6] Barnes, M., Ed., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", Internet-
Draft http://www.softarmor.com/wgdb/docs/
draft-levy-sip-diversion-08.txt, August 2004.
Donovan & Sivachelvan Expires December 25, 2006 [Page 19]
Internet-Draft The Service-State Header June 2006
Authors' Addresses
Steven R. Donovan
Cisco Systems
2200 E. President George Bush Turnpike
Richardson, TX 75082
USA
Phone: +1 972 255 0248
Email: srd@cisco.com
Chelliah Sivachelvan
Cisco Systems
2200 E. President George Bush Turnpike
Richardson, TX 75082
USA
Phone: +1 972 255 1169
Email: chelliah@cisco.com
Donovan & Sivachelvan Expires December 25, 2006 [Page 20]
Internet-Draft The Service-State Header June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Donovan & Sivachelvan Expires December 25, 2006 [Page 21]
