Addressing Record-Route Issues in the Session Initiation Protocol (SIP)
RFC 5658
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
(including IPv4 to IPv6 interface changes), etc. Multiple documents
have addressed the question, each of them generally providing an
adequate recommendation for its specific use case, but none of them
gives a general solution or provides a coherent set of
Show full document text