Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
RFC 3327
Document | Type |
RFC - Proposed Standard
(December 2002; Errata)
Updated by RFC 5626
Was draft-willis-sip-path (sip WG)
|
|
---|---|---|---|
Authors | Dean Willis , Bernie Hoeneisen | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3327 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note | Published. | ||
Send notices to | <rohan@cisco.com> |
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,Show full document text