Subject: Re: [Sip] REGISTER Processing

From: [email-masked]
Date: Tue, 18 Jun 2002 23:59:59 +0530

Hi,

I have a few doubts regarding the way out of sequence REGISTER
requests are handled.

The Algorithm given in 10.3 seems to define different behaviours
in handling out sequence REGISTER requests while updation and
de-Registration.

Bullet 6 which defines de-Registration (Contact with *) specifies that if
CSeq doesn't
match the binding MUST be left as is. (The request succeeds)

Bullet 7 which defines updation specifies that if the CSeq doesn't match
the update MUST be
aborted and the "request fails".

Why is the behaviour different for de-Registration and updation.

What I feel is that even during updation the request shouldn't fail but the
binding that doesn't
agree with the CSeq should not be updated. But the updation of other
bindings should be allowed.
this way it is made sure that the Out of Sequence request received does not
change the binding registered
by the highet CSeq request.

Am I missing out something. Please correct me if my understanding is wrong.

Thanx & Regards,
- Vijay

Jonathan Rosenberg <[email-masked]> on 06/18/2002 11:51:05 PM

To:   Jiri Kuthan <[email-masked]>
cc:   [email-masked], Jan Janak <[email-masked]> (bcc: Vijay
      Ganapathy/HSSBLR)

Subject:  Re: [Sip] REGISTER Processing

sorry for the immensely late response... combing the list now for old
bis issues:

Jiri Kuthan wrote:
 > There seems to be insufficient guidance in bis-09 on usage of Call-ID
 >  in REGISTERs. The only thing which I found there is in 10.2.4:
 >
 > "A UA SHOULD use the same Call-ID for all registrations during a
 > single boot cycle. "
 >
 > I think that does NOT require Call-ID to change across reboots.

Correct.

 > UAs with no memory are not explicitely mandated to change Call-ID
 > (ignoring that bis asks to deny REGISTERs with Call-ID== and CSeq <=
 > values in registrar's bindings). If the UACs actually do not change
 > Call-ID, REGISTERs after reboots with low CSeq will be ignored.

Right, which is way the guidelines for CSeq say:

 > CSeq: The CSeq value guarantees proper ordering of REGISTER requests.
 > A UA MUST increment the CSeq value by one for each REGISTER
 > request with the same Call-ID.

This would seem to explicitly address the issue, no?

 >
 > Which actually happened during two tests in SIPIt.
 >
 > Also the SHOULD strengh seems to weak -- 'SHOULD' MUST be used if not
 > doing so does not break things, which is not the case here.

I think SHOULD is sufficient so long as you also properly follow the
MUST strength requirement on CSeq incremeting.

 >
 > --
 >
 > Other confusing thing is which SIP reply a request failure for
 > out-of-order REGISTERs in line 1740 implies. I could connect it to
 > the next paragraph "....if binding update fails...the request MUST
 > fail with 500..." but I am not sure that 500 is a good choice.

No, that status code is correct. Its the same error response used when
you receive a request on a dialog with a CSeq lower than the current
one. From line 2033 in bis09 PDF, a 500 is returned there too. You want
a 500, since the client can retry the request and it can work the second
time (since the CSeq will change as a natural consequence of retrying
the request).

Given that the error code is correct, do you still find it confusing to
have the two paragraphs connected?

 >
 > --
 >
 > Yet anothet thing, which Jan pointed out, is that handling of
 > out-or-order in lines 1738-40 also includes retransmissions (CSeq and
 > CallID in request and bindings equal).

Retransmissions would have already been handled in the transaction
layer. Thus, a totally new transaction with the same call-id/cseq is
indeed an error.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip