When the text in bis-09 says "the update must be aborted and the request fails", its actually referring to both extending registration and deregistering. The behaviour for both cases is exactly the same. Expires: 0 is just another update, it just happens that time is 0 seconds.
Regards, Hisham > -----Original Message----- > From: ext [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 10, 2002 3:49 PM > To: [EMAIL PROTECTED] > Subject: [Sip-implementors] Handling out of order REGISTER requests > > > > > Hi, > > It has been specified that Callid and Cseq should be recorded for each > binding. > > I have a doubt in the algorithm, for handling out of sequence REGISTER > requests, given in rfc2543bis-09 > (Please spare some time in going through the scenario) > > De-Registration of Contacts: > > 1) If the Callids doesn't match - go ahead and remove the binding. > > 2) If the Callids match - remove the binding only if the Cseq of the > de-registration request is greater than the one using which > the binding was > last modified. And leave the binding as is if the CSeq is smaller. > > Updating Contacts: > > 1) If the Contact doesn't exist add one to the already existing list. > > 2) If the Conatct already exists and Callids doesn't match - > update the > Contact > > 3) If the Contact already exists and Callids match - update > only if CSeq of > the current request is greater and abort the updations > (request fails) if > the CSeq is smaller. > > Let us consider an example, > > There are two contacts > > Contact1 Callid1 5 (Cseq) > Contact2 Callid2 2 (Cseq) - (Lets consider this contact was > registered > after a crash, > different boot cycle) > > Now Registrar receives a REGSITER request. > Callid - Callid2 > CSeq - 1 > Conatact - *;expires=0 > > My understanding is > > The Registrar would remove the Contact1 - mismatch in Callid > then would > look into Contact2 will not be removed becuase of out of > order request.So > this behaviour is fine. > > The final list of Contacts after the request processing will be > > Conact2 Callid2 2 (CSeq) > > Had the request come in order the final list will be the same. Ao the > algorithm works fine. > > > Now let us consider updation. > > Callid - Callid2 > CSeq - 1 > Contact - Contact1 (with some changes) > Contact - Contact2 (with some changes) > > My understanding is > > The Registrar would update Contact1.Incase of Contact2 there > will be a CSeq > mismatch.So the entire transaction would be aborted (rfc says > that "updates > aborted and request fails") i.e changes made to Contact1 > will also be > rolled back. > > Is my understanding of the entire scenario correct. If so,Why is the > behaviour during updation and de-registration > different.During updation why > should we rollback the changes made to Contact1.Had the > requests come in > order final contact list would look like > > Conatct1 Callid2 1 (CSeq) > Conatct2 Callid2 2 (CSeq) > > As the requests came out of sequence the final contact list looks like > > Contact1 Callid1 5 (CSeq) > Conatct2 Callid2 2 (CSeq) (which was not the one the end > point had desired > for) > > Could you please clarify and correct if I am wrong. > > Thanks in advance, > Vijay > > > > > > > This message is proprietary to Hughes Software Systems > Limited (HSS) and is > intended solely for the use of the individual to whom it is > addressed. It > may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is > intended. If > you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are > notified that > you are strictly prohibited from using, copying, altering, or > disclosing > the contents of this message. HSS accepts no responsibility > for loss or > damage arising from the use of the information transmitted by > this email > including damage from virus. > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
