Addressing Record-Route Issues in the Session Initiation Protocol (SIP)
RFC 5658

Document Type RFC - Proposed Standard (October 2009; No errata)
Last updated 2013-03-02
Replaces draft-froment-sip-record-route-fix
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5658 (Proposed Standard)
Telechat date
Responsible AD Robert Sparks
Send notices to sip-chairs@ietf.org, draft-ietf-sip-record-route-fix@ietf.org, tfroment@gmail.com, nils@ohlmeier.com
Network Working Group                                         T. Froment
Request for Comments: 5658                                   Tech-invite
Category: Standards Track                                       C. Lebel
                                                           B. Bonnaerens
                                                          Alcatel-Lucent
                                                            October 2009

                   Addressing Record-Route Issues in
                 the Session Initiation Protocol (SIP)

Abstract

   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.

Status of This Memo

   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.

Froment, et al.             Standards Track                     [Page 1]
RFC 5658                  SIP Record-Route Fix              October 2009

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Problem Statement ...............................................4
      3.1. Background: Multi-Homed Proxies ............................4
      3.2. Identified Problems ........................................5
   4. Record-Route Rewriting ..........................................6
   5. Double Record-Routing ...........................................6
   6. Usage of Transport Protocol Parameter ..........................10
      6.1. UA Implementation Problems and Recommendations ............10
      6.2. Proxy Implementation Problems and Recommendations .........14
   7. Conclusion .....................................................15
   8. Security Considerations ........................................16
   9. Acknowledgments ................................................16
   10. References ....................................................17
      10.1. Normative References .....................................17
      10.2. Informative References ...................................17

Froment, et al.             Standards Track                     [Page 2]
RFC 5658                  SIP Record-Route Fix              October 2009

1.  Introduction

   Over the years, it has been noticed in interoperability events like
   SIPit, that many implementations had interoperability problems due to
   various Record-Routing issues or misinterpretations of [RFC3261]; in
   particular, when a change occurs between the incoming and outgoing
   sides of a proxy: transport protocol switching, "multi-homed" proxies
Show full document text