SIP -- Session Initiation Protocol                             D. Willis
Working Group                                           dynamicsoft Inc.
Internet-Draft                                              B. Hoeneisen
Expires: November 14, 2002                                         Nokia
                                                            May 16, 2002


   SIP Extension Header Field for Service Route Discovery in Private
                                Networks
                     draft-willis-sip-scvrtdisco-05

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 14, 2002.

Copyright Notice

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

Abstract

   This document proposes a private SIP extension header field used in
   conjunction with responses to REGISTER requests to provide a
   mechanism by which a registrar may inform a registering UA of a
   service route that the UA may use to request outbound services from
   the registrar's domain.







Willis & Hoeneisen      Expires November 14, 2002               [Page 1]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


Table of Contents

   1.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.    Background . . . . . . . . . . . . . . . . . . . . . . . . .  3

   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  . . . . . . . . . . . . . . . . . .  6
   6.3   Procedures at the Registrar  . . . . . . . . . . . . . . . .  7
   6.4   Examples of Usage  . . . . . . . . . . . . . . . . . . . . .  8
   6.4.1 Example of Mechanism in REGISTER Transaction . . . . . . . .  8
   6.4.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 10

   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 12

   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 13

         Normative References . . . . . . . . . . . . . . . . . . . . 13

         Non-Normative References . . . . . . . . . . . . . . . . . . 14

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14

         Full Copyright Statement . . . . . . . . . . . . . . . . . . 15




















Willis & Hoeneisen      Expires November 14, 2002               [Page 2]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


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 RFC 2119 [3].

2. Background

   3GPP established a requirement for discovering home proxies during
   SIP registration and published this requirement in draft-garcia-
   sipping-3gpp-reqs [6].  Unlike many other network environments, the
   3GPP network dynamically assigns a home service proxy to each
   address-of-record.  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.

   For inbound (UA terminated) session cases, the home proxy network
   routes requests having a request-URI targeting the address-of-record
   associated with the UA to the assigned home service proxy by using
   some sort of look-up-mechanism outside the scope of this document.

   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 have been 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,
       firewall complexity, operations overhead, and a significant
       additional "over the air" traffic.
   3.  Use of lookup tables in the home network, as is done for inbound
       requests.  This has a relatively high overhead in terms of
       database operations.
   4.  Returning a 302 response indicating the service proxy as a new
       contact, causing the upstream node processing the 302 (ostensibly
       the UA) to retransmit the request toward the service proxy.
       While this shares the database operation of the previous
       alternative, it does explicitly allow for caching the 302
       response thereby potentially reducing the frequency and number of
       database operations.
   5.  Performing an operation equivalent to record-routing in a



Willis & Hoeneisen      Expires November 14, 2002               [Page 3]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


       REGISTER transaction between the UA and the associated registrar,
       then storing that route in the UA and reusing it as a service
       route on future requests originating from the UA.  While
       efficient, this constrains the service route for proxy operations
       to be congruent with the route taken by the REGISTER message.
   6.  Returning service route information as the value of a header
       field in the REGISTER response.  While similar to the previous
       alternative, this approach grants the ability for the registrar
       to selectively apply knowledge about the topology of the home
       network in constructing the service route.

   This document discusses this final alternative: using a header field
   in the REGISTER response to indicate a service route that the UA may
   wish to use if requesting services from the proxy network associated
   with the registrar generating the response.

   Scenario



       UA1----P1-----|    |--R-------|
                     |    |          |
                     P2---|         DBMS
                     |    |          |
       UA2-----------|    |--HSP-----|



   In this scenario, we have a "home network" containing routing proxy
   P2, registrar R, home service proxy HSP, and database DBMS used by
   both R and HSP.  P2 represents the "edge" of the home network from a
   SIP perspective, and might be called an "edge proxy".  UA1 is an
   external UA behind proxy P1.  UA1 discovers P1 via DHCP.  UA2 is
   another UA on the Internet, and does not use a default outbound
   proxy.  We do not show DNS elements in this diagram, but will assume
   their reasonable availability in the discussion.  The mission is for
   UA1 to discover HSP so that outbound requests from UA1 may be routed
   (at the discretion of UA1) through HSP, thereby receiving outbound
   services from HSP.

3. Discussion of Mechanism

   The proposed mechanism uses a private header field "P-Service-Route"
   in the REGISTER response to indicate a service route that the UA may
   wish to use if requesting services from the proxy network associated
   with the registrar generating the response.  The routing established
   by the P-Service-Route mechanism applies only to requests originating
   in the user agent.



