[MEDIACTRL] Revised RFC errata report on erratum 1994 to RFC 5552 (SIP Interface to VoiceXML Media Services)

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 20 January 2011 03:06 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A13E3A7085 for <mediactrl@core3.amsl.com>; Wed, 19 Jan 2011 19:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level:
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDs83pfqX8Ly for <mediactrl@core3.amsl.com>; Wed, 19 Jan 2011 19:06:20 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3280F3A7080 for <mediactrl@ietf.org>; Wed, 19 Jan 2011 19:06:19 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJI2N02HCzI1/2dsb2JhbACkSnOkNwKYVYVQBIRviW4
X-IronPort-AV: E=Sophos;i="4.60,347,1291611600"; d="scan'208";a="228367054"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Jan 2011 22:08:59 -0500
X-IronPort-AV: E=Sophos;i="4.60,347,1291611600"; d="scan'208";a="586135602"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Jan 2011 22:08:58 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 19 Jan 2011 22:08:58 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Date: Wed, 19 Jan 2011 22:08:18 -0500
Thread-Topic: Revised RFC errata report on erratum 1994 to RFC 5552 (SIP Interface to VoiceXML Media Services)
Thread-Index: AQHLuE9gqGTu8rbdmkKjlG+EA8GN3Q==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B220A1767C3@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MEDIACTRL] Revised RFC errata report on erratum 1994 to RFC 5552 (SIP Interface to VoiceXML Media Services)
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jan 2011 03:06:22 -0000

This revision incorporates Mark Scott's suggestion of 4 Jan 2010.
This revision removes discussion of the "uri" and "si" values, which
will be handled elsewhere.
======================================================================
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.  Each entry (hi-entry) in the
     History-Info header is mapped, in order, into an element of the
     session.connection.redirect array.
======================================================================

Dale