Network Working Group M. Mohali
Internet-Draft France Telecom
Intended status: Informational S. Norreys
Expires: January 12, 2009 British Telecom
J. Van Gee
Belgacom
M. Dolly
ATT
F. Silva
Portugal Telecom
G. Sciortino
C. Amenta
Italtel
July 11, 2008
Mapping and interworking of Diversion information Between Diversion and
History-Info Headers in the Session Initiation Protocol (SIP)
draft-mohali-diversion-history-info-00
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 January 12, 2009.
Abstract
Both History-Info and Diversion headers are able to transport
Mohali, et al. Expires January 12, 2009 [Page 1]
Internet-Draft Mapping Diversion and History-Info July 2008
diverting information in Session Initiation Protocol (SIP) signaling.
This document proposes a way to map call forwarding information
contained in a Diversion header into a History-Info header and vice
versa. In addition, an interworking policy is proposed to manage the
headers coexistence.
Prior to existence of [RFC4244] describing the History-Info header,
there was a draft introducing a header named Diversion for the
transport of diversion information.
Since the Diversion header is used in many existing networks
implementations and it is not standardized for transport of diversion
information, a mapping with the standardized History-Info header is
needed.
Requirements Language
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].
Mohali, et al. Expires January 12, 2009 [Page 2]
Internet-Draft Mapping Diversion and History-Info July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Interworking need . . . . . . . . . . . . . . . . . . . . 5
2.2. Interworking recommendations . . . . . . . . . . . . . . . 5
3. Headers syntaxes reminder . . . . . . . . . . . . . . . . . . 7
3.1. History-Info header syntax . . . . . . . . . . . . . . . . 7
3.2. Diversion header syntax . . . . . . . . . . . . . . . . . 8
4. Headers in SIP METHOD . . . . . . . . . . . . . . . . . . . . 9
5. Diversion header to History-Info header . . . . . . . . . . . 9
6. History-Info header to Diversion header . . . . . . . . . . . 12
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Example with Diversion header changed into
History-Info header . . . . . . . . . . . . . . . . . . . 14
7.2. Example with History-Info header changed into
Diversion header . . . . . . . . . . . . . . . . . . . . . 14
7.3. Example with two SIP networks using History-Info
header interworking with a SIP network using Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Mohali, et al. Expires January 12, 2009 [Page 3]
Internet-Draft Mapping Diversion and History-Info July 2008
1. Introduction
1.1. Overview
For enhanced network services (eg. Voicemail, IVR or automatic call
distribution), it is necessary for the called SIP user agent to
identify from whom and why the session was diverted. In order to be
used by various service providers or applications, redirection
information needs to pass through the network.
This is possible with two different SIP headers: History-Info
[RFC4244] and Diversion [draft-levy-sip-diversion-08] which both able
to transport diversion information in SIP signaling. Because of this
double possibility, it is necessary to map one into the other.
This document provides a standard mechanism of translation between
the History-Info header and the Diversion header.
1.2. Background
To transport diversion information, the History-Info header [RFC4244]
and an URI extension [RFC4458] are advocated in the standardized
Communication Diversion (CDIV) service Protocol Specifications
[TS_183004] and [TS_24.604].
Because of the implementation of the Diversion header in some SIP
networks/terminals and the History-Info header in others, it is
necessary to map one to the other.
At first, the Diversion header was described in
[draft-levy-sip-diversion-08], which is today discarded. This header
contains the list of the diverting user(s) with associated
information. The top-most diversion entry (first in the list)
corresponds to the last diverting user and the bottom-most entry to
the first diverting user (see syntax below).
At the same time, the History-Info header was proposed for the
transport of "request history" information which allows the receiving
application to determine hints about how and why the session arrived
at the application/user. As history information is larger than
diversion information, diversion information MUST be located and
extracted from the History-Info header. This is not the case with
the Diversion header. In addition, for diverting information the
History-Info header MUST be completed by [RFC4458] for the transport
of the diversion reason.
Those headers have different syntaxes described below. Note that the
main difference is that the History-Info header is a chronological
writing header whereas the Diversion header is the opposite (i.e. the
first diversion entry read correspond to the last diverting user).
Mohali, et al. Expires January 12, 2009 [Page 4]
Internet-Draft Mapping Diversion and History-Info July 2008
2. Problem Statement
2.1. Interworking need
The Diversion header is used for recording communication diversion
information which could be useful to network entities downstream.
Today, this SIP header is implemented by several manufacturers and
deployed in several networks.
In addition, the History-Info header is standardized, among other
needs, for the transportation of diversion information.
As both are answering to call forwarding needs, according to the one
created or completed in one side and the one interpreted in the other
side, diverting information could be mixed-up if they are both
present in the INVITE request. So, Diversion and History-Info
headers MUST NOT independently coexist for the session signalling.
For the transportation of consistent diversion information
downstream, it is necessary to make the two headers interwork.
Mapping between the Diversion header and the History-Info header is
presented in sections 5 and 6.
2.2. Interworking recommendations
To avoid the two headers coexisting it would be better to replace one
by the other during the interworking, but this may not be possible
due to the information that History-Info header may carry.
Indeed, the History-Info header is larger than Diversion header and
is used for other services than call diversion: in addition to trace
call forwarding information, it is acting as a session history and
could store all successive R-URI values. So, sometimes, it will not
be possible to suppress the History-Info header after the Diversion
header has been created.
SIP network/terminal using Diversion to SIP network/terminal using
History-Info header:
When the Diversion header is mapped into a History-Info header, the
Diversion header MUST be suppressed in the outgoing INVITE. It is
considered that all information present in the Diversion header is
transferred in the History-Info header.
If a History-Info header is present in the incoming INVITE (in
addition to Diversion header), the Diversion header and History-Info
header present MUST be mixed and only the diversion information not
yet present in the History-Info header MUST be inserted as a last
entry (more recent) in the existing History-Info header as
Mohali, et al. Expires January 12, 2009 [Page 5]
Internet-Draft Mapping Diversion and History-Info July 2008
recommended in [RFC4244].
As an example, this could be the case of an INVITE coming from a
network_2 using Diversion header but before passed through a
network_1 using History-Info header (or the network_2 uses History-
Info header to transport successive URI information) and going to a
network_3 using History-Info header. In that case, the incoming
INVITE contains a Diversion header and a History-info header. So
that, it is necessary to create, for network_3, a single History-Info
header gathering existing information in the History-Info header
received and those present in the Diversion header. Then network_3
could use call forwarding information that are present in a single
header and add its own diversion information if necessary.
Note that the chronological order could not be certified. If
previous policy recommendations are applied, the chronological order
is respected as Diversion entries are inserted at the end of the
History-Info header taking into account the Diversion internal
chronology.
SIP network/terminal using History-Info header to SIP network/
terminal using Diversion header:
When the History-Info header is mapped into a Diversion header, some
precautions MUST be taken.
If the History-Info header contains only communication diversion
information, then it MUST be suppressed after the mapping.
If the History-Info header contains other information, then only the
information of concern to the diverting user MUST be used to create
entries in the Diversion header and the History-Info header MUST be
kept as received in the INVITE forwarded downstream.
Note: The History-Info header could be used for other reasons than
CDIV services, for example by a service which need to know if a
specific AS had yet been invoked in the signalling path. If the call
is after forwarded to a network using History-Info header, it would
be better to not loose history information due to passing though the
network which only support Diversion header. A recommended solution
MUST NOT disrupt the standard behaviour and networks which not
implement History-Info header MUST be transparent to an incoming
History-Info header.
If a Diversion header is already presents in the incoming INVITE (in
addition to History-Info header), only diversion information present
in the History-Info header but not in the Diversion header MUST be
inserted from the last entry (more recent) into the existing
Diversion header as recommended in the Diversion draft
[draft-levy-sip-diversion-08]. Note that the chronological order
could not be certified. If previous policy recommendations are
Mohali, et al. Expires January 12, 2009 [Page 6]
Internet-Draft Mapping Diversion and History-Info July 2008
respected, this case SHOULD NOT happen.
Forking case:
The History-Info header enables the recording of sequential forking
for the same served-user. During a mapping from the History-Info
header to Diversion header, the History-Info entries contaning a
forking situation (with an incremented "index" parameter) could be
either mapped for each entry with a call forwarding "cause"
parameter, the interworking entity could choose to create only one
Diversion entry or to not apply the mapping. The choice could be
done according a local policy.
3. Headers syntaxes reminder
3.1. History-Info header syntax
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *( SEMI hi-param )
hi-targeted-to-uri= name-addr
hi-param = hi-index / hi-extension
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
hi-extension = generic-param
The History-Info header is specified in [RFC4244]. Amongst the
information contained in the header list is the diversion information
with a specific cause code mentioning the diversion reason. These
optional cause codes are defined in [RFC4458]. It is also possible
to introduce the Privacy header defined in [RFC3323] for diversion
information. The top-most History-Info entry (first in the list)
corresponds to the oldest history information.
A diverting user information is identifiable by the History-Info
entry containing a cause-param with cause value as listed in
[RFC4458] and by the entry just before. The last diversion target is
identifiable by the last History-Info entries containing a cause-
param with cause value as listed in RFC 4458.
The cause-param is inserted in the hi-targeted-to-uri of the address
were the communication is diverted to. The index parameter is a
string of digits, separated by dots to indicate the number of forward
hops and retargets.
Example:
History-Info:
<sip: diverting_user1_addr; Privacy=none >;index=1,
Mohali, et al. Expires January 12, 2009 [Page 7]
Internet-Draft Mapping Diversion and History-Info July 2008
<sip: diverting_user2_addr; Privacy=history;
Reason=SIP;cause=302>index=1.1,
<sip:last_diversion_target;Reason=SIP;cause=486>; index=1.1.1,
Policy concerning "histinfo" option tag in Supported header:
According to [RFC4244], a proxy that receives a Request with the
"histinfo" option tag in the Supported header should return captured
History-Info in subsequent, provisional and final responses to the
Request. The behaviour depend whether the local policy support the
capture of History-Info or not.
3.2. Diversion header syntax
It seems that there is some few mistakes in the Diversion syntax, so
it would be better to use the following syntax:
Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion-
params)
diversion-params = name-addr *(SEMI (diversion-reason / diversion-
counter / diversion-limit / diversion-privacy / diversion-screen /
diversion-extension))
diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / "no-
answer" / "unavailable" / "unconditional" / "time-of-day" / "do-not-
disturb" / "deflection" / "follow-me" / "out-of-service" / "away" /
token / quoted-string)
diversion-counter = "counter" EQUAL 1*2DIGIT
diversion-limit = "limit" EQUAL 1*2DIGIT
diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / "off"
/ token / quoted-string)
diversion-screen = "screen" EQUAL ("yes" / "no" / token / quoted-
string)
diversion-extension = token [EQUAL (token / quoted-string)]
Note: The Diversion header could be used in the comma-separated
format as described below and in a header-separated format. Both
formats could be combined a received INVITE as RECOMMENDED in
[RFC3261].
Example:
Diversion:
diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1; privacy=off
Mohali, et al. Expires January 12, 2009 [Page 8]
Internet-Draft Mapping Diversion and History-Info July 2008
4. Headers in SIP METHOD
You can find here a reminder of History-Info header field and
Diversion header field in relation to methods. As those headers does
not have the same capabilities, it is necessary to clarify the
interworking.
Use of History-Info header field:
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
History-Info amdr - - - o o o o
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
History-Info amdr o o o - - - o
Use of Diversion header field:
Header field where enc. e-e ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- --- ---
Diversion R h - - - o - -
Diversion 3xx h - - - o - -
The recommended interworking presented in this document SHOULD apply
only for INVITE requests.
In 3xx responses, both headers could be present.
When a proxy wants to interwork with a network supporting the other
header field, it SHOULD apply the mapping between Diversion header
and History-Info header in the 3xx response.
When a recursing proxy redirects an initial INVITE after receving a
3xx response, it SHOULD add as a last entry either a Diversion header
or History-Info header (according its capabilities) in the forwarded
INVITE. Local policies could apply to send the received header in
the next INVITE or not.
Other messages where History-Info could be present are not used for
the Call Forwarding service and SHOULD NOT be changed into Diversion
header. The destination network MUST be transparent the received
History-Info header.
5. Diversion header to History-Info header
For N Diversion entries N+1 History-Info entries MUST be created. To
create the History-Info entries in the same order than during a
session establishment, the Diversion entries MUST be mapped from the
bottom-most until the top-most.
Mohali, et al. Expires January 12, 2009 [Page 9]
Internet-Draft Mapping Diversion and History-Info July 2008
The first entry created in the History-Info header contains:
- a hi-target-to-uri with the name-addr parameter of the bottom-
most Diversion header
- the privacy entry mapping the privacy parameter of the bottom-
most Diversion header,
- an index set to 1.
For the each Diversion header, the next History-info entries are
mapped as following:
Mohali, et al. Expires January 12, 2009 [Page 10]
Internet-Draft Mapping Diversion and History-Info July 2008
Source Destination
Diversion header component: History-Info header component:
=============================================================================
Name-addr of the previous Hi-target-to-uri
(on top) Diversion header.
If there is no previous(top-most),
it is the Request-URI address.
=============================================================================
Reason Cause
"unknown"--------------------------------------404
"unconditional"--------------------------------302
"user-busy"------------------------------------486
"No-answer"------------------------------------408
"deflection "----------------------------------480
"Unavailable"----------------------------------503
"time-of-day"----------------------------------404 (default) or 302
"do-not-disturb"-------------------------------404 (default) or 302
"follow-me"------------------------------------404 (default) or 302
"out-of-service"-------------------------------404 (default)
"away"-----------------------------------------404 (default) or 302
=============================================================================
Counter Hi-index
"1" or parameter ------------------------------The previous created index
no present is incremented with ".1"
Superior to "1" -------------------------------1+[(N-1)*".1"]
(i.e. N)
=============================================================================
Privacy of the previous Privacy escaped in the
(on top) Diversion header. hi-targeted-to-uri
If there is no previous(top-most),
no privacy parameter is created.
"full"-----------------------------------------"history"
"Off"------------------------------------------Privacy header field
absent or "none"
"name"-----------------------------------------"history"
"uri"------------------------------------------"history"
=============================================================================
Note: For other optional Diversion parameters, there is no
recommendation.
Note: For values of the "reason" parameter which are mapped with a
recommended default value, it could also be possible to choose an
other value or to omit the parameter.
Concerning local policies recommendations about headers coexistence
Mohali, et al. Expires January 12, 2009 [Page 11]
Internet-Draft Mapping Diversion and History-Info July 2008
in the INVITE request, see section 2.2.
6. History-Info header to Diversion header
As each previous diverting user MUST be present in the received
History-Info header, one Diversion header entry per diverting user
MUST be created in order to not to loose any diverting information.
For each History-Info header containing a cause-param with cause
value as listed in the [RFC4458]; a Diversion header entry MUST be
created. The first History-Info header entry selected will be mapped
into the last Diversion header entry and so on.
In this case, the History-Info header MUST be mapped into the
Diversion header as following:
Mohali, et al. Expires January 12, 2009 [Page 12]
Internet-Draft Mapping Diversion and History-Info July 2008
Source Destination
History-Info header component: Diversion header component:
============================================================================
Hi-target-to-uri of the Name-addr
History-Info which precedes the one
containing a diverting cause-param
============================================================================
Cause Reason
404--------------------------------------------"unknown"
302--------------------------------------------"unconditional"
486--------------------------------------------"user-busy"
408--------------------------------------------"No-answer"
480 or 487-------------------------------------"deflection "
503--------------------------------------------"Unavailable"
============================================================================
Hi-index Counter
Mandatory parameter for-------------------------The counter is set to "1".
History-Info reflecting
the chronological order
of the information.
============================================================================
Privacy escaped in the Privacy
hi-targeted-to-uri of the
History-Info which precedes the one
containing a diverting cause-param.
Optional parameter for History-Info,
this Privacy indicates that this
specific History-Info header SHOULD
not be forwarded.
"history"---------------------------------------"full"
Privacy header field ---------------------------"Off"
Absent or "none"
============================================================================
Privacy header [RFC3323] Privacy
The Privacy indicates that all
History-Info headers SHOULD NOT
be forwarded.
"history"---------------------------------------"full"
============================================================================
Concerning local policies recommendations about headers coexistence
in the INVITE request, see section 2.2.
Editor's note: Iinterworking with Voicemail URI, defined in
Mohali, et al. Expires January 12, 2009 [Page 13]
Internet-Draft Mapping Diversion and History-Info July 2008
[RFC4458], will be added in the next release of the document.
7. Examples
7.1. Example with Diversion header changed into History-Info header
INVITE last_diverting_target
Diversion:
diverting_user3_address;reason="unconditional";counter=1;privacy=off,
diverting_user2_address;reason="user-busy";counter=1;privacy=full,
diverting_user1_address;reason="no-answer";counter=1;privacy=off
Mapped into:
History-Info:
<sip: diverting_user1_address; privacy=none >; index=1,
<sip: diverting_user2_address; privacy=history, reason=SIP;
cause=408>index=1.1,
<sip: diverting_user3_address; privacy=none, reason=SIP;
cause=486>index=1.1.1,
<sip: last_diverting_target; Reason=SIP; cause=302>index=1.1.1.1,
7.2. Example with History-Info header changed into Diversion header
History-Info:
<sip: diverting_user1_address ;Privacy=history >; index=1,
<sip: diverting_user2_address; Privacy=none; Reason=SIP;
cause=302>index=1.1,
<sip: last_diverting_target; Reason=SIP; cause=486>index=1.1.1
Mapped into:
Diversion:
diverting_user2_address; reason="user-busy"; counter=1; privacy=off,
diverting_user1_address; reason="unconditional"; counter=1;
privacy=full
7.3. Example with two SIP networks using History-Info header
interworking with a SIP network using Diversion header
A -> P1 -> B -> C -> P2 -> D-> E
A, B, C, D and E are users.
B, C and D have Call Forwarding service invoked.
P1 and P2 are proxies.
Only relevant information is shown on the following call flow.
Mohali, et al. Expires January 12, 2009 [Page 14]
Internet-Draft Mapping Diversion and History-Info July 2008
IWF* IWF*
SIP network using | SIP network using |SIP network
History-Info | Diversion |using
| |History-Info
| |
UA A P1 AS B | P2 AS C UE C AS D | UE E
| | | | | | | | | |
|INVITE | | | | | | | | |
|------>| | | | | | | | |
| | | | | | | | | |
| |INVITE | | | | | | | |
| |------>| | | | | | | |
| |Supported: histinfo | | | | | |
| | History-Info: | | | | | |
| | <sip:proxyP1>; index=1, | | | | |
| | <sip:userB >; index=1.1 | | | | |
| | | | | | | | | |
| | |INVITE | | | | | | |
| | |------>| | | | | | |
| | |History-Info: | | | | | |
| | |<sip:proxyP1>; index=1,| | | | |
| | |<sip:userB>; index=1.1 | | | | |
| | |<sip:userC>; cause=302; index=1.1.1 | | |
| | | | | | | | | |
| | | |INVITE | | | | | |
| | | |------>| | | | | |
| | | |Diversion: | | | | |
| | | |B reason= unconditional counter=1 | |
| | | |History-Info: | | | | |
| | | |<sip:proxyP1>; index=1,| | | |
| | | |<sip:userB>; index=1.1 | | | |
| | | |<sip:proxyP2>; cause=302; index=1.1.1 | |
| | | | | | | | | |
| | | | |INVITE | | | | |
| | | | |------>| | | | |
| | | | |No modification of Diversion due to P2 |
| | | | | | | | | |
| | | | | |INVITE | | | |
| | | | | |------>| | | |
| | | | | | | | | |
| | | | | |<--180-| | | |
| | | | | | | | | |
| | | | | No response timer expire | |
| | | | | |---INVITE----->| | |
| | | Diversion: | | |
| | | userC; reason=no-answer; counter=1; privacy=full,
| | | userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | | |
Mohali, et al. Expires January 12, 2009 [Page 15]
Internet-Draft Mapping Diversion and History-Info July 2008
| | | <sip:proxyP1>; index=1, | | |
| | | <sip:userB>; index=1.1 | | |
| | | <sip:proxyP2>; cause=302; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | |INVITE | |
| | | | | | | |------>| |
| | | Diversion: | |
| | | userD; reason=time-of-day; counter=1; privacy=off |
| | | userC; reason=no-answer; counter=1; privacy=full, |
| | | userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | |
| | | <sip:proxyP1>; index=1, | |
| | | <sip:userB>; index=1.1 | |
| | | <sip:proxyP2>; cause=302; index=1.1.1 | |
| | | | | | | | | |
| | | | | | | | | INVITE |
| | | | | | | | |-------->|
| | | History-Info: |
| | | <sip:proxyP1>; index=1, |
| | | <sip:userB>; index=1.1; privacy=none, |
| | | <sip:proxyP2>; cause=302; index=1.1.1, |
| | | <sip:userC>; privacy=history; index=1.1.1.1, |
| | | <sip:userD>; cause=408; privacy=none; index=1.1.1.1.1,
| | | <sip:userE>; cause=404; index=1.1.1.1.1.1 |
| | | | | | | | | |
| | | | | | | | | |
* Note: The IWF is an interworking function which could be a stand-alone equipment not defined in this draft.
8. IANA Considerations
This document makes no request of IANA.
9. Security Considerations
The use of Diversion header or History-Info header require to apply
the requested privacy and integrity asked by each diverting user or
entity. Without integrity, the requested privacy functions could be
downgraded or eliminated, potentially exposing identity information.
Without confidentiality, eavesdroppers on the network (or any
intermediaries between the user and the privacy service) could see
the very personal information that the user has asked the privacy
service to obscure. Unauthorised insertion, deletion of modification
of those headers can provide misleading information to users and
applications. A SIP entity that can provide a redirection reason in
a History-Info header or Diversion header SHOULD be able to suppress
Mohali, et al. Expires January 12, 2009 [Page 16]
Internet-Draft Mapping Diversion and History-Info July 2008
this in accordance with privacy requirements of the user concerned.
10. References
10.1. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3969] "The Internet Assigned Number Authority (IANA) Uniform
Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP), BCP 99", RFC 3969,
December 2004.
[RFC4234] "Augmented BNF for Syntax Specifications: ABNF", RFC 4234,
October 2005.
10.2. Informative References
[RFC3323] "A Privacy Mechanism for the Session Initiation Protocol
(SIP)", RFC 3323, November 2002.
[RFC4244] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 4244, November 2005.
[RFC4458] "Session Initiation Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice Response (IVR)",
RFC 4458, April 2006.
[TS_183004]
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN), "PSTN/ISDN
simulation services: Communication Diversion (CDIV);
Protocol specification, Release 2, ETSI TS 183004",
November 2007.
[TS_24.604]
3rd Generation Partnership Project, "Technical
Specification Group Core Network and Terminals ;
Communication Diversion (CDIV) using IP Multimedia
(IM)Core Network (CN) subsystem ; Protocol specification
(Release 8), 3GPP TS 24.604", April 2008.
[draft-levy-sip-diversion-08]
"Diversion Indication in SIP,
Mohali, et al. Expires January 12, 2009 [Page 17]
Internet-Draft Mapping Diversion and History-Info July 2008
draft-levy-sip-diversion-08", August 2004.
Authors' Addresses
Marianne Mohali
France Telecom
38-40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794
France
Phone: +33 1 45 29 45 14
Email: marianne.mohali@orange-ftgroup.com
Steve Norreys
British Telecom
Jan Van Gee
Belgacom
Martin Dolly
ATT
Francisco Silva
Portugal Telecom
Guiseppe Sciortino
Italtel
Cinzia Amenta
Italtel
Mohali, et al. Expires January 12, 2009 [Page 18]
Internet-Draft Mapping Diversion and History-Info July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Mohali, et al. Expires January 12, 2009 [Page 19]