[MEDIACTRL] RFC errata report on erratum 1994 to RFC 5552 (SIP Interface to VoiceXML Media Services)
"Worley, Dale R (Dale)" <firstname.lastname@example.org> Fri, 07 January 2011 15:50 UTC
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9C03A6912 for <email@example.com>; Fri, 7 Jan 2011 07:50:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([188.8.131.52]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-Vpk1o4qUul for <firstname.lastname@example.org>; Fri, 7 Jan 2011 07:50:16 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [184.108.40.206]) by core3.amsl.com (Postfix) with ESMTP id 2F2653A6905 for <email@example.com>; Fri, 7 Jan 2011 07:50:15 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.60,289,1291611600"; d="scan'208";a="258508655"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([220.127.116.11]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jan 2011 10:52:14 -0500
X-IronPort-AV: E=Sophos;i="4.60,289,1291611600"; d="scan'208";a="567595205"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([18.104.22.168]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jan 2011 10:52:14 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 7 Jan 2011 10:52:13 -0500
From: "Worley, Dale R (Dale)" <firstname.lastname@example.org>
To: "email@example.com" <firstname.lastname@example.org>, Robert Sparks <email@example.com>
Date: Fri, 7 Jan 2011 10:51:40 -0500
Thread-Topic: RFC errata report on erratum 1994 to RFC 5552 (SIP Interface to VoiceXML Media Services)
Content-Type: text/plain; charset="us-ascii"
Subject: [MEDIACTRL] RFC errata report on erratum 1994 to RFC 5552 (SIP Interface to VoiceXML Media Services)
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2011 15:50:17 -0000
====================================================================== RFC5552, "SIP Interface to VoiceXML Media Services" Source of RFC: mediactrl (rai) Errata ID: 1994 Status: Reported Type: Technical Reported By: Henry Lum Date Reported: 2010-01-04 Section 2.4 says: session.connection.redirect: This array is populated by information contained in the History-Info [RFC4244] header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in reverse order, into an element of the session.connection.redirect array. It should say: session.connection.redirect: This array is populated by information contained in the History-Info [RFC4244] header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in order appeared in the History-Info header, into an element of the session.connection.redirect array. Notes: The elements in the History info header is designed as a tree-like structure from the origination to the destination where each forwarding proxy appends to the end of the header and add an index. The original RFC text requires that the elements to be shown in VXML session.connection.redirect array in reverse order and this is incorrect based on the definition of session.connection.redirect. The first element in the array should be the original called number which maps to index=1 in history-info, and the last element should be the last redirected number which is the last element in history-info. ---------------------------------------------------------------------- Recommended status: (correct) Verified The definition of session.connection.redirect from the VXML 2.0 specification (http://www.w3.org/TR/2004/REC-voicexml20-20040316/) is: session.connection.redirect This variable is an array representing the connection redirection paths. The first element is the original called number, the last element is the last redirected number. Each element of the array contains a uri, pi (presentation information), si (screening information), and reason property. The reason property can be either "unknown", "user busy", "no reply", "deflection during alerting", "deflection immediate response", "mobile subscriber not reachable". As such, copying the History-Info values into session.connection.redirect in the same order is somewhat more correct, as the first History-Info value should be the original request-URI. But History-Info may contain other values other than the ones that are ancestral to the INVITE containing it, and assembling the correct redirection sequence may require some additional processing. Also, the definition of History-Info is being updated (draft-ietf-sipcore-rfc4244bis) to provide better recording of redirection sequences. Documenting how to extract the redirection sequence in a way that would work in all cases is a significant piece of work. Currently, the best straightforward specification is to map the elements in forward order: session.connection.redirect: This array is populated by information contained in the History-Info [RFC4244] header in the initial INVITE or is otherwise undefined. Entries (hi-entry) in the History-Info header are mapped, in order they appear in the History-Info header, into elements of the session.connection.redirect array. It appears that definitions of the component values of the array elements need amending as well: * uri - Set to the hi-targeted-to-uri value of the History-Info entry Strictly speaking, the hi-targeted-to-uri contains "header parameters", including "Reason" and "Privacy", which are not derived from the request-URI of the corresponding INVITE, and are not meaningful considered as part of that URI. So this definition should be "Set to the hi-targeted-to-uri value, without 'headers', of the History-Info entry" * si - Set to the value of the "si" parameter if it exists, undefined otherwise I can find no reference to the "si" value in VXML 2.0, RFC 4244, or in draft-ietf-sipcore-rfc4244bis-02 -- is this entry a mistake? Ironically, taken verbatim, this definition requires the "si" value to always be undefined, which is the same effect as if its definition were deleted from the RFC. ====================================================================== Dale
- [MEDIACTRL] RFC errata report on erratum 1994 to … Worley, Dale R (Dale)