SIP -- Session Initiation Protocol D. Willis
Working Group dynamicsoft Inc.
Internet-Draft B. Hoeneisen
Expires: February 19, 2003 Nokia
August 21, 2002
Session Initiation Protocol Extension Header Field for Service Route
Discovery During Registration
draft-ietf-sip-scvrtdisco-01
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 February 19, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines a 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 February 19, 2003 [Page 1]
Internet-Draft SIP Header Field for Service Route Discovery August 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 . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . 13
Non-Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . 15
Willis & Hoeneisen Expires February 19, 2003 [Page 2]
Internet-Draft SIP Header Field for Service Route Discovery August 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 [2].
2. Background
3GPP established a requirement for discovering home proxies during
SIP registration and published this requirement in draft-garcia-
sipping-3gpp-reqs [5]. 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 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,
firewall complexity, operations overhead, and significant
additional "over the air" traffic.
3. Use of lookup tables in the home network, as may be done for
inbound requests in some 3G networks. 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
REGISTER transaction between the UA and the associated registrar,
Willis & Hoeneisen Expires February 19, 2003 [Page 3]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
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 defines 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 (this is just
an example, and other mechanisms besides DHCP are possible). 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 mechanism documented here uses a header field "Service-Route" in
the REGISTER response to indicate a service route that the UA may use
when requesting services from the proxy network associated with the
registrar generating the response. The routing established by the
Service-Route mechanism applies only to requests originating in the
user agent.
Willis & Hoeneisen Expires February 19, 2003 [Page 4]
Internet-Draft SIP Header Field for Service Route Discovery August 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 Service-Route mechanism is applicable when:
1. The UA registers with a registrar.
2. The registrar has knowledge of a service proxy that should be
used by the UA when requesting services from the domain of the
registrar. This knowledge may be a result of dynamic assignment
or some other mechanism outside the scope of this document.
3. The registrar(s) 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 specific
environment.
Other methods may also be available by which a UA may be informed of
a service route. Such alternative methods are outside the scope of
this document. Discussion of why one might wish to assign a service
route during registration or when it might be appropriate to do so is
outside the scope of this document.
5. Syntax
The syntax for the Service-Route header field is:
Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)
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 RFC 3261 [4]. The following additions to this table are needed
for Service-Route.
Willis & Hoeneisen Expires February 19, 2003 [Page 5]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
Addition of Service-Route to SIP Table 3:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Service-Route 2xx ar - - - - - o -
6. Usage
6.1 Procedures at the UA
The UA performs a registration as usual. The REGISTER response may
contain a Service-Route header field. If so, the UA MAY store the
value of the 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 addresses-of-record, 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 Service-
Route is updated according to the Service-Route header field of the
latest 200 OK response. If there is no Service-Route header field in
the response, the UA clears any service route for that registrar
previously stored by the UA. If the re-registration request is
refused or if an existing registration expires and the UA chooses not
to re-register, the UA SHOULD discard any stored service route for
that address-of-record.
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 Service-Route header
field as a preloaded Route header field in outgoing requests [4].
The UA MUST preserve the order, in case there is more than one
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.
Willis & Hoeneisen Expires February 19, 2003 [Page 6]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
6.2 Procedures at the Proxy
The 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 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.
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 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 Service-Route header field(s) in the 200
OK response. The determination(s) 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 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 Service-Route as returned in the corresponding previous REGISTER
response for the address-of-record in question. In some cases, the
Service-Route may be dynamically calculated by the registrar rather
than stored, and the decision as to whether this route should be
recalculated in the event of a Fetching Bindings operation is left to
the implementation.
Note: A Fetching Bindings operation could be used by the UA to
recover a lost value of Service-Route. Or, a UA in this situation
could just re-REGISTER.
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
Willis & Hoeneisen Expires February 19, 2003 [Page 7]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
return more than one Service-Route header field or element in the 200
OK response; the order is specified as top-down, meaning the topmost
Service-Route entry will be visited first. Such constructions are
implementation specific and outside the scope of this document.
In general, the 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 Service-Route it returns contains elements
only within the home network.
Note that the inserted Service-Route element(s) MUST conform to the
syntax of a Route element as defined in [4]. As suggested therein,
such route elements MUST include the loose-routing indicator
parameter ";lr" for full compliance with [4]
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-----------| |--HS------|
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 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 Service-Route:
Willis & Hoeneisen Expires February 19, 2003 [Page 8]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
F1 Register UA1 -> P1
REGISTER sip:HOMEDOMAIN SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: Lawyer <sip:UA1@HOMEDOMAIN>
From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
. . .
F2 Register P1 -> P2
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: Lawyer <sip:UA1@HOMEDOMAIN>
From: Lawyer <sip:UA1@HOMEDOMAIN>;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: Lawyer <sip:UA1@HOMEDOMAIN>
From: Lawyer <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
Willis & Hoeneisen Expires February 19, 2003 [Page 9]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
In this example, R is statically configured to reference HSP as a
service route, so 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: Lawyer <sip:UA1@HOMEDOMAIN>;tag=87654
From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
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: Lawyer <sip:UA1@HOMEDOMAIN>;tag=87654
From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
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: Lawyer <sip:UA1@HOMEDOMAIN>;tag=87654
From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Service-Route: <sip:HSP;lr>
. . .
F9 UA1 stores service route for HOMEDOMAIN
Willis & Hoeneisen Expires February 19, 2003 [Page 10]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
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 Service-Route:
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
Willis & Hoeneisen Expires February 19, 2003 [Page 11]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
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>
. . .
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. For this example 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 HS>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: Lawyer <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.
Willis & Hoeneisen Expires February 19, 2003 [Page 12]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
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 Service-Route
returned by the registrar, or to insert a 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.
The "sips:" URI as defined in RFC 3261 [4] 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
messages, S/MIME signed bodies may be used to provide end-to-end
protection for the returned value.
Systems using 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 Service-Route SHOULD
provide end-to-end protection on the return using S/MIME. UAs
receiving Service-Route SHOULD authenticate attached S/MIME bodies.
8. IANA Considerations
This document defines the SIP extension header field "Service-Route"
which shall be included in the registry of SIP header fields defined
in RFC 3261 [4]. The working process of the SIP Change Process [6]
mandates that general SIP extension header fileds be defined by a
standards-track RFC. This document provides the required definition.
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.]
Header Field Name: Service-Route
Compact Form: none
Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
Willis & Hoeneisen Expires February 19, 2003 [Page 13]
Internet-Draft SIP Header Field for Service Route Discovery August 2002
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Non-Normative References
[5] Garcia-Martin, MA., "3GPP Requirements On SIP", draft-garcia-
sipping-3gpp-reqs-03 (work in progress), March 2002.
[6] Mankin, A., "SIP Change Process", draft-tsvarea-sipchange-02
(work in progress), May 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
EMail: b.hoeneisen@ieee.org
URI: http://www.nokia.com/
Willis & Hoeneisen Expires February 19, 2003 [Page 14]
Internet-Draft SIP Header Field for Service Route Discovery August 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 February 19, 2003 [Page 15]
