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

Reply via email to