RFC 3327 (rfc3327) - Page 2 of 17

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

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