Hi, Algorithm that is defined in the bis-09 draft for handling out of sequence REGISTER requests states different handling for de-Registration and Updation requests. This is what is suggested for de-Registration "the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise the registrar MUST leave the binding as is. It then skips to the last step." The follwoing is suggested for updation of registrations "If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails." My point here is why should the request fail in case of updation. In case of de-Registration that particular binding is not removed but the request succeeds. The same should apply for updation also. We should not update the binding if the request is out of sequence but still honour the request for other bindings. Regards - 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
