Internet Engineering Task Force
Internet Draft A. Idnani
Document: draft-idnani-sip-contact-timestamp-00.txt Motorola
Expires: March 2003 October 2002
New Parameter for Contact Header
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.
Abstract
This memo proposes a new parameter for the SIP Contact header This
memo identifies the need for the new parameter, and then goes ahead
and defines the new parameter, and the algorithm for using the new
parameter. It also presents an example flow demonstrating the use of
the new parameter. The new parameter being defined is an optional
parameter, and is not required to be supported by the SIP servers and
UAs to be interoperational.
Conventions used in this document
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].
Idnani Expires - March 2003 [Page 1]
Internet Draft New parameter for contact Header October 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. SIP Registrar . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proxy UA . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4
5. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This draft tries to solve a problem that occurs in any situation in
which a SIP User Agent acts as a gateway to a Non-SIP device. In
particular, architectures in which SIP is used as the signaling
protocol within the core network of a system but the wireless mobile
devices that roam within the system are not SIP user agents
themselves.
This draft introduces the concept of a "Proxy UA" which acts as a
gateway between the SIP core network and the SIP-unaware mobile. The
Proxy UA is responsible for running the UA call engine for all the
mobiles that it is serving, besides converting the call control
messages from SIP to legacy protocols and vice-versa.
SIP uses contact addresses to tie a user?s address-of-record to
his/her location [1]. The contact addresses are centrally registered
with a SIP Registrar using a SIP REGISTER message. The 200 OK
response back from the SIP Registrar contains the list of all the
current Contact addresses for the user.
Many a times when a mobile user moves from one service area to
another, his registration at the old service area is kept active by a
proxy UA in that area. This is because the old proxy UA has no way of
knowing (or atleast not fast enough way of knowing) that the user has
moved, and that there is now a new proxy UA for the user, which is
the correct proxy UA.
This draft addresses the problem of stale registrations at the SIP
Proxy UA. It does not change the behavior of a SIP UA in any way. The
draft introduces a new parameter called "created", for the Contact
header. The parameter "created" will be maintained by the SIP
Registrar, and will contain a time stamp of when the Contact address
was first created, i.e. when the SIP REGISTER message containing a
Contact address and a new Call-ID was received. This parameter along
Idnani Expires - March 2003 [Page 2]
Internet Draft New parameter for contact Header October 2002
with the timestamp value will be passed back to the user / proxy UA
in a SIP 200 OK message.
2. SIP Registrar
SIP Registrar is required to maintain a list of contact addresses.
When a SIP Registrar receives a SIP REGISTER message, it MUST get the
contact address from the message, and add it to the list of contact
addresses for the user if it?s a new contact address.
This extension requires the SIP Registrar to also maintain a
timestamp when the contact address is a new contact address. If the
Call-ID of a SIP REGISTER is a new Call-ID, then the Contact address
in the SIP REGISTER message MUST be considered a new contact address,
and hence a new timestamp SHOULD be recorded for this contact
address. To keep things simple a SIP Registrar SHOULD get a new
timestamp when the CSeq of the SIP REGISTER message is "1 REGISTER".
This would signify a new Registration and hence new contact address,
and therefore a new timestamp.
The SIP Registrar should return all the contact addresses in SIP 200
OK response for a SIP REGISTER request. The contact addresses SHOULD
carry a parameter called "created". The value of the parameter SHOULD
be set to the timestamp as stored at the SIP Registrar.
e.g.
Contact: userA@proxyUA1.visited.com;created=2002-03-18:12:24:31
3. Proxy UA
The proxy UA sends SIP REGISTER messages on behalf of a UA to the SIP
Registrar. When the proxy UA receives the SIP 200 OK response back
from the SIP Registrar,
- It SHOULD check the contact addresses, and see if there are any
more contact addresses than it had sent in the SIP REGISTER
message.
- If there are, it SHOULD check the timestamp on all the contact
addresses to see if there are any newer contact addresses as
compared to the ones that it had sent.
- If there are, and the proxy UA wants to remove itself as the
contact for the UA, then the proxy UA SHOULD send another SIP
REGISTER message to the SIP Registrar, with the Expires header
set to 0.
Removing a contact address may be relevant where performance of
the system is critical. In such cases one might want to maintain
Idnani Expires - March 2003 [Page 3]
Internet Draft New parameter for contact Header October 2002
very few contact address (one in many cases), so that the UAC or
a SIP server does not have to fork a SIP INVITE to too many
contact addresses. This reduces the network traffic, and helps in
trying only those contact addresses, where probability of finding
the user is higher.
- The remaining steps are same as for any other SIP Registration
refer [1]
4. Backward Compatibility
The "created" parameter is an optional parameter. Any UA that does
not support the parameter can safely ignore the parameter. The
parameter does not change the current functionality of the SIP
Registrar and the UA, it only adds a new timestamping function on the
SIP Registrar. A proxy UA / UA that does not want to remove its
contact address from the Registrar, does not need to do so.
The "created" parameter can be used in conjunction with other Contact
header parameters, without affecting their semantics.
5. Call Flows
The following diagram illustrates a typical use of this extension. In
the following diagram Proxy UA 1 is the old proxy UA, and Proxy UA 2
is the new proxy UA.
+-----------+ +-----------+ +---------------+
| Proxy UA1 | | Proxy UA1 | | SIP Registrar |
+-----------+ +-----------+ +---------------+
| | |
| | F1 SIP REGISTER |
| |----------------------->|
| | |
| | F2 200 OK |
| |<-----------------------|
| | |
| F3 SIP REGISTER | |
|----------------------|----------------------->|
| | |
| F4 200 OK | |
|<---------------------|------------------------|
| | |
| F5 SIP REGISTER | |
|----------------------|----------------------->|
| | |
| F4 200 OK | |
|<---------------------|------------------------|
| | |
Idnani Expires - March 2003 [Page 4]
Internet Draft New parameter for contact Header October 2002
In the above call flow, when the user moves to a new service area,
the proxy UA (Proxy UA 2) in that area registers the contact address
with the SIP Registrar. After some time when the old proxy UA (Proxy
UA 1) sends a SIP REGISTER to renew the registration, it gets a 200
OK response back from the SIP Registrar containing both the old and
the new contact addresses. Proxy UA 1, looks at the contact
addresses, and realizes by looking at the timestamps on the contact
addresses that there is a new proxy UA for the user, so it
deregisters its contact address, by sending a SIP REGISTER message,
with the Expires value set to 0.
Message Details
F1 SIP REGISTER
REGISTER sip:registrar.home.com
Via: SIP/2.0/UDP proxyUA2.visited.com:5060
From:UserA <userA@home.com>
To: UserA <userA@home.com>
Call-ID: 123456@proxyUA2.visited.com
Cseq: 1 REGISTER
Contact: userA@proxyUA2.visited.com
Expires: 7200
Content-Length: 0
F2 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP registrar.home.com:5060
From:UserA <userA@home.com>
To: UserA <userA@home.com>
Call-ID: 123456@proxyUA2.visited.com
Cseq: 1 REGISTER
Contact: userA@proxyUA1.visited.com;created=2002-03-18:12:24:31
Contact: userA@proxyUA2.visited.com;created=2002-03-18:18:19:35
Content-Length:0
F3 SIP REGISTER
REGISTER sip:registrar.home.com
Via: SIP/2.0/UDP proxyUA1.visited.com:5060
From:UserA <userA@home.com>
To: UserA <userA@home.com>
Call-ID: 63158@proxyUA1.visited.com
Cseq: 16 REGISTER
Contact: userA@proxyUA1.visited.com
Expires: 7200
Content-Length: 0
Idnani Expires - March 2003 [Page 5]
Internet Draft New parameter for contact Header October 2002
F4 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP registrar.home.com:5060
From:UserA <userA@home.com>
To: UserA <userA@home.com>
Call-ID: 63158@proxyUA1.visited.com
Cseq: 16 REGISTER
Contact: userA@proxyUA1.visited.com;created=2002-03-18:12:24:31
Contact: userA@proxyUA2.visited.com;created=2002-03-18:18:19:35
Content-Length:0
F5 SIP REGISTER
REGISTER sip:registrar.home.com
Via: SIP/2.0/UDP proxyUA1.visited.com:5060
From:UserA <userA@home.com>
To: UserA <userA@home.com>
Call-ID: 63158@proxyUA1.visited.com
Cseq: 17 REGISTER
Contact: userA@proxyUA1.visited.com
Expires: 0
Content-Length: 0
F6 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP registrar.home.com:5060
From:UserA <userA@home.com>
To: UserA <userA@home.com>
Call-ID: 63158@proxyUA1.visited.com
Cseq: 17 REGISTER
Contact: userA@proxyUA2.visited.com;created=2002-03-18:18:19:35
Content-Length:0
6. Security Considerations
This draft does not introduce any new security threats.
7. References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work in
progress),February 2002
[2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
Idnani Expires - March 2003 [Page 6]
Internet Draft New parameter for contact Header October 2002
Author's Addresses
Ajaykumar Idnani
Motorola
1301 E Algonquin Road
Schaumburg, IL 60196
Email: Ajaykumar.idnani@motorola.com
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.
Notice Regarding Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights
Idnani Expires - March 2003 [Page 7]