Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000188998D
Original Publication Date: 2009-Oct-01
Included in the Prior Art Database: 2009-Oct-24
Document File: 36 page(s) / 39K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Froment: AUTHOR [+3]

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 7% of the total text.

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 i...