Skip to main content

Addressing Record-Route issues in Session Initiation Protocol (SIP)
draft-froment-sip-record-route-fix-00

Document Type Replaced Internet-Draft (individual)
Expired & archived
Authors Thomas Froment , Christophe Lebel
Last updated 2007-07-03 (Latest revision 2007-02-26)
Replaced by draft-ietf-sip-record-route-fix
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-ietf-sip-record-route-fix
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

A typical function of a Session Initiation Protocol (SIP) Proxy is to set a Record-Route header on initial requests in order to make subsequent requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and URI parameters that could influence the routing like different transport parameters (UDP, TCP, SCTP...), 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 switching, sip to sips or IPV4 to IPV6 scenarios...), the question arises on what should be put in Record- Route: it is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally suggests the use of the double Record-Route technique as a replacement to the current RFC3261 text, which only describes Record-Route rewriting solution.

Authors

Thomas Froment
Christophe Lebel

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)