Subject: Questions regarding REGISTER

From: Jon Schlegel <[email-masked]>
Date: Thu, 11 Nov 1999 18:49:26 -0500

In the interests of robustness, we have been reexamining our
implementation of the SIP Registrar and we have a few questions regarding
how REGISTER requests should be handled.  While we agree that the CSeq
value cannot be used to enforce global ordering on register requests, since
the requests may come from different Call-IDs, it seems that the CSeq value
could be used to enforce ordering on requests with the same Call-ID.
Further, the SIP specification indicates that Clients SHOULD enforce
ordering on their own by avoiding sending a new registration until a
response has been received for their previous register request, however it
does not say that clients MUST enforce ordering, so it is possible for a
request with a lower CSeq and a given Call-ID to arrive after a request
with a higher CSeq and the same Call-ID.  This might cause problems if the
request with the lower CSeq cancelled all registrations.  In order to get
around these problems, we have devised the following scheme for processing
REGISTER requests:

	-An incoming register for a given To which has a different Call-ID than
any other 
 	register currently in the database for that To is added to the database.
No previous
	registrations are modified or replaced.

	-An incoming register with the same To and Call-ID as other registrations
in the 	database, but with a different Contact field is added to the
database.  No previous 	registrations are modified or replaced.

	-An incoming register with the same To, Call-ID, and Contact as a
registration currently
	existing in the database, but with a lower CSeq value is discarded.
	
	-An incoming register with the same To, Call-ID, and Contact as a
registration 	currently existing in the database, but with a CSeq value >=
than the CSeq value 
	for the registration currently in the database is processed according to
the following 
	rules:
		-Compare the q values for the registrations, if the q value for the
incoming 		registration is greater than the q value for the registration
currently in the database,
		replace.  If the q value for the incoming registration is less than the q
value for the 
		registration currently in the database discard the incoming registration.
		-If the q values of the two registrations are equal, compare the TTLs for
the two 
		registrations.  If the TTL for the incoming registration is greater,
replace the entry
		currently in the database with the new registration, otherwise discard
the new 
		registration.  

	-An incoming register with the same To as a registration or set of
registrations 	currently in the database, but with Expires: 0 and Contact:
* deletes all registrations 	from the databaes with the same To, except for
those with the same Call-ID and a 
	higher CSeq value than the incoming registration.
	
	-An incoming register with the same To as a registration or set of
registrations 	currently in the database, but with Expires: 0 and a
specified contact field deletes
	the registration with the given To and Contact, unless the registration
with the given
	To and Contact has the same Call-ID and a greater CSeq value.  

Are there any problems that might be caused by handling REGISTER requests
in this manner?  The only problem that we can think of is that if someone
happens to crash their client and then it comes back up with the same
Call-ID, it will then try to renew its registrations with a lower CSeq than
the registrations which are already in the database, and the new
registrations will get discarded.  However, if the Call-ID is chosen using
cryptographically random identifiers, as the RFC indicates it should be,
this scenario is highly unlikely.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Nov 1999 19:33:06 -0500

I'm not sure complicated rules are necessary. Clients should generally
not send a registration for '*' (to cancel all) unless they know they
want to start with a clean slate. The typical distributed update would
simply leave the default registration ("home") alone and just change the
temporary address, with a higher q value. Removing registrations should
almost never be necessary, since they time out and having one hang
around a few minutes longer than needed does no harm.

Since a client generally does not know why some other client has
registered, about the only thing that is robust is manual removal, from
a list of current registrations.

Thus, I'm not sure when the order of arrival would matter. What problem,
exactly, are you trying to solve?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Nov 1999 11:09:19 -0500

I think the "problem" is solved by chaning the SHOULD to a MUST; clients
MUST not send registrations before receiving responses to the previous.
Once we do that, if you break the rule, you should anticipate that the
behavior is not what you think it might be.

I don't want to overcomplicate things if its not needed. Looking at the

>         registrations are modified or replaced.

If the Contact is a new one, this is what happens now. The difference is
only if the Contact matches an existing registration. This means, for
example, I wouldn't be able to sit at one machine, go to another
machine, and from there, delete my previous registration. This disables
some useful mobility features.

> database.  No previous  registrations are modified or replaced.

This mirrors current behavior.

>         existing in the database, but with a lower CSeq value is discarded.

This differs, but is eliminated by a change in strength to MUST.

>                 registration currently in the database discard the incoming

Hmm; so I can't lower the q value without first deleting it, and then
adding a new one? Why is this needed?

>                 currently in the database with the new registration, otherwise

Same as above; why?

>         higher CSeq value than the incoming registration.

except for those with the same Call-ID? So I have to change Call-IDs to
delete?

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com