Willis & Hoeneisen      Expires November 14, 2002               [Page 4]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


   Simply put, the registrar generates a service route for the
   registering UA and returns it in the response to each successful
   REGISTER request.  This service route has the form of a Route header
   field that the registering UA may use to send requests through the
   service proxy selected by the registrar.  The UA would use this route
   by inserting it as a preloaded Route header field in requests
   originated by the UA intended for routing through the service proxy.

   The mechanism by which the registrar constructs the header field
   value is specific to the local implementation and outside the scope
   of this document.

4. Applicability Statement

   The P-Service-Route mechanism is applicable when:

   1.  The UA registers with a REGISTRAR in a given domain.
   2.  The domain dynamically assigns a service proxy for the UA.
   3.  The registrar(s) in the domain has/have sufficient knowledge of
       the network topology, policy, and situation such that a
       reasonable service route can be constructed.
   4.  Other mechanisms for proposing a service route to the UA are not
       available or are inappropriate for use within the administrative
       domain.

5. Syntax

   The syntax for the P-Service-Route header field is:

   P-Service-Route = "P-Service-Route" HCOLON 1#( p-sr-value)

   p-sr-value = name-addr *( SEMI rr-param )

   rr-param = generic-param

   The allowable usage of header fields is described in Tables 2 and 3
   of SIPbis [1].  The following additions to this table are needed for
   P-Service-Route.

   Addition of P-Service-Route to SIP Table 3:


         Header field          where   proxy ACK BYE CAN INV OPT REG PRA
         _______________________________________________________________
         P-Service-Route        2xx      ar   -   -   -   -   -   o   -






Willis & Hoeneisen      Expires November 14, 2002               [Page 5]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


6. Usage

6.1 Procedures at the UA

   The UA performs a register as usual.  The register response may
   contain a P-Service-Route header field.  If so, the UA MAY store the
   value of the P-Service-Route header field in an association with the
   address-of-record for which the REGISTER transaction had registered a
   contact.  If the UA supports multiple address of records, it may be
   able to store multiple service routes, one per address-of-record.  If
   the UA refreshes the registration, the stored value of the P-Service-
   Route is updated according to the P-Service-Route header field of the
   latest 200 OK response.  If there is no P-Service-Route header field
   in the response, the UA clears any service route for that registrar
   previously stored by the UA.

   The UA MAY choose to exercise a service route for future requests
   associated with a given address-of-record for which a service route
   is known.  If so, it uses the content of the P-Service-Route header
   field as a preloaded Route header field in outgoing requests [1].
   The UA MUST preserve the order, in case there is more than one P-
   Service-Route header field or header field value.

   Loose routes may interact with routing policy in interesting ways.
   The specifics of how the service route set integrates with any
   locally required default route and local policy are implementation
   dependent.  For example, some devices will use locally-configured
   explicit loose routing to reach a next-hop proxy, and others will use
   a default outbound-proxy routing rule.  However, for the result to
   function, the combination MUST provide valid routing in the local
   environment.  In general, the service route set is appended to any
   locally configured route needed to egress the access proxy chain.
   Systems designers must match the service routing policy of their
   nodes with the basic SIP routing policy in order to get a workable
   system.

6.2 Procedures at the Proxy

   The P-Service-Route header field is generally treated like any other
   unknown header field by intermediate proxies.  They simply forward it
   on towards the destination.

   There is a question of whether proxies processing a REGISTER response
   may add themselves to the route set in the P-Service-Route header
   field.  While this would enable dynamic construction of service
   routes, it has two significant problems.  The first is one of
   transparency, as seen by the registrar: Intermediate proxies could
   add themselves without the knowledge or consent of the registrar.



Willis & Hoeneisen      Expires November 14, 2002               [Page 6]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


   The second problem is interaction with end-to-end security.  If the
   registrar uses S/MIME techniques to protect the REGISTER response,
   such additions would be visible to the UA as "man in the middle"
   alterations in the response.  Consequently, intermediate proxies
   SHOULD NOT alter the value of P-Service-Route in REGISTER responses,
   and if they do, acceptance of the alteration by the UA MUST NOT be
   required.

6.3 Procedures at the Registrar

   When a registrar receives a successful REGISTER request, it MAY
   choose to return one or more P-Service-Route header field(s) in the
   200 OK response.  The determinations of whether to include these
   header fields(s) into the 200 OK response and what value(s) to insert
   are a matter of local policy and outside the scope of this document.

   Having inserted a P-Service-Route header field or fields, the
   registrar returns the 200 OK response to the UA in accordance with
   standard procedures.

   A REGISTER operation performing a Fetching Bindings (i.e.  no Contact
   header field is present in the request) SHOULD return the same value
   of P-Service-Route as returned in the corresponding previous REGISTER
   response for the address-of-record in question.

   Note: A Fetching Bindings operation could be used by the UA to
      recover a lost value of P-Service-Route.

   Certain network topologies MAY require a specific proxy (e.g.
   firewall proxy) to be traversed before the home service proxy.  Thus,
   a registrar with specific knowledge of the network topology MAY
   return more than one P-Service-Route header field or element in the
   200 OK response; the order is specified as top-down, meaning the
   topmost P-Service-Route entry will be visited first.  Such
   constructions are implementation specific and outside the scope of
   this document.

   In general, the P-Service-Route header field contains references to
   elements strictly within the administrative domain of the registrar
   and home service proxy.  For example, consider a case where a user
   leaves the "home" network and roams into a "visited" network.  The
   registrar cannot be assumed to have knowledge of the topology of the
   visited network, so the P-Service-Route it returns contains elements
   only within the home network.

   Note that the inserted P-Service-Route element(s) MUST conform to the
   syntax of a Route element as defined in [1].  As suggested therein,
   such route elements MUST include the loose-routing indicator



