Internet Engineering Task Force J. Elwell
Internet Draft Siemens
F. Audet
Nortel
draft-elwell-sipping-service-retargeting-00.txt
Expires: April 2006 October 2005
Indicating Service Retargeting in the Session Initiation Protocol
(SIP)
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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This contains motivation, requirements and a proposed solution for
indicating service retargeting information in SIP requests and
responses. Retargeting of a request can be considered to be service
retargeting when it goes beyond "normal" routing and might be of
interest to applications at the UAS or UAC.
Elwell Expires - April 2006 [Page 1]
Indicating Service Retargeting in SIP October 2005
Table of Contents
1 Introduction....................................................3
2 Requirements....................................................5
3 Overview of the solution........................................6
4 Behaviour.......................................................7
4.1 UAC behaviour.................................................7
4.2 Proxy behaviour...............................................7
4.3 Redirect behaviour............................................8
4.4 UAS behaviour.................................................8
5 Syntax..........................................................8
6 PSTN Mapping....................................................9
7 Examples.......................................................11
7.1 Proxy forwards busy to deputy................................11
7.2 Endpoint forwards busy to deputy.............................13
7.3 Endpoint forwards busy to TDM via a gateway..................14
7.4 Endpoint forwards busy to deputy with History Info...........15
8 IANA considerations............................................17
9 Security Considerations........................................17
9.1 Integrity Protection of Forwarding in SIP....................18
9.2 Privacy Related Issues on the Second Call Leg................18
10 Acknowledgements..............................................19
11 Author's Addresses............................................20
12 Normative References..........................................20
13 Appendix - Rejected Alternatives (temporary û to be removed)..21
13.1 Extending the SIP Reason header.............................22
13.2 New 3xx response codes......................................22
Elwell Expires - April 2006 [Page 2]
Indicating Service Retargeting in SIP October 2005
1 Introduction
Central to SIP [SIP] is the concept of retargeting a request by a
proxy, whereby the Request-URI in the original request is replaced
before forwarding the request on the next hop. Retargeting can also
occur because of redirection by a redirect server using a SIP 3xx
response code and subsequent recursion by the UAC or a proxy. Except
where otherwise stated, the term retargeting is used in this document
to cover recursion as well as retargeting. A given request from a
User Agent Client (UAC) can be retargeted zero or more times before
reaching the User Agent Server (UAS).
Retargeting is a normal part of routing a request in SIP. For
example, an outbound proxy might convert the initial Request-URI from
a telephone URI (perhaps in the form of a dial string) to a SIP URI.
As another example, the final proxy typically replaces an Address of
Record with the URI of a registered contact.
However, sometimes a service running at a proxy or redirect server
(including a UA acting as a redirect server) can initiate retargeting
to a specific service URI. Retargeting of this nature can be called
service retargeting, because it is based on special services that
operate on incoming requests to a target. An example of service
retargeting can be found in [SRVCTRL]. [SRVCTRL] specifies a means
for communicating context information to an application, with the
expectation that the recipient endpoint or application understands
the implications of the context information. Typically the original
target user will have made arrangements for service retargeting.
Service retargeting can be based on simple or complex rules for
handling requests to the original target.
For example, a request could be retargeted to a destination that can
handle requests that encounter busy or no reply at the original
target. As another example, a user could arrange that requests
targeted at the user be retargeted to a deputy, perhaps because the
original user expects to be absent or does not wish to be disturbed.
The fact that a request has been service retargeted is often of
interest to the users involved, i.e., the retargeted-to user and the
calling user, or to an application. Therefore it would be very useful
to provide to the UAS and the UAC details of retargeting in the form
of the original target URI, the retargeted-to URI and the reason for
retargeting.
Service retargeting information is also useful when interworking with
PSTN/ISDN. Service retargeting in SIP is similar to diversion in
PSTN/ISDN, and therefore service retargeting information in SIP can
be mapped to/from diversion information in PSTN/ISDN. For example,
for a call that is service retargeted in the SIP network because the
Elwell Expires - April 2006 [Page 3]
Indicating Service Retargeting in SIP October 2005
original target is busy, if the new target is in PSTN/ISDN the
PSTN/ISDN can be told that the call has been diverted on busy.
As a further example, service retargeting information can be of use
to a voice mail server. When a request is service retargeted to a
voice mail server the voice mail server is likely to need to know the
identity of the original target in order to access the correct
mailbox and the reason for service retargeting in order to behave
appropriately, e.g., play an appropriate announcement.
In all these examples, information about normal SIP retargeting, as
opposed to service retargeting, is not generally of interest.
[HIST] specifies a means of providing the UAS and UAC with
information about the retargeting of a request. This information
includes the initial Request-URI and any retarget-to URIs. This
information is placed in the History-Info header, field, which,
except where prevented by privacy considerations, is built up as the
request progresses and, on reaching the UAS, is returned in certain
responses. Within the History-Info header field, each URI, except for
the final one, includes as a parameter a Reason Header [REASON]
indicating the SIP response code that led to retargeting from that
URI to the next URI. This is either the response code received as a
result of forwarding the request to that URI or the nearest
equivalent if retargeting occurs without having forwarded the
request.
[HIST], when deployed at relevant SIP entities and not subject to
privacy, is intended to provide a comprehensive trace of retargeting
for a SIP request, along with the SIP response codes that led to
retargeting. [HIST] is captured independently of any service
interactions that might have resulted in retargeting. [HIST]
captures the information independently of how an endpoint might make
use of the information. Thus, it does not fully meet the needs of
reporting service retargeting for the following reasons:
- [HIST] reports all retargets, not just service retargets. This puts
the burden on the UAS or UAC to pick out which retargets are for
service reasons and which are for normal SIP routing reasons.
- [HIST] reports reasons in the form of SIP response codes, which do
not necessarily reflect service reasons for retargeting very well and
are not always meaningful to applications.
- The SIP response codes captured by [HIST] are dependent upon
whether retargeting is as a result of recursion or not. When
recursion is used, the SIP response code will always be in the 3xx
range, but otherwise, even if the reason for retargeting is
identical, the reason will not be in the 3xx range. For example, if
Elwell Expires - April 2006 [Page 4]
Indicating Service Retargeting in SIP October 2005
retargeting is due to the previous target being busy, the SIP
response code used without recursion would normally be 486, but with
recursion it would have to be a 3xx response code (e.g., 302).
This document defines a mechanism that provides simple but meaningful
information to a service retargeted-to user or application to
represent the most recent retarget of a request. The mechanism makes
use of the solution approach specified in [SRVCTRL], which provides
the flexibility to provide service retargeting information in SIP
requests. When used in conjunction with [HIST] it provides more
comprehensive information to the retargeted-to user or application
and also to the calling user or application. Although aimed primarily
at INVITE requests, it can in principle apply to other SIP methods.
2 Requirements
REQ-1. When forwarding a service-retargeted request to a UAS, it must
be possible to include information that denotes the service reason
for service retargeting and the previous target, in order to assist
the user or application in determining how to behave, e.g.:
- how to respond to the request;
- in the case of an INVITE request that is answered, how to behave
during the established session (e.g., greeting to be given).
REQ-2. It must be possible to include this information in a service-
retargeted request to a UAS also in the case where service
retargeting has been followed by retargeting that is not service
retargeting.
REQ-3. When a request from a UAC has been service-retargeted, it must
be possible to include information in a response that denotes the
reason for service retargeting and new target, in order to assist the
user in determining how to behave, e.g.:
- in the case of a failed request, under what circumstances it might
be appropriate to re-attempt the request (e.g., if retargeted because
of busy but the new target does not answer, it might be appropriate
to retry a few minutes later);
- in the case of an INVITE request that results in an established
session, whether to abandon that session and if so under what
circumstances it might be appropriate to re-attempt the request;
- in the case of an INVITE request that results in an established
session, how to behave during that session (e.g., greeting to be
given).
REQ-4. It must be possible to indicate that the reason for
retargeting is because there are no registered contacts for the URI.
Elwell Expires - April 2006 [Page 5]
Indicating Service Retargeting in SIP October 2005
REQ-5. It must be possible to indicate that the reason for
retargeting is because contacts for the URI are busy.
REQ-6. It must be possible to indicate that the reason for
retargeting is because the request was not answered during the
alerting period.
REQ-7. It must be possible to indicate that the reason for
retargeting is because the user has arranged for requests to be
retargeted irrespective of the state of registered contacts.
REQ-8. It must be possible to indicate that the reason for
retargeting is because the user declined the request during alerting.
REQ-9. It must be possible to indicate that the reason for
retargeting is because the user has arranged for requests to be
distributed among a number of targets.
REQ-10. It must be possible to indicate that the reason for
retargeting is because of network conditions.
REQ-11. It must be possible to indicate (e.g., by default) that there
is no service reason for retargeting.
REQ-12. It must be possible to extend the list of service retargeting
reasons in the future.
REQ-13. It must be possible to suppress information concerning
service retargeting in order to reflect network policy or respect the
wishes of the retargeted-from user.
3 Overview of the solution
[SRVCTRL] describes how URI parameters can be used to control a
service or application at the UAS by providing appropriate context
information. It describes this only in principle, without assigning
any new URI parameter names or values. For a given deployment, the
principles can be used to achieve control of a service or application
by configuring the appropriate URI parameter names and values at the
equipment concerned or by using equipment with appropriate
capabilities from a single vendor. This requires a lot of
coordination for configuring the various pieces of equipment,
matching service URIs, mapping service URIs to phone numbers, etc.
Further standardisation is required to allow easy deployment of
equipment from different vendors and with various level of
capabilities.
Elwell Expires - April 2006 [Page 6]
Indicating Service Retargeting in SIP October 2005
The solution here adopts the principles of [SRVCTRL] and defines
parameter names and values for indicating retargeting details to a
service or application. This enhancement to SIP, when used alone, is
sufficient to satisfy the needs of some applications and can also
provide useful information to a retargeted-to user. When used in
conjunction with [HIST] it can provide very comprehensive information
not only to retargeted-to applications and users but also to source
applications and users.
When a request is service retargeted (for a reason meaningful to a
retargeted-to user or application), two parameters are added to the
retargeted-to URI: the old-target parameter contains the previous
target URI and the retargeting-reason parameter contains the reason
for service retargeting. Provided this is the last retarget, these
parameters will reach the UAS and can be provided to the user or
application.
This provides a simple means of satisfying the needs of certain
applications such as voice mail servers that just require information
about the most recent retarget in order to trigger appropriate
behaviour.
When retargeting occurs and a History-Info header field element is
added to record the retarget-to URI and the SIP reason that led to
retargeting, if the retargeting is service retargeting the old-target
and retargeting-reason parameters in the retargeted-to URI will also
appear in the History-Info header field element. If History-Info
header field elements are forwarded to the UAS, the UAS will be able
to see which retargets were service retargets and the service
retargeting reasons concerned. Likewise, if the History-Info header
field elements are sent back to the UAC, the UAC will be able to see
which retargets were service retargets. This information can be
presented to the user or application at the UAS or UAC.
4 Behaviour
4.1 UAC behaviour
A UAC MAY use service redirection information in a received History-
Info header field to present to the user or application.
Note that when a UAC recurses as a result of receiving a 3xx
response, any service redirection information in the retargeted-to
URI (received in the Contact header field) will automatically be
copied into the Request URI.
4.2 Proxy behaviour
Elwell Expires - April 2006 [Page 7]
Indicating Service Retargeting in SIP October 2005
When retargeting a request for service reasons, a proxy MAY add an
old-target parameter and a retargeting-reason parameter to the new
target URI as placed in the Request-URI of the forwarded request. If
a new History-Info header field element is created to contain the new
target URI, this too MUST contain the same old-target and
retargeting-reason parameters.
4.3 Redirect behaviour
When redirecting a request for service reasons, a redirect MAY add an
old-target parameter and a retargeting-reason parameter to any or all
URIs placed in the Contact URI header field in the 3xx response.
4.4 UAS behaviour
A UAS MAY use service redirection information in a received Request-
URI or History-Info header field to present to the user or
application.
5 Syntax
This RFC updates the SIP URI parameters registry as defined in
[URIREG]. Two new URI parameters are defined.
URI parameter old-target, when present, means that the URI became the
target URI for the request (the new Request URI) as a result of
service retargeting and the URI parameter value was the Request URI
prior to service retargeting.
URI parameter retargeting-reason, when present, means that the URI
became the target URI for the request (the new Request URI) as a
result of service retargeting and the URI parameter value indicates
the reason for service retargeting.
The following retargeting-reason values are defined in this
specification:
no-contacts - service retargeting because there are no registered
contacts for the URI;
busy û service retargeting because contacts for the URI are busy;
no-reply û service retargeting because the request was not answered
during the alerting period;
unconditional û service retargeting because the user has arranged for
requests to be retargeted irrespective of the state of registered
contacts;
Elwell Expires - April 2006 [Page 8]
Indicating Service Retargeting in SIP October 2005
declined û service retargeting because the user declined the request
during alerting;
distribution û service retargeting because the user has arranged for
requests to be distributed among a number of targets;
network û service retargeting because of network conditions.
If a received retargeting-reason value is not recognized it SHOULD be
treated as "unconditional".
The ABNF definition of these parameters is as follows.
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param
/ old-target / retargeting-reason / other-param
old-target = "old-target=" Request-URI
redirecting-reason = "redirecting-reason=" service-reason
service-reason = ("no-contacts" / "busy" / "no-reply"
/ "unconditional" / "declined" / "distribution"
/ "network" / other-reason)
other-reason = token
6 PSTN Mapping
The mapping to the PSTN/ISDN protocols is important both for gateways
that connect the IP network to existing TDM equipment, such as PBXs
and voicemail systems, and for gateways that connect the IP network
to the PSTN/ISDN network. Both Q.931 and ISUP have signaling for
this information that can be treated as roughly equivalent for the
purposes here.
For a service-retargeted call from SIP to PSTN/ISDN, the user portion
of the URI SHOULD be used as the address of the service retargeted-to
entity in the PSTN/ISDN, while the old-target SHOULD be mapped to the
PSTN/ISDN original redirecting number.
If the gateway and Proxy are in the same Trust Domain (defined in RFC
3325 [PASSERT]), and the Spec(T) includes compliance with that
specification, and the Spec(T) asserts that the Proxy will do
screening (whatever that means), then the gateway MAY claim that the
original redirecting number is screened; otherwise it SHOULD NOT
assert that the original redirecting number is screened.
The following SHOULD be used as the mapping from retargeting-reason
parameters to ISUP/Q.931/QSIG redirect reason codes:
+------------------------------------------------------------------+
Elwell Expires - April 2006 [Page 9]
Indicating Service Retargeting in SIP October 2005
| Retargeting reason value | ISUP/Q.931/QSIG redirect
|
| | reason codes |
|----------------------------------------+-------------------------|
| no-contacts - service retargeting | Unknown / not available |
| because there are no registered | (Unconditional for QSIG)|
| contacts for the URI; | |
|----------------------------------------+-------------------------|
| busy û service retargeting because | User busy |
| contacts for the URI are busy; | |
|----------------------------------------+-------------------------|
| no-reply û service retargeting | No reply |
| because the request was not answered | |
| during the alerting period; | |
|----------------------------------------+-------------------------|
| unconditional û service retargeting | Unconditional |
| because the user has arranged for | |
| requests to be retargeted irrespective | |
| of the state of registered contacts; | |
|----------------------------------------+-------------------------|
| declined û service retargeting because | Deflection during |
| the user declined the request during | alerting |
| alerting; | (No reply for QSIG) |
|----------------------------------------+-------------------------|
| distribution û service retargeting | Deflection immediate |
| because the user has arranged for | response |
| requests to be distributed among a | (Unconditional for QSIG)|
| number of targets; | |
|----------------------------------------+-------------------------|
| network û service retargeting because | Network congestion |
| of network conditions. | (Unconditional for QSIG)|
+----------------------------------------+-------------------------+
The redirection counters SHOULD be set to one unless additional
information is available.
For a call from PSTN/ISDN that has been redirected within the
PSTN/ISDN, information from the PSTN/ISDN MAY be used to indicate
service retargeting in the SIP INVITE request. In this case, the
original redirecting number SHOULD be used to derive the old-target
URI and the ISUP/Q.931/QSIG redirect reason code should be used to
derive the retargeting-reason, in accordance with the table above.
More comprehensive mapping to/from PSTN/ISDN may be achieved if the
History-Info header field is also taken into account (e.g., by taking
into account multiple service retargets and by mapping information
sent towards the calling party). This is outside the scope of this
document.
Elwell Expires - April 2006 [Page 10]
Indicating Service Retargeting in SIP October 2005
7 Examples
This section provides some example use cases for the solution
proposed in this document. The examples are intended to highlight
the potential applicability of this solution and are not intended to
limit its applicability. The term "deputy" is used to define the
role of a recipient UA, after retargeting, in several of the
examples. This term is intended to represent a general role of an
entity that could be an automata (eg. voicemail server) or another
person, such as another member of a work group (e.g. supervisor) or
agent in a call center application, etc..
Also the examples show just service retargeting on busy, but can
easily be adapted to show other forms of service retargeting.
7.1 Proxy forwards busy to deputy
In this example, Alice calls Bob. BobÆs proxy determines that Bob is
busy, and the proxy forwards the call to Bob's deputy (or voice
mail). Alice's phone is at 192.168.0.1 while Bob's phone is at
192.168.0.2. The important thing to note is the URI in message F7.
Alice Proxy Bob Deputy
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 486 Busy F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.168.0.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@92.168.0.1>
Content-Type: application/sdp
Elwell Expires - April 2006 [Page 11]
Indicating Service Retargeting in SIP October 2005
Content-Length: *Body length goes here*
* SDP goes here*
F2: INVITE proxy.example.com -> 192.168.0.2
INVITE sip:line1@192.168.0.2 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.168.0.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F4: 486 192.168.0.2 -> proxy.example.com
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
INVITE sip:deputy@example.com; \
old-target=sip:+15555551002@example.com;user=phone; \
retargeting-reason=busy SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.168.0.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
Elwell Expires - April 2006 [Page 12]
Indicating Service Retargeting in SIP October 2005
* SDP goes here*
7.2 Endpoint forwards busy to deputy
In this example, Alice calls Bob. Bob is busy, but forwards the
session directly to his deputy (or voicemail). Alice's phone is at
192.168.0.1 while Bob's phone is at 192.168.0.2. The important thing
to note is the URI in the Contact in message F3.
Alice Proxy Bob Deputy
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | 302 Moved F3 | |
| 302 Moved F4 |<-------------| |
|<---------------| | |
| ACK F5 | | |
|--------------->| ACK F6 | |
| |------------->| |
| INVITE F7 |
|-------------------------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.168.0.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@92.168.0.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F2: INVITE proxy.example.com -> 192.168.0.2
INVITE sip:line1@192.168.0.2 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
Elwell Expires - April 2006 [Page 13]
Indicating Service Retargeting in SIP October 2005
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.168.0.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F3: 302 192.168.0.2 -> proxy.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip: deputy@example.com; \
old-target=sip:+15555551002@example.com;user=phone; \
retargeting-reason=busy;>
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
INVITE sip: deputy@example.com; \
old-target=sip:+15555551002@example.com;user=phone; \
retargeting-reason=busy SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.168.0.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
7.3 Endpoint forwards busy to TDM via a gateway
In this example, the deputy (or mailbox) is reached via a gateway to
a TDM network. Bob's number is +1 555 555-1002, while deputy's
number on the TDM network is +1-555-555-2000.
The call flow is the same as in section 7.2 except for the Contact
URI in F3 and the Request URI in F7.
Elwell Expires - April 2006 [Page 14]
Indicating Service Retargeting in SIP October 2005
F3: 302 192.168.0.2 -> proxy.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:+15555552000@example.com;user=phone;\
old-target=tel:+15555551002;retargeting-reason=busy>
Content-Length: 0
F7: INVITE proxy.example.com -> gw.example.com (for both 7.1 and 7.2)
INVITE sip:+15555552000@example.com;user=phone;\
old-target=tel:+15555551002;retargeting-reason=busy \
SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:5551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.168.0.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
7.4 Endpoint forwards busy to deputy with History Info
This example illustrates how History Info [HIST] works in conjunction
with service retargeting. The scenario is the same as 7.1.
F1: INVITE 192.168.0.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@92.168.0.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1
Content-Type: application/sdp
Content-Length: *Body length goes here*
Elwell Expires - April 2006 [Page 15]
Indicating Service Retargeting in SIP October 2005
* SDP goes here*
F2: INVITE proxy.example.com -> 192.168.0.2
INVITE sip:line1@192.168.0.2 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.168.0.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.168>;index=1.1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F7: INVITE proxy.example.com -> um.example.com
INVITE sip: deputy@example.com; \
old-target=sip:+15555551002@example.com;user=phone; \
retargeting-reason=busy SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.168.0.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.168?Reason=SIP%3Bcause%3D302;
text=öMoved Temporarilyö>;index=1.1
<sip: deputy@example.com; \
old-target=sip:+15555551002@example.com;user=phone;\
retargeting-reason=busy>;index=2
Contact: <sip:alice@192.168.0.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
Elwell Expires - April 2006 [Page 16]
Indicating Service Retargeting in SIP October 2005
8 IANA considerations
This specification adds a new value to the IANA registration in the
"SIP/SIPS URI Parameters" sub-registry at
http://www.iana.org/assignments/sip-parameters as defined in
[URIREG].
Parameter Name Predefined Values Reference
old-target No [RFCAAAA]
retargeting-reason Yes [RFCAAAA]
[Note to IANA: Please replace AAAA with the RFC number of this
specification.
This document requests that IANA create a new registry for
retargeting-reason values. Each registry entry must contain the value
and the specification in which the value is defined. New values for
this registry may be defined only in Standards Track RFCs. This
registry is to be populated initially with the following entries
defined in section 5: no-contacts; busy; no-reply; unconditional;
declined; distribution; network.
9 Security Considerations
This draft discusses transactions involving at least three parties,
which increases the complexity of the privacy issues. In addition,
the security considerations of [HIST] apply when the History-Info
header field is used.
The new URI parameters defined in this draft are generally sent from
a Proxy or call control system to a retargeted-to UA (or to a gateway
to the PSTN and then to a retargeted-to device). These new
parameters tell the retargeted-to UA what service the proxy wishes to
have performed. Just as any message sent from the proxy to the
retargeted-to UA needs to be integrity protected, these messages need
to be integrity protected to stop attackers from, for example,
causing speech (e.g., voicemail) meant for a company's CEO to go to
an attacker. RFC 3261 provides a TLS mechanism suitable for
performing this integrity protection.
The signaling from the Proxy to the retargeted-to UA will reveal who
is calling whom and possibly some information about a user's presence
based on whether the call was answered or retargeted. This
information can be protected by encrypting the SIP traffic between
the Proxy and the retargeted-to UA. Again, RFC 3261 contains
mechanisms for accomplishing this using TLS.
Elwell Expires - April 2006 [Page 17]
Indicating Service Retargeting in SIP October 2005
The S/MIME based mechanisms in RFC 3261 will generally not be
applicable for protecting this information because they are meant for
end to end issues and this is primarily a middle to end scenario.
Without end-to-end or middle-to-end security, reliance is placed on
on hop-by-hop security using TLS and the SIPS URI scheme. This
requires that all hops between the Proxy and the retareget-to UR be
trusted, which is the case in many deployment scenarios.
9.1 Integrity Protection of Forwarding in SIP
The forwarding of a call in SIP brings up a very strange trust issue.
Consider the normal case when A calls B and the call gets forwarded
to C by a network element in B's domain, and then C answers the call.
A has called B but ended up talking to C. This scenario may be hard
to separate from a man in the middle attack.
There are two possible solutions. One is that B sends back
information to A saying don't call me, call C and signs it as B. The
problem is that this solution involves revealing that B has forwarded
to C, which B often may not want to do. For example, B may be a work
phone that has been forwarded to a mobile or home phone. The user
does not want to reveal their mobile or home phone number but, even
more importantly, does not want to reveal that they are not in the
office.
The other possible solution is that A needs to trust B only to
forward to a trusted identity. This requires a hop by hop transitive
trust such that each hop will only send to a trusted next hop and
each hop will only do things that the user at that hop desired. This
solution is enforced in SIP using the SIPS URI and TLS based hop by
hop security. It protects from an off axis attack, but if one of the
hops is not trustworthy, the call may be diverted to an attacker.
Any redirection of a call to an attacker's mailbox is serious. It is
trivial for an attacker to make its mailbox seem very much like the
real mailbox and forward the messages to the real mailbox so that the
fact that the messages have been intercepted or even tampered with
escapes detection.
9.2 Privacy Related Issues on the Second Call Leg
When A calls B and gets redirected to C, occasionally people say
there is a requirement for the call leg from B to C to be anonymous.
This is not the PSTN and there is no call leg from B to C; instead
there is a VoIP session between A and C. If A had put a To header
containing B in the initial invite message, unless something special
is done about it, C will see that To header. If the person who
answers phone C says "I think you dialed the wrong number, who were
you trying to reach?" A will probably specify B.
Elwell Expires - April 2006 [Page 18]
Indicating Service Retargeting in SIP October 2005
If A does not want C to see that the call was to B, A needs a special
relationship with the forwarding Proxy to induce it not to reveal
that information. The call should go through an anonymizer service
that provides session or user level privacy (as described in [PRIV]
[4]) service before going to C. It is not hard to figure out how to
meet this requirement, but it is unclear why anyone would want this
service.
The scenario in which B wants to make sure that C does not see that
the call was to B is easier to deal with but a bit weird. The usual
argument is B wants to forward his phone to C but does not want C to
find out his phone number. It is hard to imagine that C would want
to accept all BÆs calls without knowing how to call B to complain.
Several popular web portals will send SMS alert message about things
like stock prices and weather to mobile phone users today. Some of
these contain no information about the account on the web portal that
initiated them, making it nearly impossible for the mobile phone
owner to stop them. This anonymous message forwarding has turned out
to be a really bad idea even where no malice is present. Clearly
some people are fairly dubious about the need for this, but never
mind: let's look at how it is solved.
In the general case, the proxy needs to route the call through an
Anonymization Service and everything will be cleaned up. Any
Anonymization service that performs the "Privacy: Header" Service in
[PRIV] MUST remove the reason and target URI parameters from the URI.
[PRIV] already makes it clear you would need to clean up this sort of
information.
There is a specialized case of some interest in which the mechanisms
in this specification are being used in conjunction with [PRIV], and
the retargeted-to UA and the Proxy are both in the trust domain. In
this limited case, the problem that B does not want to reveal their
address to C can be solved by ensuring that the target parameter URI
should never be in a message that is forwarded outside the trust
domain. If it is passed to a PSTN device in the trust domain, the
appropriate privacy flag needs to be set in the ISUP or ISDN
signaling.
In several scenarios it is possible that a service retargeted-to user
will receive unwanted calls. Arranging for automatic rejection of
such calls can alleviate the problem, although it would be preferable
to take steps to prevent the service retargeting, e.g., by contacting
the retargeting user. Of course, if for privacy reasons service
retargeting information is not provided, this will not be possible.
10 Acknowledgements
Elwell Expires - April 2006 [Page 19]
Indicating Service Retargeting in SIP October 2005
Some of the text was taken from Cullen Jennings' draft on voicemail-
uri. The following individuals provided valuable comments during the
initial formulation of this document: Denis Alexeitsev, Mary Barnes,
Martin Dolly, Roland Jesske, Joanne McMillen.
11 Author's Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
Franois Audet
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
USA
mailto:audet@nortel.com
12 Normative References
[SIP] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[HIST] M. Barnes, "An Extension to the Session Initiation Protocol
for Request History Information", draft-ietf-sipping-history-info-06
(work in progress).
[REASON] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header
for the Session Initiation Protocol (SIP)", RFC 3326.
[SRVCTRL] B. Campbell, R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087.
[URIREG] G. Camarillo, "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the Session
Initiation Protocol (SIP)", RFC 3969.
[PASSERT] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks", RFC 3325, November 2002.
[PRIV] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
Intellectual Property Statement
Elwell Expires - April 2006 [Page 20]
Indicating Service Retargeting in SIP October 2005
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 IETF's procedures with respect to rights in IETF 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 (2005).
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
13 Appendix - Rejected Alternatives (temporary û to be removed)
The following alternative solutions were considered and rejected.
Elwell Expires - April 2006 [Page 21]
Indicating Service Retargeting in SIP October 2005
13.1 Extending the SIP Reason header
This alternative involves defining a new "protocol" (namespace) in
the SIP Reason header for service retargeting reasons. A service-
retargeted request could then convey, as a URI header in the History-
Info header field, a Reason header field indicating the service
retargeting reason, in addition to the SIP reason for retargeting. In
addition, the Reason header field could be used in a 3xx response to
indicate a service reason for redirection. This was considered to
have the following disadvantages:
- It is not backwards compatible with existing UACs or proxies, which
would not copy a Reason header from a 3xx response into a History-
Info header field when recursing.
- The need for escape characters in URI headers makes this less
readable.
- It does not provide a basic level of support to applications at the
UAS without requiring use of the History-Info header field.
13.2 New 3xx response codes
There are many unused response codes in the 3xx range, and a few of
these could have been used for service retargeting reasons. This was
considered to have the following disadvantages:
- Service reasons for retargeting are in some ways orthogonal to SIP
reasons, and it would be unwise to mix the two in the same namespace.
- There may be advantages in having both a SIP retargeting reason and
a service retargeting reason available.
- It does not provide a basic level of support to applications at the
UAS without requiring use of the History-Info header field.
Elwell Expires - April 2006 [Page 22]