Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
RFC 3608

 
Document Type RFC - Proposed Standard (October 2003; No errata)
Updated by RFC 5630
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3608 (Proposed Standard)
Telechat date
Responsible AD Allison Mankin
Send notices to <dean.willis@softarmor.com>, <rohan@cisco.com>
Network Working Group                                          D. Willis
Request for Comments: 3608                              dynamicsoft Inc.
Category: Standards Track                                   B. Hoeneisen
                                                                  Switch
                                                            October 2003

       Session Initiation Protocol (SIP) Extension Header Field
            for Service Route Discovery During Registration

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 (2003).  All Rights Reserved.

Abstract

   This document defines a Session Initiation Protocol (SIP) extension
   header field used in conjunction with responses to REGISTER requests
   to provide a mechanism by which a registrar may inform a registering
   user agent (UA) of a service route that the UA may use to request
   outbound services from the registrar's domain.

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Discussion of Mechanism  . . . . . . . . . . . . . . . . . .   4
   4.  Applicability Statement  . . . . . . . . . . . . . . . . . .   5
   5.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       6.1.  Procedures at the UA . . . . . . . . . . . . . . . . .   6
       6.2.  Procedures at the Proxy  . . . . . . . . . . . . . . .   7
       6.3.  Procedures at the Registrar  . . . . . . . . . . . . .   8
       6.4.  Examples of Usage  . . . . . . . . . . . . . . . . . .   9
             6.4.1.  Example of Mechanism in REGISTER Transaction .   9
             6.4.2.  Example of Mechanism in INVITE Transaction . .  12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
   9.  Normative References . . . . . . . . . . . . . . . . . . . .  15
   10. Informative References . . . . . . . . . . . . . . . . . . .  15

Willis & Hoeneisen          Standards Track                     [Page 1]
RFC 3608       SIP Extension for Service Route Discovery    October 2003

   11. Intellectual Property Statement. . . . . . . . . . . . . . .  16
   12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  16
   13. Full Copyright Statement . . . . . . . . . . . . . . . . . .  17

1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

2.  Background

   The Third Generation Partnership Project (3GPP) established a
   requirement for discovering home proxies during SIP registration and
   published this requirement in [6].  The 3GPP network dynamically
   assigns a home service proxy to each address-of-record (AOR).  This
   assignment may occur in conjunction with a REGISTER operation, or
   out-of-band as needed to support call services when the address-of-
   record has no registrations.  This home service proxy may provide
   both inbound (UA terminated) and outbound (UA originated) services.

   In the inbound case, the Request-Uniform Resource Identifier (URI) of
   incoming SIP requests matches the address-of-record of a user
   associated with the home service proxy.  The home service proxy then
   (in most cases) forwards the request to the registered contact
   address for that AOR.  A mechanism for traversing required proxies
   between the home service proxy and the registered UA is presented in
   [4].

   Outbound (UA originated) session cases raise another issue.
   Specifically, "How does the UA know which service proxy to use and
   how to get there?"

   Several mechanisms were proposed in list discussions, including:

   1. Configuration data in the UA.  This raises questions of UA
      configuration management and updating, especially if proxy
      assignment is very dynamic, such as in load-balancing scenarios.

   2. Use of some other protocol, such as HTTP, to get configuration
      data from a configuration server in the home network.  While
      functional, this solution requires additional protocol engines,
Show full document text