Willis & Hoeneisen      Expires November 14, 2002               [Page 7]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


   parameter ";lr" for full compliance with [1]

6.4 Examples of Usage

   We present an example in the context of the scenario presented in the
   Background section earlier in this document.  The network diagram is
   replicated below:

   Scenario



     UA1----P1-----|    |--R-------|
                   |    |          |
                   P2---|         DBMS
                   |    |          |
     UA2-----------|    |--HSP-----|




6.4.1 Example of Mechanism in REGISTER Transaction

   This example shows the message sequence for user agent UA1
   registering to HOMEDOMAIN using registrar R.  R returns a P-Service-
   Route indicating that UA1 may use home service proxy HSP to receive
   outbound services from HOMEDOMAIN.

   Please note that the name UA1, HOMEDOMAIN, etc.  are placeholders for
   appropriate user and host names or addresses.

   Message sequence for REGISTER returning P-Service-Route:


   F1 Register UA1 -> P1

      REGISTER sip:HOMEDOMAIN SIP/2.0
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>
      From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
       . . .


   F2 Register P1 -> P2




Willis & Hoeneisen      Expires November 14, 2002               [Page 8]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


      REGISTER sip:HOMEDOMAIN SIP/2.0
      Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>
      From: UA1@REGISTAR <sip:UA1@REGISTAR>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
       . . .


   F3 Register P2 -> R

      REGISTER sip:HOMEDOMAIN SIP/2.0
      Via: SIP/2.0/UDP P2:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>
      From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
       . . .


   F4 R executes Register

      R Stores:
      For <sip:UA1@HOMEDOMAIN>
      Contact = <sip:UA1@192.0.2.4>


   F5 R calculates Service Route

      In this example, R is statically configured to reference HSP as a
      service route, so P-Service-Route = <sip:HSP;lr>


   F6 Register Response r -> P2

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP P2:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>
      From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER



Willis & Hoeneisen      Expires November 14, 2002               [Page 9]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


      Contact: <sip:UA1@192.0.2.4>
      P-Service-Route: <sip:HSP;lr>
       . . .


   F7 Register Response P2 -> P1

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>
      From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      P-Service-Route: <sip:HSP;lr>
       . . .


   F8 Register Response P1 -> UA1

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>
      From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      P-Service-Route: <sip:HSP;lr>
       . . .


   F9 UA1 stores service route for HOMEDOMAIN



6.4.2 Example of Mechanism in INVITE Transaction

   This example shows the message sequence for an INVITE transaction
   originating from UA1 eventually arriving at UA2 using outbound
   services from HOMEDOMAIN, where UA1 has previously registered with
   HOMEDOMAIN and been informed of a service route through HSP.  The
   service being provided by HOMEDOMAIN is a "logging" service, which
   provides a record of the call for UA1's use (perhaps the user of UA1
   is an attorney who bills for calls to customers).

   Message sequence for INVITE using P-Service-Route:




Willis & Hoeneisen      Expires November 14, 2002              [Page 10]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


   F1 INVITE UA1 -> P1

      INVITE sip:UA2@HOMEDOMAIN  SIP/2.0
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: Customer <sip:UA2@HOMEDOMAIN>
      From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 18 INVITE
      Contact: <sip:UA1@192.0.2.4>
      Route: <sip:HSP;lr>
       . . .

      Note: P1 is selected using the "outbound proxy" rule in UA1.


   F2 INVITE P1 -> P2

      INVITE sip:UA2@HOMEDOMAIN  SIP/2.0
      Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: Customer <sip:UA2@HOMEDOMAIN>
      From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 18 INVITE
      Contact: <sip:UA1@192.0.2.4>
      Record-Route: <sip:P1;lr>
      Route: <sip:HSP;lr>
       . . .

      Note: P2 is selected using a DNS lookup on the domain of HSP.
      P1 has added itself to the Record Route.


   F3 INVITE P2 -> HSP

      INVITE sip:UA2@HOMEDOMAIN  SIP/2.0
      Via: SIP/2.0/UDP P2:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: Customer <sip:UA2@HOMEDMAIN>
      From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 18 INVITE
      Contact: <sip:UA1@192.0.2.4>
      Record-Route: <sip:P2;lr>
      Record-Route: <sip:P1;lr>
      Route: <sip:HSP;lr>
       . . .



