RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5552, "SIP Interface to VoiceXML Media Services", May 2009

Source of RFC: mediactrl (rai)
See Also: RFC 5552 w/ inline errata

Errata ID: 1994
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Henry Lum
Date Reported: 2010-01-04
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

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.

--- From reviewer Dale Worley ---

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.

Report New Errata



Advanced Search