Subject: Re: [Sip] REGISTER Processing

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jun 2002 14:21:05 -0400

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

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 18 Jun 2002 21:59:14 +0200

inline

>This would seem to explicitly address the issue, no?

Agreed -- I missed that. 

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

Yes.

>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).

I'm not particularly happy about 5xx in neither context. 5xx stands for server error
("the server failed to fulfill an apparently valid request"), whereas this sounds to
me much more like "4xx - client error -- the request contains bad syntax or cannot
be fulfilled at server". I don't think there is a big interop issue for UACs, it is
primarily of diagnostic value. I'm a fan of rich and correct diagnostic info, which
makes bug location easier. 5xx makes me hunt a bug mistakenly in a UAS. My preference 
is "4xx out-of-order". 

>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.

UAs, including registrars, may be stateless. Such registrars would be then
forced by spec to send an error on retransmission, resulting in a UAC 
believing it is not registered. As long as contacts are unchanged, I'm
willing to send 200 to request with current CSeq.

-Jiri

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Jun 2002 00:45:20 -0400

inline.

Nirmalya Ghosh wrote:
> Hi Jonathan,
> I have a question regarding what happens when a user wants to fetch its
> current bindings (maybe after rebooting his/her PC). I understand that
> the Call-ID need not be the same across reboots, but what I am not sure
> of is whether for a dummy REGISTER request (containing no Contact or
> Expires) sent to fetch its bindings after rebooting, would/should get a
> 500 response from the registrar just because its CSeq does not match
> that of existing bindings.

No. Follow the processing steps in section 10.3. The registrar would 
come to step 6, at which point it has authenticated the request and 
verified that the AOR in the To is valid for the domain. If there is no 
contact in the REGISTER (in the case of fetch), step 6 instructs the 
registrar to go to the last step. The last step, 8, has the registrar 
returning the current bindings in the 200 OK.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Jun 2002 01:41:46 -0400

inline.

> makes bug location easier. 5xx makes me hunt a bug mistakenly in a UAS.

Its not about finger-pointing, its about taking the proper actions upon 
getting the error. Generally, 5xx is supposed to mean, "you can retry 
this request later on without change, and it might succeed". The 4xx 
responses indicated that the client needs to change the request in some 
way, and if it can't, there is no point in trying again. In this case 
here, the client CAN indeed simply retry the request again later on, 
without change (of course, things like the cseq, call-id, via do change 
as per normal operation), and it can work. Thats why we used 500.

> UAs, including registrars, may be stateless.

The notion of stateless UAS is really for unauthenticated requests. Its 
not a general thing. Indeed, in the case of REGISTER, there are other 
problems. Each retransmission would effectively update the expiration 
time of the contact. Eaech response would therefore have a different 
expiration time in the contact. As a result, the "retransmits" of each 
response are different, and the UAC would need to use the last one in 
order to obtain the proper expiration time. Not a big issue, but its not 
supposed to work that way.

I would argue that this points to a need for clarification in 8.2.7 of 
additional requirements on stateless UAS; namely, a UAS cannot be 
stateless unless the request processing for that method would always 
result in the same response if the requests are identical.

-Jonathan R.

---

From: "Nirmalya Ghosh" <[email-masked]>
Date: Wed, 19 Jun 2002 12:20:48 +0800

Hi Jonathan,
that of existing bindings. Or am I misinterpreting things here? 

Thanks & Regards,
Nirmalya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Wednesday, June 19, 2002 2:21 AM
To: Jiri Kuthan
Cc: [email-masked]; Jan Janak
Subject: Re: [Sip] REGISTER Processing

Jiri Kuthan wrote:
>  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:

> A UA MUST increment the CSeq value by one for each REGISTER  > request
with the same Call-ID.

 >
 > --
 >
 > 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.

 >
 > --
 >
 > 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).

-Jonathan R.

_______________________________________________
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

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 19 Jun 2002 11:17:32 +0200

At 07:41 AM 6/19/2002, Jonathan Rosenberg wrote:
>>makes bug location easier. 5xx makes me hunt a bug mistakenly in a UAS.
>>My preference is "4xx out-of-order". 
>
>Its not about finger-pointing, 

That is my concern -- lack of finger pointing makes life difficult. (Do you
remember those ancient compilers whose only error message was "syntax
error"?) The spec tells 4xx is a request failure, 5xx is a server failure. 
Out-of-order requests are not a server failure -- these are messages
invalid  within a call-id space context.

Ignoring whether 4xx or 5xx makes a better interop job, having a special 
o-o-o response code seems very helpful to me -- it would encourage server 
implementors to be more specific than {4|5}00 "some error".

>its about taking the proper actions upon getting the error. Generally, 5xx is supposed to mean, "you can retry this request later on without change, and it might succeed". The 4xx responses indicated that the client needs to change the request in some way, and if it can't, there is no point in trying again. 
>In this case here, the client CAN indeed simply retry the request again later on, without change (of course, things like the cseq, call-id, via do change as per normal operation), and it can work. Thats why we used 500.

I see now -- a noble lie. UAS tells the buggy UAC "5xx I'm guilty
please retry, as soon as my current bindings expire or you reach
my Cseq you'll be ok" (as opposed to honest "4xx don't resubmit until 
you fix your buggy CSeq").

It is ugly, though I admit 5xx is doing little a bit better in 
this case -- we trade better interoperability with buggy UACs 
for diagnostic value of status code (is it worth it?). Again, 
compensating that by a specific status code seems very helpful to me.

>The notion of stateless UAS is really for unauthenticated requests. Its not a general thing. 

Please no -- forbidding undocumented uses of an entity is too limiting.
There are for sure other valid uses of stateless UASs. For example, 
a stateless redirect server copes better with heavy load than
a stateful one.

>Indeed, in the case of REGISTER, there are other problems. Each retransmission would effectively update the expiration time of the contact. 

It may or may not, subject to how the transactionally-stateless registrar
is implemented.

>Eaech response would therefore have a different expiration time in the contact. As a result, the "retransmits" of each response are different, and the UAC would need to use the last one in order to obtain the proper expiration time. Not a big issue, but its not supposed to work that way.

That is fixeable with a stateless registrar. I am only opposed to forcing
a stateless registrar to send a negative reply on REGISTER retransmisssion.

-Jiri

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Jun 2002 16:25:57 -0400

> that of existing bindings. Or am I misinterpreting things here? 

Things work fine. Please read the rules in 10.3 and follow them through 
for this case. You will arrive at step 6, which says:

The registrar checks whether the request contains the Contact header 
field. If not, it skips to the last step. 1710

The last step involves sending a 200 OK with the list of registered 
contacts. The intermediate steps which are skipped are the ones that 
check the CSeq and Call-ID.

-Jonathan R.