Willis & Hoeneisen      Expires November 14, 2002              [Page 11]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


      Note: HSP is selected using a DNS lookup for HSP within HOMEDOMAIN.
      P2 has addded itself to the Record Route.


   F4 HSP executes service

      HSP identifies the service to be executed from UA1's stored
      profile. The specifics of this are outside the scope of this
      document.  HSP writes a record to "Lawyer"s log book, then looks up
      name "sip:UA2@HOMEDOMAIN" and discovers that the current contact for
      UA2 is address 18.19.20.21.  This will be the request-URI of the
      next-hop INVITE


   F5 INVITE HSP->P2

      INVITE sip:UA2@18.19.20.21
      Via: SIP/2.0/USP HSP:5060;branch=z9hG4bKHSP10120323
      Via: SIP/2.0/UDP P2:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: Customer <sip:UA2@HOMEDOMAIN>
      From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 18 INVITE
      Contact: <sip:UA1@192.0.2.4>
      Record-Route: <sip:HSP;lr>
      Record-Route: <sip:P2;lr>
      Record-Route: <sip:P1;lr>
       . . .

      Note: P2 selected by outbound proxy rule on HSP.


   INVITE propagates toward UA2 as usual.



7. Security Considerations

   It is possible for proxies between the UA and the registrar during
   the REGISTER transaction to modify the value of P-Service-Route
   returned by the registrar, or to insert a P-Service-Route even when
   one was not returned by the registrar.  It is also possible for
   proxies on the INVITE path to execute many different attacks.  It is
   therefore desirable to apply transitive mutual authentication using
   sips: or other available mechanisms in order to prevent such attacks.




Willis & Hoeneisen      Expires November 14, 2002              [Page 12]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


   The "sips:" URI as defined in [1] defines a mechanism by which a UA
   may request transport-level message integrity and mutual
   authentication.  Since there is no requirement for proxies to modify
   message, S/MIME signed bodies may be used to provide end-to-end
   protection for the returned value.

   Systems using P-Service-Route SHOULD provide hop-by-hop message
   integrity and mutual authentication.  UAs SHOULD request this support
   by using a "sips:" URI.  Registrars returning a P-Service-Route
   SHOULD provide end-to-end protection on the return using S/MIME.  UAs
   receiving P-Service-Route SHOULD authenticate attached S/MIME bodies.

8. IANA Considerations

   This document defines the SIP extension header field "P-Service-
   Route" which should be included in the registry of SIP header fields
   defined in SIP bis [1].  As required by the SIP change process draft-
   tsvarea-sipchange [7] the SIP extension header field name "Service-
   Route" should also be registered in association with this extension.
   However, "Service-Route" MUST not be used until documented by a
   standards-track RFC.  Expert review as required for this process is
   to be provided by the SIP Working Group.

   The following is the registration for the P-Service-Route header
   field:

      RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
         this specification.]

      Header Field Name: P-Service-Route

      Compact Form: none


   The following is the registration for the Service-Route header field:

      RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
         this specification.] (not yet specified, only reserved)

      Header Field Name: Service-Route

      Compact Form: none


Normative References

   [1]  Rosenberg, J., "SIP: Session Initiation Protocol", draft-ietf-
        sip-rfc2543bis-09 (work in progress), March 2002.



Willis & Hoeneisen      Expires November 14, 2002              [Page 13]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
        2223, October 1997.

   [5]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

Non-Normative References

   [6]  Garcia-Martin, MA., "3GPP Requirements On SIP", draft-garcia-
        sipping-3gpp-reqs-03 (work in progress), March 2002.

   [7]  Mankin, A., "SIP Change Process", draft-tsvarea-sipchange-01
        (work in progress), March 2002.


Authors' Addresses

   Dean Willis
   dynamicsoft Inc.
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75028
   US

   Phone: +1 972 473 5455
   EMail: dwillis@dynamicsoft.com
   URI:   http://www.dynamicsoft.com/


   Bernie Hoeneisen
   Nokia
   Helsinki, Hiomo 3/6
   P.O. Box 312
   00045 NOKIA Group
   Finland

   Phone: +358-40-821 9 831
   EMail: bernhard.honeisen@nokia.com, b.hoeneisen@ieee.org
   URI:   http://www.nokia.com/






Willis & Hoeneisen      Expires November 14, 2002              [Page 14]


Internet-Draft    SIP Header Field for Service Route Discovery  May 2002


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Willis & Hoeneisen      Expires November 14, 2002              [Page 15]