Hi ,
Let me try to be more clear on what I mean
Under section 10.3 point number 6 expalins steps to be followed while doing
de-registration and point 7 specifies the steps to be followed while
updating a binding. I felt that steps in de-registration seems to be
handling out of sequence registrations very well, whereas updation seems to
give incorrect results( I am just seeking a clarification on that).
Say I am registering a Contact. Contact1 with callid1 ans CSeq(5)
The registration table would have an entry
Contact1 callid1 CSeq(5)
Now I crash or reboot. I am de-registering my contacts with
Callid2 CSeq(1) Contact * expires=0
So the contact gets removed.
Now I am sending a new contact
Contact2 callid2 CSeq(2) -------> Result1
In the above case the de-registration and registration requests went in
order.
Now let us consider what happens when the two requests reaches out of
order.
Contact2 Callid2 CSeq(2) reaches first. So, that will get added to the
existing list
So the list would be
Contact1 callid1 CSeq(5)
Contact2 callid1 CSeq(2)
Then the lower CSeq arrives(de-registration request). So if we follow
section 10.3 point number 6 Contact1 will get removed due to callid
mismatch. But Contact2 will not be because of CSeq out of order.
So the registration table entry would like
Contact2 callid2 CSeq(2) ---------> Result2
Now let us compare Result1 and Result2. They are exactly the same. So we
have successfully handled the out of sequence request. Because the
algorithm gives the same result even if the requests come out of sequence.
When we find a mismatch in the CSeq we are not aborting the changes made to
Contact1. So the algorithm is fine. What if we abort the changes to
Contact1 on a CSeq mismatch. the registration table would have the
following entries
-----------> Result3
Contact1 callid1 CSeq(5)
Contact2 callid2 CSeq(2)
Now if we compare Result1 and Result3 we can find that they don't match.
The algorithm gives a wrong result.
That is what I have exactly meant in the first mail. The de-registration
section doesn't say that we should abort but section10.3 point number 7
which specifies how bindings must be updated says that the changes should
be aborted on finding a mismatch of CSeq. Now please go through the update
section of my previous mail.
So what I feel is that even while updating Contacts we shouldn't abort the
changes made to the earlier bindings. The request shouldn't fail rather
only the updation of that particular Contact should fail.
Again if I am wrong just correct me.
thanks and regards
- Vijay
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
