Subject: [Sip] Clarification on RFC 3261, section 10.3 §6

From: Thomas Froment <[email-masked]>
Date: Tue, 07 Mar 2006 16:13:01 +0100

RFC 3261 section 10.3 (Processing REGISTER Requests) states:
part 6:

The registrar checks whether the request contains the Contact
         header field.  If not, it skips to the last step.  If the
         Contact header field is present, the registrar checks if there
         is one Contact field value that contains the special value "*"
         and an Expires field.  If the request has additional Contact
         fields or an expiration time other than zero, the request is
         invalid, and the server MUST return a 400 (Invalid Request) and
         skip the remaining steps.  If not, 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 update
         MUST be aborted and the request fails.*

I am *exactly* in the last case where I MUST abort the update and "fail the request":
WHAT does exactly mean "FAIL the request":

option 1 -> should I answer error 4xx, or 5xx ? if yes, which one?
option 2-> should I just ignore the update and still answer 200 OK ?

This test case is performed in ETSI RFC 3261 test suite, and this test suite assume option 2 is correct, but it does not
seem so clear reading RFC...
Any help ?
Thanks,
Thomas

_______________________________________________
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: Pekka Pessi <[email-masked]>
Date: Tue, 07 Mar 2006 18:08:39 +0200

>option 2-> should I just ignore the update and still answer 200 OK ?

You get there when registrar has already seen a REGISTER request
with same Call-ID but higher CSeq, so I'd choose option 1 and
return 400 Reordered or something. 

>This test case is performed in ETSI RFC 3261 test suite, and this
>test suite assume option 2 is correct, but it does not seem so
>clear reading RFC...

--Pekka

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 07 Mar 2006 12:24:17 -0500

On Tue, 2006-03-07 at 16:13 +0100, Thomas Froment wrote:
>          Otherwise, the update
> This test case is performed in ETSI RFC 3261 test suite, and this test
> suite assume option 2 is correct, but it does not

It would be extremely odd to "fail the request" by sending "200 OK".

Generally, an out-of-order request is rejected with a 500 response (see
12.2.2), but I personally don't like that, as it is not a failure of the
server, but rather of the response.  We should define a particular 49x
code for that.

Dale

---

From: Thomas Froment <[email-masked]>
Date: Tue, 07 Mar 2006 18:35:14 +0100

>It would be extremely odd to "fail the request" by sending "200 OK".
I agree with you this is somewhat strange, but we can imagine a 
registrar just "ignore" an update
and should fail the "update request",but not the "SIP request" -> that 
means it will answer 200 OK with the same
number of bindings as previously, and this could be considered as a way 
to "fail the request".
At least, it seems to be the way the ETSI SIP compliance TTCN test is 
coded, and people having specified this test
have interpreted (or misinterpreted) things like this...
I would be happy, if one of them is in the list, could answer...

>server, but rather of the response.  We should define a particular 49x
Yes, but this is a more general question...

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 07 Mar 2006 12:56:05 -0500

> number of bindings as previously, and this could be considered as a way 

I would think that if the authors of 3261 wished to allow that, they
would have used the verb "ignore".

> have interpreted (or misinterpreted) things like this...

I wouldn't be surprised if ETSI has made a mistake in their test suite.

Dale