| TOC |
|
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.
Both History-Info and Diversion headers are able to transport
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] (, “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.) 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.
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] (, “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
1.
Introduction
1.1.
Overview
1.2.
Background
2.
Problem Statement
2.1.
Interworking need
2.2.
Interworking recommendations
3.
Headers syntaxes reminder
3.1.
History-Info header syntax
3.2.
Diversion header syntax
4.
Headers in SIP METHOD
5.
Diversion header to History-Info header
6.
History-Info header to Diversion header
7.
Examples
7.1.
Example with Diversion header changed into History-Info header
7.2.
Example with History-Info header changed into Diversion header
7.3.
Example with two SIP networks using History-Info header interworking with a SIP network using Diversion header
8.
IANA Considerations
9.
Security Considerations
10.
References
10.1.
Normative References
10.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
| TOC |
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] (, “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.) and Diversion [draft‑levy‑sip‑diversion‑08] (, “Diversion Indication in SIP, draft-levy-sip-diversion-08,” August 2004.) 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.
| TOC |
To transport diversion information, the History-Info header [RFC4244] (, “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.) and an URI extension [RFC4458] (, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.) are advocated in the standardized
Communication Diversion (CDIV) service Protocol Specifications [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.) and [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.).
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] (, “Diversion Indication in SIP, draft-levy-sip-diversion-08,” August 2004.), 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] (, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.) 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).
| TOC |
| TOC |
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.
| TOC |
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 recommended in [RFC4244] (, “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.).
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] (, “Diversion Indication in SIP, draft-levy-sip-diversion-08,” August 2004.).
Note that the chronological order could not be certified. If previous
policy recommendations are 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.
| TOC |
| TOC |
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] (, “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.). 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] (, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.). It is also possible to
introduce the Privacy header defined in [RFC3323] (, “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.)
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] (, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.) 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,
<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] (, “An Extension to the Session Initiation Protocol (SIP) for Request History Information,” November 2005.), 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.
| TOC |
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] (, “SIP: Session Initiation Protocol,” June 2002.).
Example:
Diversion:
diverting_user2_addr; reason="user-busy"; counter=1;
privacy=full,
diverting_user1_addr; reason="unconditional";
counter=1; privacy=off
| TOC |
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.
| TOC |
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.
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:
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 in the INVITE request, see section 2.2.
| TOC |
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] (, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.); 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:
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 [RFC4458] (, “Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR),” April 2006.), will be added in the next release of the
document.
| TOC |
| TOC |
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,
| TOC |
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
| TOC |
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.
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: | | |
| | | <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.| TOC |
This document makes no request of IANA.
| TOC |
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 this in accordance
with privacy requirements of the user concerned.
| TOC |
| TOC |
| [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. |
| TOC |
| [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, draft-levy-sip-diversion-08,” August 2004. |
| TOC |
| Marianne Mohali | |
| France Telecom | |
| 38-40 rue du Général 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 |
| TOC |
Copyright © 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.
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.