Subject: [Simple] Errors on older notifications

From: Avshalom Houri <[email-masked]>
Date: Wed, 10 Jan 2007 13:16:14 +0200

When a subscriber gets a NOTIFY with a lower CSEQ, can it return an error
and still keep the subscription?

Should it return 200 OK?

Could not find the answer in 3265 or 3856.

Thanks
--Avshalom
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Wed, 10 Jan 2007 14:33:34 +0100

Surely RFC 3261 applies (12.2.2):

   If the remote sequence number was not empty, but the sequence number
   of the request is lower than the remote sequence number, the request
   is out of order and MUST be rejected with a 500 (Server Internal
   Error) response.

RFC 3265 does not appear to change this behaviour.

500 (Server Internal Error) responses do not kill the dialog, only the
transaction - see
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.tx
t.

Regards

Keith

________________________________

	From: Avshalom Houri [mailto:[email-masked]] 
	Sent: 10 January 2007 11:16
	To: [email-masked]
	Subject: [Simple] Errors on older notifications

	When a subscriber gets a NOTIFY with a lower CSEQ, can it return
an error 
	and still keep the subscription? 
	
	Should it return 200 OK? 

	Thanks 
	--Avshalom

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 10 Jan 2007 15:44:20 +0200

On the other hand the following text from RFC 3265 may say the opposite
(found it after I have sent the email):

RFC 3265 Section 3.2.2:
 If the NOTIFY request fails (as defined above) due to an error
   response, and the subscription was installed using a soft-state
   mechanism, the notifier MUST remove the corresponding subscription.

This seems to contradict RFC 3261 and the dialousage draft.

Regards
--Avshalom

"Drage, Keith \(Keith\)" <[email-masked]> 
10/01/2007 15:33

To
Avshalom Houri/Haifa/IBM@IBMIL, <[email-masked]>
cc

Subject
RE: [Simple] Errors on older notifications

Regards

Keith

                 When a subscriber gets a NOTIFY with a lower CSEQ, can it 
return
an error 
                 and still keep the subscription? 
 
                 Should it return 200 OK? 

                 Thanks 
                 --Avshalom

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jan 2007 11:17:43 -0500

> This seems to contradict RFC 3261 and the dialousage draft.

I agree that there seems to be a conflict here. However the accompanying 
text in 3265 explains the rationale, and I believe based on that the 
dialogusage approach should take precedence, at least in some cases. In 
particular, if the notifier has sent a NOTIFY before receiving a 
response to a previous NOTIFY, then this error can occur without 
implying any serious problem.

However this could probably stand to have some further discussion. 
Perhaps Adam (author of 3265) will provide an opinion.

	Paul

> Regards
> --Avshalom
> 
> 
> 
> 
> 
> *"Drage, Keith \(Keith\)" <[email-masked]>*
> 
> 10/01/2007 15:33
> 
> 	
> To
> ------------------------------------------------------------------------
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 12 Jan 2007 10:37:39 -0600

So I believe dialog-usage says what we want and that this points to  
another clarification to 3265 and possibly to the event packages.

The effect of overlapping transactions were ill-defined when we did  
3265 (remember the arguments we had in SIMPLE about disallowing
them for Event: presence, and a little further back the arguments in  
SIP about disallowing them in a dialog period) - there are things we
learned since then that we need to capture.

RjS

---

From: Avshalom Houri <[email-masked]>
Date: Sun, 14 Jan 2007 14:40:57 +0200

Time for 3265-bis?
In addition to that overlapping transactions etc. it can include also some 
optimizations as etags.

--Avshalom

Robert Sparks <[email-masked]> 
12/01/2007 18:37

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
"Drage, Keith \(Keith\)" <[email-masked]>, [email-masked]
Subject
Re: [Simple] Errors on older notifications

The effect of overlapping transactions were ill-defined when we did 3265 
(remember the arguments we had in SIMPLE about disallowing
them for Event: presence, and a little further back the arguments in SIP 
about disallowing them in a dialog period) - there are things we 
learned since then that we need to capture.

RjS

RFC 3265 Section 3.2.2: 

Regards 
--Avshalom

To

Subject

Regards

Keith

                
                Should it return 200 OK? 

                Thanks 
                --Avshalom