Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
RFC 3327

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                          D. Willis
Request for Comments: 3327                              dynamicsoft Inc.
Category: Standards Track                                   B. Hoeneisen
                                                                  Switch
                                                           December 2002

        Session Initiation Protocol (SIP) Extension Header Field
                 for Registering Non-Adjacent Contacts

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.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The REGISTER function is used in a Session Initiation Protocol (SIP)
   system primarily to associate a temporary contact address with an
   address-of-record.  This contact is generally in the form of a
   Uniform Resource Identifier (URI), such as Contact:
   <sip:alice@pc33.atlanta.com> and is generally dynamic and associated
   with the IP address or hostname of the SIP User Agent (UA).  The
   problem is that network topology may have one or more SIP proxies
   between the UA and the registrar, such that any request traveling
   from the user's home network to the registered UA must traverse these
   proxies.  The REGISTER method does not give us a mechanism to
   discover and record this sequence of proxies in the registrar for
   future use.  This document defines an extension header field, "Path"
   which provides such a mechanism.

Willis & Hoeneisen          Standards Track                     [Page 1]
RFC 3327          Path Extension Header Field for SIP      December 2002

Table of Contents

   1.    Background . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Applicability Statement  . . . . . . . . . . . . . . . . . .  3
   4.    Path Header Field Definition and Syntax  . . . . . . . . . .  3
   5.    Usage of Path Header Field . . . . . . . . . . . . . . . . .  5
   5.1   Procedures at the UA . . . . . . . . . . . . . . . . . . . .  5
   5.2   Procedures at Intermediate Proxies . . . . . . . . . . . . .  5
   5.3   Procedures at the Registrar  . . . . . . . . . . . . . . . .  6
   5.4   Procedures at the Home Proxy . . . . . . . . . . . . . . . .  6
   5.5   Examples of Usage  . . . . . . . . . . . . . . . . . . . . .  7
   5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . .  7
   5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   6.1   Considerations in REGISTER Request Processing  . . . . . . . 13
   6.2   Considerations in REGISTER Response Processing . . . . . . . 14
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
         Normative References . . . . . . . . . . . . . . . . . . . . 16
         Non-Normative References . . . . . . . . . . . . . . . . . . 16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 17

1. Background

   3GPP established a requirement for discovering intermediate proxies
   during SIP registration and published this requirement in [5].

   Scenario:

   UA1----P1-----P2-----P3------REGISTRAR

   UA1 wishes to register with REGISTRAR.  However, due to network
   topology, UA1 must use P1 as an "outbound proxy", and all requests
   between UA1 and REGISTRAR must also traverse P1, P2, and P3 before
   reaching REGISTRAR.  Likewise, all requests between REGISTRAR and UA1
   must also traverse P3, P2, and P1 before reaching UA1.

   UA1 has a standing relationship with REGISTRAR.  How UA1 establishes
   this relationship is outside the scope of this document.  UA1
   discovers P1 as a result of configuration, DHCP assignment or other
   similar operation, also outside the scope of this document.
   REGISTRAR has a similar "default outbound proxy" relationship with
   P3.

Willis & Hoeneisen          Standards Track                     [Page 2]
RFC 3327          Path Extension Header Field for SIP      December 2002

   Eventually, REGISTRAR or a "home proxy" (a proxy serving as the
   terminal point for routing an address-of-record) closely related to
   it will receive a request destined for UA1.  It needs to know which
   proxies must be transited by that request in order to get back to
   UA1.  In some cases, this information may be deducible from SIP
   routing configuration tables or from DNS entries.  In other cases,