Subject: [Sip] RFC 5658 on Addressing Record-Route Issues in the Session Initiation Protocol (SIP)

From: [email-masked]
Date: Fri, 23 Oct 2009 16:19:59 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 5658

        Title:      Addressing Record-Route Issues in the 
                    Session Initiation Protocol (SIP) 
        Author:     T. Froment, C. Lebel,
                    B. Bonnaerens
        Status:     Standards Track
        Date:       October 2009
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      18
        Characters: 39219
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sip-record-route-fix-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5658.txt

A typical function of a Session Initiation Protocol (SIP) Proxy is to
insert a Record-Route header into initial, dialog-creating requests in
order to make subsequent, in-dialog requests pass through it.  This
header contains a SIP Uniform Resource Identifier (URI) or SIPS
(secure SIP) URI indicating where and how the
subsequent requests should be sent to reach the proxy.  These SIP or SIPS
URIs can contain IPv4 or IPv6 addresses and URI parameters that could
influence the routing such as the transport parameter (for example,
transport=tcp), or a compression indication like "comp=sigcomp".  When
a proxy has to change some of those parameters between its incoming
and outgoing interfaces (multi-homed proxies, transport protocol
switching, or IPv4 to IPv6 scenarios, etc.), the question arises on
what should be put in Record-Route header(s).  It is not possible to
make one header have the characteristics of both interfaces at the
same time.  This document aims to clarify these scenarios and fix bugs
already identified on this topic; it formally recommends the use of
the double Record-Route technique as an alternative to the current RFC
3261 text, which describes only a Record-Route rewriting solution.  
[STANDARDS TRACK]

This document is a product of the Session Initiation Protocol Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute