SIP -- Session Initiation Protocol D. Willis
Working Group dynamicsoft Inc.
Internet-Draft B. Hoeneisen
Expires: October 18, 2002 Nokia
April 19, 2002
SIP Extension Header for Service Route Discovery in Private Networks
draft-willis-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 October 18, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document proposes a private SIP extension header used in
conjunction with responses to REGISTER messages 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 October 18, 2002 [Page 1]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion of Mechanism . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . . 5
5.2 Procedures at the Proxy . . . . . . . . . . . . . . . . . . . 6
5.3 Procedures at the Registrar . . . . . . . . . . . . . . . . . 6
5.4 Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 6
5.5 Example of Mechanism in REGISTER Transaction . . . . . . . . . 6
5.6 Example of Mechanism in INVITE Transaction . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . . 11
Non-Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
Willis & Hoeneisen Expires October 18, 2002 [Page 2]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
1. Background
3GPP established a requirement for discovering home proxies during
SIP registration and published this requirement in [3GPPReq]. 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.
The home proxy network routes inbound messages 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. This mechanism deals with
inbound (UA terminated) messages.
Outbound (UA originated) messages 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 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
messages. 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 message 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 a REGISTER
message between the UA and the associated registrar, then storing
that route in the UA and reusing it as a service route on future
messages 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 in
the REGISTER response. While similar to the previous
Willis & Hoeneisen Expires October 18, 2002 [Page 3]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
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 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 messages from UA1 may be routed
(at the discretion of UA1) through HSP, thereby receiving outbound
services from HSP.
2. Discussion of Mechanism
The proposed mechanism uses a private header "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.
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
that the registering UA may use to send messages through the service
proxy selected by the registrar. The UA would use this route by
inserting it as a preloaded Route header in messages originated by
the UA intended for routing through the service proxy.
Willis & Hoeneisen Expires October 18, 2002 [Page 4]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
The mechanism by which the registrar constructs the header value is
specific to the local implementation and outside the scope of this
document.
3. 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.
4. Syntax
The syntax for the P-Service-Route header 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 headers is described in Table 2 of [1]. The
following additions to this table are needed for P-Service-Route.
Addition of P-Service-Route to SIP Table 2:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
P-Service-Route R amr - - - - - o -
P-Service-Route 2xx amr - - - - - o -
5. Usage
5.1 Procedures at the UA
The UA performs a register as usual. The register response may
contain a "P-Service-Route" header. If so, the UA MAY store the
value of the P-Service-Route header in an association with the
address-of-record for which the REGISTER message had registered a
Willis & Hoeneisen Expires October 18, 2002 [Page 5]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
contact. If the UA supports multiple address of records, it may be
able to store multiple service routes, one per address-of-record.
The UA MAY choose to exercise a service route for future messages
associated with a given address-of-record for which a service route
is known. If so, it appends the given service route to any local
required Route headers, and uses the result as a preloaded Route
header in outgoing messages.
5.2 Procedures at the Proxy
The P-Service-Route header is treated like any other unknown header
by intermediate proxies. They simply forward it on towards the
destination.
5.3 Procedures at the Registrar
When a registrar receives a successful REGISTER message, it MAY
choose to return a P-Service-Route header in the 200 OK response.
The determinations of whether to include this header into the 200 OK
response and what value to insert are a matter of local policy and
outside the scope of this document. Having inserted a P-Service-
Route header, the registrar returns the 200 OK response to the UA in
accordance with standard procedures.
5.4 Examples of Usage
We present 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-----|
5.5 Example of Mechanism in REGISTER Transaction
This example shows the message sequence for UA1 registering to
HOMEDOMAIN using registrar R. R returns a P-Service-Route indicating
Willis & Hoeneisen Expires October 18, 2002 [Page 6]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
that UA1 may use home service proxy HSP to receive outbound services
from HOMEDOMAIN.
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: UA@HOMEDOMAIN <UA1@HOMEDOMAIN>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
. . .
F2 Register P1 -> P2
REGISTER sip:HOMEDOMAIN SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
To: UA@HOMEDOMAIN <UA@HOMEDOMAIN>
From: UA@REGISTAR <UA@REGISTAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
. . .
F3 Register P2 -> R
REGISTER sip:HOMEDOMAIN SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
To: UA@HOMEDOMAIN <UA@HOMEDOMAIN>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
. . .
F4 R executes Register
R Stores:
Willis & Hoeneisen Expires October 18, 2002 [Page 7]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
For UA1@P2
Contact = <sip:UA1@192.0.2.4>
F5 R calculates Service Route
Statically configured to reference HSP as a Service Route
P-Service-Route=<sip:HSP;lr>
F6 Register Response r -> P2
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
To: UA@HOMEDOMAIN <sip:UA@P2>
From: UA@HOMEDOMAIN <sip:UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@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 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
To: UA@HOMEDOMAIN <sip:UA@HOMEDOMAIN>
From: UA@HOMEDOMAIN <sip:UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
P-Service-Route=<sip:HSP;lr>
. . .
F8 Register Response P1 -> UA
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA@HOMEDOMAIN <sip:UA@HOMEDOMAIN>
From: UA@HOMEDOMAIN <sip:UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
Willis & Hoeneisen Expires October 18, 2002 [Page 8]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
P-Service-Route=<sip:HSP;lr>
. . .
F9 UA stores service route for HOMEDOMAIN
5.6 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 "speed dial" service, where
the user's private speed dial code "Joe" is expanded to "sip:Joe@UA2"
by the action of HSP.
Message sequence for INVITE using P-Service-Route:
F1 INVITE UA1 -> P1
INVITE sip:joe SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: Joe <sip:joe>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@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:joe SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
To: Joe <sip:joe>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@192.0.2.4>
Record-Route <sip:P1;lr>
Route: <sip:HSP;lr>
. . .
Willis & Hoeneisen Expires October 18, 2002 [Page 9]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
(note: P2 is selected using a DNS lookup on the domain of HSP)
F3 INVITE P2 -> HSP
INVITE sip:joe SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
To: Joe <sip:joe>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@192.0.2.4>
Record-Route <sip:P1;lr>
Record-Route <sip:P2;lr>
Route: <sip:HSP;lr>
. . .
(note: HSP is selected using a DNS lookup for HSP within HOMEDOMAIN)
F4 HSP executes service
looks up name "sip:joe" in UA1's profile, returns "sip:joe@UA2"
This will be request-URI of next-hop INVITE
F5 INVITE HSP->P2
INVITE sip:joe@UA2
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
Via: SIP/2.0/USP HSP:5060;branch=HSP10120323
To: Joe <sip:joe@UA2>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@192.0.2.4>
Record-Route <sip:P1;lr>
Record-Route <sip:P2;lr>
Record-Route <sip:HSP;lr>
. . .
(note: P2 selected by outbound proxy rule on HSP)
INVITE propagates toward UA2 as usual.
Willis & Hoeneisen Expires October 18, 2002 [Page 10]
Internet-Draft SIP Ext Header for Service Route Discovery April 2002
6. 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.
7. IANA Considerations
This document defines the SIP extension header "P-Service-Route"
which should be included in the registry of SIP headers defined in
SIP [1]. As required by the SIP change process draft-tsvarea-
sipchange [7] the SIP extension header name "Service-Route" should
also be registered in association with this extension.
Normative References
[1] Rosenberg, J., "SIP: Session Initiation Protocol draft-ietf-
sip-rfc2543bis-09.txt", March 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-3GPPRequirements.txt", March 2002.
[7] Mankin, A., "SIP Change Process draft-tsvarea-sipchange", March
2002.
Willis & Hoeneisen Expires October 18, 2002 [Page 11]
Internet-Draft SIP Ext Header for Service Route Discovery April 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 October 18, 2002 [Page 12]
Internet-Draft SIP Ext Header for Service Route Discovery April 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 October 18, 2002 [Page 13]