Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)

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 and Diversion 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.

To transport diversion information, the History-Info header and an URI extension are advocated in the standardized Communication Diversion (CDIV) service Protocol Specifications and . 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 , 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 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).

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.

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 . 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 . 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.

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 . 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 . It is also possible to introduce the Privacy header defined in 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 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 , 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.

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 .Example: Diversion: diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, diverting_user1_addr; reason="unconditional"; counter=1; privacy=off

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.

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.

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 ; 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 , will be added in the next release of the document.

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,

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

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.

This document makes no request of IANA.

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.