One document matched: draft-elwell-sipping-redirection-reason-00.txt
Internet Engineering Task Force J. Elwell
Internet Draft Siemens
draft-elwell-sipping-redirection-reason-00.txt
Expires: November 2004 May 2004
Indicating redirection reasons in SIP
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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 (2004). All Rights Reserved.
Abstract
This examines the need for signalling additional information
concerning the reason for redirection in SIP and proposes two
possible solutions.
Elwell Expires - November 2004 [Page 1]
Indicating redirection reasons in SIP May 2004
Table of Contents
1 Introduction....................................................3
2 Candidate solutions.............................................4
2.1 Solution 1 - add a new "protocol" value to the Reason header..4
2.2 Solution 2 - add a new redirection-reason parameter to a contact
URI...............................................................6
3 Conclusions.....................................................8
4 Acknowledgements................................................8
5 Author's Addresses..............................................8
6 Normative References............................................8
Elwell Expires - November 2004 [Page 2]
Indicating redirection reasons in SIP May 2004
1 Introduction
Central to SIP [2] is the concept of redirecting or retargeting a
request by a proxy, whereby the Request-URI in the original request
is replaced before forwarding the request on the next hop. Sometimes
this is due to normal rerouting behaviour of the proxy (e.g.,
resolving an address-of-record URI to a contact URI). At other times
it is due to more application-related reasons, e.g., where a user has
made arrangements for calls to that user under certain conditions to
be forwarded to a different destination. Also retargeting can be
performed as a result of a 3xx response from a redirect server.
Different 3xx response codes reflect different reasons for rejecting
the request.
The History-Info header [3] provides a means for conveying
information about a retarget to the final destination UAS and also
back to the UAC. In addition to providing the retargeted-from and
retargeted-to URIs for each recorded retarget, this header also
conveys a reason by means of the Reason header. The Reason header
accompanies the retargeted-from URI and reflects the reason why
attempts to reach that target failed, normally in the form of the SIP
response code concerned.
However, there is nothing in either a 3xx response or the History-
Info header to indicate an explicit reason for the redirection
request or the retarget respectively. At present the reason is
implicit in the reason for failure of the request to the original
target. Sometimes this might give an accurate picture of what is
happening, but not always. Consider the following cases:
1. A device acts as a redirect server because it is busy. None of
the 3xx response codes can reflect that the reason for retargeting
to the URI given in the Contact header of the 3xx response is
because the existing target is busy.
2. A device acts as a redirect server because it alerts the user
but fails to get a reply within a certain time. None of the 3xx
response codes can reflect that the reason for retargeting to the
URI given in the Contact header of the 3xx response is because the
existing target failed to answer.
3. A proxy is scripted to retarget requests without first
attempting to forward them to the original target. Retargeting may
be unconditional or based on certain conditions such as date, time,
the source of the request or caller preferences. Because it does
this without forwarding the request to the original target, no SIP
response code is applicable.
Elwell Expires - November 2004 [Page 3]
Indicating redirection reasons in SIP May 2004
4. A proxy is scripted to perform hunting or distribution of calls
among a number of different targets. When forwarding a request to a
target selected from a list of candidate targets, the reason for
retargeting is because of hunting or distribution, rather than
because of any failure of the existing target.
5. In the hunting or distribution scenario above, forwarding a
request to one target from the list of candidate targets may fail
for a particular reason (e.g., busy), leading to selection of
another target from the list. However, the reason for retargeting
is because of hunting or distribution, not specifically because the
previous target had a certain condition.
This seems to point to a need to convey in a 3xx response or a
History-Info header the reason for selecting the retargeted-to URI.
Candidate reasons are:
CFI, "Call forwarding immediate" - immediate retargeting without
forwarding the request to the retargeted-from URI;
CFB, "Call forwarding busy" - retargeting because the retargeted-from
URI is busy;
CFNR, "Call forwarding no reply" - retargeting because there was no
reply at the retargeted-from URI;
CD, "Call deflection" - retargeting because the user at the
retargeted-from URI made a request in real time for retargeting;
HUNT, "Hunting" - selection of the target by means of hunting or
distribution;
NORMAL "Normal redirection" (default) - normal retargeting of a
request.
Note that selection of the new target may depend on several other
conditions (e.g., relating to date, time, the source of the request
or caller preferences), but the reasons suggested above should be
sufficient to convey the main circumstance leading to the retarget.
Two candidate solutions are discussed below.
2 Candidate solutions
2.1 Solution 1 - add a new "protocol" value to the Reason header
New reasons could be achieved by adding a new "protocol" value in the
Reason header. For example, assume a session was initiated to
sip:+14084953756@foo.com;user=phone.
Elwell Expires - November 2004 [Page 4]
Indicating redirection reasons in SIP May 2004
Assuming the entity sending the INVITE supports the History-Info
header, the INVITE would look like this:
INVITE sip:+14084953756@foo.com;user=phone SIP/2.0
From: "Mr. Whatever" <whatever@foo.com>;tag=2
To: <sip:+14084953756@foo.com;user=phone>
Call-ID: 12345600@foo.com
CSeq: 1 INVITE
History-Info: <sip:+14084953756@foo.com;user=phone>;index=1
...
The call is then redirected to a contact URI
<sip:+44123456789@foo.com;user=phone> in a 302 response. The response
would be as follows:
SIP/2.0 302 Moved temporarily
From: "Mr. Whatever" <whatever@foo.com>;tag=2
To: <sip:+14084953756@foo.com;user=phone>;tag=3
Call-ID: 12345600@foo.com
CSeq: 1 INVITE
Contact: <sip:+44123456789@foo.com;user=phone>
Reason: Redirection; cause=CFI
…
The call would be retargeted to the contact URI. The first History-
Info header would be augmented with the two reasons for retargeting
(302 and CFI)). A second History-Info header would be added with the
new retargeted-to Request-URI:
INVITE sip:+44123456789@foo.com;user=phone SIP/2.0
From: "Mr. Whatever" <whatever@foo.com>;tag=2
To: <sip:+14084953756@foo.com;user=phone>
Call-ID: 12345600@foo.com
CSeq: 1 INVITE
History-Info: <sip:+14084953756@foo.com;user=phone?Reason: SIP;
cause=302; text="Moved temporarily"?Reason: Redirection;
cause=CFI>;index=1, <sip:+44123456789@foo.com;user=phone>;index=2
The "index 1" entry indicates that the call to +1-408-495-3756 was
retargeted because of SIP response code 302 and redirection reason
CFI.
The "index 2" entry indicates that the call to +44-123456789 has not
yet been further retargeted.
For the case where the proxy initiates retargeting (not as a result
of a 3xx response from a redirect server), the proxy itself would
Elwell Expires - November 2004 [Page 5]
Indicating redirection reasons in SIP May 2004
need to generate the Reason header with Redirection;cause=CFI for
inclusion in the index 2 URI in History-Info.
This solution would require either a new standards track RFC or a
standard published by another organisation to define the new
"protocol" value in the Reason header.
There is an impact on History-Info in that History-Info is required
to capture the Redirection reason in a Reason header (since it's not
part of the Contact URI in this case). In the current History-Info
draft, only the SIP response code is captured in a Reason header.
2.2 Solution 2 - add a new redirection-reason parameter to a contact
URI
New reasons could be indicated using a new parameter in a URI.
For example, assume a session was initiated to
sip:+14084953756@foo.com;user=phone.
Assuming the entity sending the INVITE supports the History-Info
header, the INVITE would look like this:
INVITE sip:+14084953756@foo.com;user=phone SIP/2.0
From: "Mr. Whatever" <whatever@foo.com>;tag=2
To: <sip:+14084953756@foo.com;user=phone>
Call-ID: 12345600@foo.com
CSeq: 1 INVITE
History-Info: <sip:+14084953756@foo.com;user=phone>;index=1
...
The call is then redirected to a contact URI
<sip:+44123456789@foo.com;user=phone;redirection-reason=CFI> in a 302
response. The response would be as follows:
SIP/2.0 302 Moved temporarily
From: "Mr. Whatever" <whatever@foo.com>;tag=2
To: <sip:+14084953756@foo.com;user=phone>;tag=3
Call-ID: 12345600@foo.com
CSeq: 1 INVITE
Contact: <sip:+44123456789@foo.com;user=phone;redirection-
reason=CFI>
…
The call would be retargeted to the contact URI. The first History-
Info header will be augmented with the Redirection reason (302). A
second History-Info header is added with the new retargeted Request-
URI:
Elwell Expires - November 2004 [Page 6]
Indicating redirection reasons in SIP May 2004
INVITE sip:+44123456789@foo.com;user=phone;redirection-reason=CFI
SIP/2.0
From: "Mr. Whatever" <whatever@foo.com>;tag=2
To: <sip:+14084953756@foo.com;user=phone>
Call-ID: 12345600@foo.com
CSeq: 1 INVITE
History-Info: <sip:+14084953756@foo.com;user=phone?Reason: SIP;
cause=302; text="Moved temporarily">;index=1,
<sip:+44123456789@foo.com;user=phone;redirection-
reason=CFI>;index=2
The "index 1" entry indicates that the call to +1-408-495-3756 was
retargeted because of SIP response code 302.
The "index 2" entry indicates that the call to +44-123456789 has not
yet been further retargeted, but that it was made as a result of a
CFI redirection-reason.
For the case where the proxy initiates retargeting (not as a result
of a 3xx response from a redirect server), the proxy itself would
need to generate the redirection-reason parameter for inclusion in
the index 2 URI in History-Info.
This solution has the advantage that the redirection reason is
associated with a particular contact URI and would automatically get
copied as part of the contact URI into the Request-URI of the
retargeted request. It would be backward compatible with existing
implementations of History-Info, since it would automatically be
copied with the URI into the History-Info header.
A possible disadvantage is that URI parameters are intended to
influence a request constructed from the URI. It might be argued that
redirection-reason does not meet this requirement.
Note the difference between this and solution 1, whereby the
additional reason is placed in the index 1 URI for solution 1 but in
the index 2 URI for solution 2. It is arguable which is the more
appropriate. Also solution 1 could be adapted to use the index 2 URI,
if considered more appropriate.
The SIP and SIPS URIs are extensible in that new parameters can be
added and will be ignored by any implementation that does not
understand them. There are plans to create an IANA registry for URI
parameters (draft-ietf-sip-uri-parameter-reg-01), and this will
require that new parameters be defined in an RFC.
There is no impact on the History-Info draft.
Elwell Expires - November 2004 [Page 7]
Indicating redirection reasons in SIP May 2004
3 Conclusions
The SIP community is asked to express its opinions on the two
proposed solutions or suggest other alternatives.
4 Acknowledgements
The author would like to acknowledge considerable assistance from
Francois Audet and Mary Barnes in drafting this contribution.
5 Author's Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
6 Normative References
[1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the
Session Initiation Protocol (SIP)", RFC 3326.
[2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[3] M. Barnes "An Extension to the Session Initiation Protocol for
Request History Information", draft-ietf-sipping-history-info-02
(work in progress)
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 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.
Elwell Expires - November 2004 [Page 8]
Indicating redirection reasons in SIP May 2004
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 (2004). 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.
Elwell Expires - November 2004 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 17:07:50 |