Subject: [Sip] I-D ACTION:draft-idnani-sip-contact-timestamp-00.txt

From: [email-masked]
Date: Thu, 03 Oct 2002 07:12:37 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: New Parameter for Contact Header
	Author(s)	: A. Idnani
	Filename	: draft-idnani-sip-contact-timestamp-00.txt
	Pages		: 7
	Date		: 2002-10-2
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-idnani-sip-contact-timestamp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-idnani-sip-contact-timestamp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-idnani-sip-contact-timestamp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Oct 2002 15:19:09 -0400

The general concept here seems interesting, but I have some issues with the details:

The idea seems to be to provide enough information so that different UAs representing the "same" device can cooperate to minimize multiple registrations of that device. But while the "created" timestamp is helpful for this purpose, it doesn't seem sufficient. For a UA to use the created timestamps for this purpose, it must assume that multiple contacts registered for the same Address of Record do in fact represent the "same" device. But this need not be the case. It could be that other things are also registered, as alternatives providing voicemail support, or to support other media, or whatever.

To achieve your purpose, I think you need something else, such as a deviceid parameter, that can be used by multiple UAs representing the same device to indicate the identity of that device. With that, a UA making a registration would want to check for the existence of another registration with a newer timestamp and the same deviceid before deciding to unregister itself. (Conceivably you could use the user part of the sip address for this purpose. But doing so presumes that all UAs representing the device agree on how to represent the name of the device as a user part in the url. This is probably not a good assumption.)

Another issue is that your technique for assigning timestamps assumes that the timestamp is assigned by the registrar only when a REGISTER with a new callid is received. That assumes that subsequent REGISTER messages under the same callid are only refreshes of the same contact address. This need not be the case. It is quite legal for subsequent REGISTERs to add new contact addresses. In this case, the newly added contact addresses should receive new timestamps. 

Finally, you haven't said what should happen if a Contact header in a REGISTER message happens to contain a "created=" parameter. This is currently legal, as an extension parameter. Should this be an error, should the registrar accept the parameter and avoid assigning its own, or should it replace the value with the timestamp it assigns? 

	Paul
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Oct 2002 02:04:55 -0400

Paul Kyzivat wrote:
 > To achieve your purpose, I think you need something else, such as a
 > deviceid parameter, that can be used by multiple UAs representing the
 > same device to indicate the identity of that device. With that, a UA
 > making a registration would want to check for the existence of
 > another registration with a newer timestamp and the same deviceid
 > before deciding to unregister itself. (Conceivably you could use the
 > user part of the sip address for this purpose. But doing so presumes
 > that all UAs representing the device agree on how to represent the
 > name of the device as a user part in the url. This is probably not a
 > good assumption.)

Actually, I think its the right assumption.

If you eliminate the gateways which are assumed in the draft, and the 
UA's were pure SIP UA, how would this work? When the UA roams, it 
acquires a new IP address. So, it needs to unregister the old one. It 
can do that directly because it still remembers the URI with which it 
registered previsously, and so can unregister it.

I would argue that, in the case of a gatewayed system, it should work 
identically. It would be the responsibility of the gateways to extract a 
  consistent identity from the devices in order to properly identify the 
old registration in order to remove it. Using some kind of identifier in 
the user part of the URI is the right way to do it.

This would probably be one of several mapping functions that would be 
needed to properly build this gateway function. It seems better to push 
all these things into a gateway specification rather than burden SIP 
with them. We already have a way to identify a device - using the URI.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Oct 2002 08:59:41 -0400

> with them. We already have a way to identify a device - using the URI.

I don't have any particular vested interest in this, so I am satisfied to defer to those that do, if this makes sense to them. 

Perhaps I misunderstand the use case. In the draft the issue was managing the transition between 

	Contact: sip:[email-masked]
and	Contact: sip:[email-masked]

where both are registered to:

	sip:[email-masked]

Presumably this should also apply if the transition was between 

	Contact: sip:[email-masked]
and	Contact: sip:[email-masked]

The trouble with using the user part is that the user part is supposed to be uninterpretted by all except those within the domain part. So proxyUA1.cellprovider1.com has no business ascribing any particular meaning to the user part of sip:[email-masked].

It *may* be acceptable for proxyUA1.visited.com to presume to know something about the user part of sip:[email-masked]. 

I suppose it may be ok in the cellprovider1/cellprovider2 case if they have some specific business agreement. But I doubt one could reasonably expect to expect IETF to standardize this kind of assumption.

In any case, it seems that minimally the spec should say what kind of matching of contacts is required before deciding that one should defer to another.

	Paul