Internet DRAFT - draft-alexiou-sipping-allocate
draft-alexiou-sipping-allocate
SIPPING Working Group T. Alexiou
Internet Draft J. Lennox
Document: <draft-alexiou-sipping-allocate-00.txt> K. Murakami
Lucent
Technologies
Expires: August 2002 February 2002
The SIP ALLOCATE Method
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 become obsolete 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.
The distribution of this memo is unlimited.
Abstract
This document defines ALLOCATE, a new method extending the SIP
protocol. ALLOCATE is a request to a SIP/PSTN gateway or Media
Gateway Controller to create a dynamic and short-lived binding
between a PSTN telephone number and a set of SIP URIs.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................1
1 Introduction.....................................................2
2 Example Use......................................................2
3 ALLOCATE Method..................................................3
3.1 Constructing the Request.......................................3
3.2 Processing the Request.........................................4
3.3 Call setup.....................................................5
4 Security Considerations..........................................5
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 1
<draft-alexiou-sipping-allocate-00.txt> February 2002
5 IANA Considerations..............................................6
6 Message Examples.................................................6
7 References.......................................................6
8 Authors' Addresses...............................................7
9 Acknowledgements.................................................7
10 IPR Statement...................................................7
11 Full Copyright Statement........................................7
1 Introduction
This document defines ALLOCATE, a new method extending the SIP [2]
protocol. ALLOCATE is a request to a SIP/PSTN gateway or Media
Gateway Controller (MGC) [3] to create a dynamic and short-lived
binding between a PSTN telephone number and a set of SIP URIs. This
telephone number, which we call a Temporary SIP Gateway Number
(TSGN), is similar in purpose to a routing number in wireless
networks. Once the gateway is contacted through PSTN signaling (such
as an IAM ISUP message) with this TSGN number after the binding is
created, the gateway issues INVITE requests to the addresses
specified in the ALLOCATE request to complete the call.
Existing techniques for mapping a telephone number to a set of SIP
URLs, such as Enum [4] or a REGISTER request sent to a telephone
number, assume that the telephone number space is under the control
of the entity performing the assignments; TRIP [6] was mainly meant
for routing calls from SIP networks to PSTN. This model, however,
deals with the opposite direction: many ALLOCATE requestors may
obtain temporary gateway numbers from a single gateway, dynamically
on a per user/call basis. The pool of temporary numbers must
therefore be under the control of the gateway, not the requestor, so
a new technique is needed.
IETF protocols for temporary leases of resources out of a pool, such
as DHCP [5] or MADCAP [7], do currently exist. However, these
protocols are primarily designed for very specific problem domains,
such as use on a local-area network or for allocating multicast
addresses with only loose coupling, and none of them are terribly
well suited for the wide-area use that this usage scenario requires.
No existing protocols are directly suitable to exactly this purpose.
As the scenario simply has request and response semantics, any of
the multitudinous existing Internet request/response protocols could
potentially provide the transport for this scenario; there is not an
extremely strong argument for any of them. However, since the
devices to be used must already speak SIP, and since SIP's syntax
and semantics are designed to represent telephony-style resources,
SIP seems the most appropriate protocol for this purpose.
2 Example Use
The ALLOCATE method, combined with cellular network technologies,
allows the selection of a media gateway dynamically upon delivering
a call from a circuit switched network to a SIP terminal. This
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 2
<draft-alexiou-sipping-allocate-00.txt> February 2002
contrasts with the current prevailing approach of statically
determining a media gateway by the directory number, regardless of
the location of the end terminal.
In cellular networks, a dynamically assigned routing number is
employed to deliver a call to the roaming subscriber via circuit-
switched networks. ALLOCATE makes it possible to obtain such routing
number from any desirable SIP gateway. With this routing number, a
call can be relayed through the PSTN networks to the gateway, which
then attempts to deliver the call to the provided contact addresses.
A specific example of this is shown in Figure 1. The ISUP network
queries the mobility manager with a routing information request.
The mobility manager then asks a gateway to allocate a TSGN for a
particular user's contact addresses. The gateway returns the TSGN in
the 200 OK message, and the mobility manager sends the TSGN back to
the ISUP network. Then the ISUP network issues an IAM addressed with
the TSGN, which the PSTN routes to the gateway. When the gateway
receives the IAM, it initiates SIP INVITE requests to the addresses
which were specified in the ALLOCATE request.
The SIP request and response messages for this example's ALLOCATE
transaction are shown in Section 6.
|---------|
| ISUP | 5. IAM (TSGN)
| Network | --------------------------
|---------| |
^ | |
4. | | |
Rsp | | 1. Routing Info |
(TSGN)| | Request |
| | |
| | |
| \/ \/
|---------| 2. ALLOCATE 6. INVITE alice@office
| Mobility|---------------------->|------|------------------------>
| Manager |<--------------------- | GW |------------------------>
|---------| 3. 200 OK |------| 6'. INVITE alice@lab
Contact: <tel:TSGN>
Figure 1: Example Call Flow
3 ALLOCATE Method
The ALLOCATE method is structured much like the REGISTER method.
However the semantics of the Contact, To, and From headers are
different as described in the following section. There is also one
additional header, Allocate-For. There are no new response codes,
bodies, or special processing requirements for proxies.
3.1 Constructing the Request
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 3
<draft-alexiou-sipping-allocate-00.txt> February 2002
A client issuing an ALLOCATE constructs its headers as detailed
below:
To: The To header field contains a SIP URL representing the initial
gateway to which the request was sent. As with REGISTER, this
will generally have only a 'host' component and no 'user'
component.
From: The From header field contains a SIP URL representing the
requestor. If the destination gateway is using SIP-layer
authentication to authenticate the requestor, this field is
used as the key to determine the authentication credentials to
be used (as with REGISTER).
Contact: At least one Contact address, to be bound to a TSGN by the
server, must be present. The client can use the "expires"
header field parameter (or an Expires header) to indicate how
long it wishes the binding to be valid. (An expiration value
of three minutes is RECOMMENDED.)
Note: three minutes is an initial estimate of an
appropriate expiration timer; the optimal value for
this timer is for further study.
The addresses specified in the Contact header field SHOULD be
SIP or SIPS URIs, unless the requestor has out-of-band
knowledge that the gateway supports routing calls to other URI
schemes.
Allocate-For: This optional header indicates an E.164 address of the
entity on whose behalf the allocation is being performed,
through which the PSTN call will be routed. The syntax of this
header is the same as that of Contact. Gateways, or gateway
location servers, MAY use this information to choose an
appropriate gateway, in order to minimize, e.g. the length of
the PSTN call leg. Allocate requestors SHOULD include this
information if it is available.
Other SIP header fields and the SIP Request-URI are constructed in
the standard manner specified by the SIP specification. ALLOCATE
requests contain no content bodies.
3.2 Processing the Request
If the received request contains multiple Contact addresses, the
server MUST be able to fork or sequentially search for the user
based on the q preference value; otherwise it MUST reject the
request with a 488 Not Acceptable Here response code.
If the server decides to accept the request, it sends the client a
200 OK response. The response MUST include one Contact header with
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 4
<draft-alexiou-sipping-allocate-00.txt> February 2002
exactly one Contact header field containing the TSGN, expressed as a
"tel" URI [8]. The TSGN SHOULD be in global (E.164) format, and
SHOULD NOT contain an isdn-subaddress or other components which
would prevent it from being globally reachable.
The server MUST indicate how long the binding is valid with an
"expires" Contact header field parameter. The server MAY lower the
expiration time from the value specified in the request, but MUST
NOT increase it.
If the expiration period in the request is shorter than is supported
by the server, the server rejects the request with the status 423
Interval Too Brief, and includes a Min-Expires header in the
response indicating the shortest expiration period supported.
If subsequent ALLOCATE requests (in new transactions) arrive for the
same set of Contact addresses, they are processed independently, and
should obtain different TSGNs.
3.3 Call setup
When a PSTN call placed to the TSGN arrives at the gateway, the
gateway initiates SIP INVITE requests to the SIP addresses specified
in the ALLOCATE message's Contact header field. Once the INVITE
transactions have been initiated, the binding between the TSGN and
the set of SIP addresses is removed.
The binding is alternatively removed when the "expires" timer
specified by the server has elapsed. Gateways SHOULD avoid re-using
TSGNs for some period of time after a binding has expired, to avoid
accidental collision between old and new bindings.
4 Security Considerations
The security requirements and considerations in the SIP
specification apply to the ALLOCATE method. Trust models or security
associations between clients and servers are beyond the scope of
this document. The authors wish that the definition of this
extension be orthogonal to the current or future security models for
SIP.
For example, Denial of Service attack against the server by
unauthenticated users, to exhaust the available TSGNs, is among the
obvious attacks. Minimally, the digest authentication mechanism used
for SIP registrations can apply to the ALLOCATE method for
authentication between domains.
Gateways SHOULD avoid exposing the TSGN in the INVITE methods they
generate after receiving the PSTN call setup. This will help
somewhat to avoid session hijacking by callers calling TSGN numbers
for sessions they have not been assigned. In the absence of
authentication in the PSTN, however, this problem will still remain;
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 5
<draft-alexiou-sipping-allocate-00.txt> February 2002
gateways which have administrative relationships with all PSTN
entities authorized to transit through them SHOULD verify at least
the PSTN source of the call.
5 IANA Considerations
This document defines a new SIP method name (ALLOCATE), and a new
header field (Allocate-For).
6 Message Examples
In the following example, the gateway gw58.ca.pstn-gws.example
binds, for 180 seconds, the TSGN +13235554258 to the Contact
addresses in the request.
ALLOCATE sip:gw58.ca.pstn-gws.example SIP/2.0
Via: SIP/2.0/UDP nj.mobility-manager.example:5060
From: <sip:nwelem47.nj.mobility-manager.example>
To: <sip:gw58.ca.pstn-gws.example>
Call-ID: 1234567890@nwelem47.nj.mobility-manager.example
CSeq: 1 ALLOCATE
Max-Forwards: 70
Contact: "Alice at work" <sip:alice@office.work.com>; expires=180
Contact: "Alice in the lab" <sip:alice@lab.work.com>; expires=180
Allocate-For: <tel:+18475550000>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP nj.mobility-manager.example:5060
From: <sip:nwelem47.nj.mobility-manager.example>
To: <sip:gw58.ca.pstn-gws.example>
Call-ID: 1234567890@nwelem47.nj.mobility-manager.example
CSeq: 1 ALLOCATE
Contact: <tel:+13235554258>; expires=180
Content-Length: 0
7 References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1999.
[2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session Initiation
Protocol", draft-ietf-sip-rfc2543-bis-08, February 2002. Work in
progress.
[3] F. Cuervo et al, "Megaco Protocol Version 1.0", RFC 3015,
November 2000.
[4] P. Falstrom, "E.164 number and DNS", RFC 2916, September 2000.
[5] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[6] J. Rosenberg, H. Salama, M. Squire, "Telephony Routing over IP
(TRIP)", RFC 3219, January 2002.
[7] S. Hanna, B. Patel, and M. Shah, "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 6
<draft-alexiou-sipping-allocate-00.txt> February 2002
[8] H. Schulzrinne and A. Vaha-Sipila, "URIs for Telephone Calls",
draft-antti-rfc2806bis-02.txt, February 2002. Work in progress.
8 Authors' Addresses
Triantafyllos Alexiou
101 Crawfords Corner Rd
Room: 4J-513A
Holmdel, NJ 07733
Tel: +1 732 332-5559
Email: akis@lucent.com
Jonathan Lennox
101 Crawfords Corner Rd
Room: 4F-516
Holmdel, NJ 07733
Tel: +1 732 332-6063
Email: lennox@lucent.com
Kazutaka Murakami
101 Crawfords Corner Rd
Room: 4G-512
Holmdel, NJ 07733
Tel: +1 732 949-6028
Email: kmurakami@lucent.com
9 Acknowledgements
We thank Henning Schulzrinne, Tom La Porta, and Oliver Haase for
their comments on this proposal.
10 IPR Statement
Lucent Technologies may have intellectual property rights on the
example scenario described in section 2. The ALLOCATE method itself
is unencumbered to the best of our knowledge.
11 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
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
defined in the Internet Standards process must be followed, or as
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 7
<draft-alexiou-sipping-allocate-00.txt> February 2002
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.
T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 8
