Subject: [Sipping] consecutive NOTIFY and automatic unsubscription upon 500 error re sponse

From: Pinal Jean-Pierre <[email-masked]>
Date: Thu, 18 Dec 2003 16:03:36 +0100

Hello 

1)

As described in RFC 3261, a UA may start a next transaction before the previous is terminated 

(except for INVITE)

2)

After subscription, if notifier sends two consecutive NOTIFYs, the 

subscriber may receive the second NOTIFY first and reject the first 

with 500 in conformance with RFC 3261

RFC 3261

12.2.2 UAS Behavior

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

3)

And in RFC 3265

"A NOTIFY request is considered failed if the response times out, or a

non-200 class response code is received which has no "Retry-After"

header and no implied further action which can be taken to retry 

therequest (e.g., "401 Authorization Required".)"

...

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

=> In the case when second NOTIFY is received before first, the NOTIFIER receives a 500 for the first NOTIFY and the subscription is removed!

But the subscriber does not want that its subscription is removed! 

Here, what is wrong?

Must the subscriber sends a 500 with always a Retry-After header in order to avoid subscription deletion?

In this case, must the NOTIFIER send a new NOTIFY with a full description of subscribed state?

I found nothing in RFC3265 about consecutive NOTIFYs.

Or must the implied event package define in "Notifier generation of NOTIFY requests" section that the notifier can not generate a new NOTIFY before response of the previous NOTIFY has been received?

I think it is not the responsibility of event package

Is there a lack in RFC3265?

Best regards

Jean-Pierre

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 18 Dec 2003 10:21:20 -0500

inline......
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Pinal Jean-Pierre
  Sent: Thursday, December 18, 2003 10:04 AM
  To: [email-masked]'
  Subject: [Sipping] consecutive NOTIFY and automatic unsubscription upon
500 error re sponse

  Hello

  1)

  As described in RFC 3261, a UA may start a next transaction before the
previous is terminated

  (except for INVITE)

  2)

  12.2.2 UAS Behavior

     Error) response."

  [TOLGA] Based on the error code, it seems to me like an oversight. For
UDP -or if different streams are used per transaction for SCTP- there might
be reordering of requests. To cover such a case, I would expect some other
error code. 500(Server Internal Error) sounds to me more like implying
something wrong on the UAS, rather than missequencing on the network. In
fact the above statement in RFC3261 12.2.2. makes me think that as long as
there is a possibility of missequencing in the network, it is better to wait
a transaction to end, before starting a new one. At least, I would do it
that way in my application, you won't loose much. Non-INVITE tranasactions
are supposed to end with no significant delays.

  3)

  And in RFC 3265

  ...

  subscription."

  => In the case when second NOTIFY is received before first, the NOTIFIER
receives a 500 for the first NOTIFY and the subscription is removed!

  Here, what is wrong?

  Must the subscriber sends a 500 with always a Retry-After header in order
to avoid subscription deletion?

  In this case, must the NOTIFIER send a new NOTIFY with a full description
of subscribed state?

  [TOLGA]Although there are no hard limits there is the following:

  RFC3265 4.1

  "Further, it is expected that this mechanism is not to be used in
applicationss where the frequency of reportable events is excessively
rapid(e.g., more than about once a second)."

  Or must the implied event package define in "Notifier generation of NOTIFY
requests" section that the notifier can not generate a new NOTIFY before
response of the previous NOTIFY has been received?

  Best regards

  Jean-Pierre

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Dec 2003 01:52:36 -0500

This is a good question. I believe it is an error in RFC 3265, as this 
case should not cause termination of the dialog. The essence of the 
problem is that RFC 3265 has much more strict rules for dialog 
termination than RFC 3261. In RFC 3261, it is only a 481 or 408 which 
causes dialog termination. RFC 3265 adds to that, extending it to any 
error response for which a remedy is not apparent. It is not obvious 
as to whether a 500 response fits into the category of "no further 
action can be taken to retry the request".

However, I would argue that, in the case of a 500, there is a clear 
action. According to RFC 3261, you should try again in a few seconds. 
As a result, a 500 response should not be a failure as defined by 
rfc3265 and not cause the dialog to terminate. However, this is far 
from clear in RFC 3265, and the spec ought to have been more clear 
about exactly which response codes really constitute a failure. We 
need to clarify that 500 does NOT.

I've added this to bugzilla. You can find the bug report at:
http://bugs.sipit.net/sipwg/show_bug.cgi?id=744

Thanks,
Jonathan R.

Pinal Jean-Pierre wrote:

> Or must the implied event package define in "Notifier generation of 
> NOTIFY requests" section that the notifier can not generate a new NOTIFY 
> before response of the previous NOTIFY has been received?
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Dec 2003 08:52:58 -0500

I believe the main problem is with 3261 rather than with 3265. Allowing
concurrent transactions and than rejecting them because of missequencing in
the network with an error code indicating "Server Internal Error" sounds
strange to me. One could argue, if the client is aware that there might be
missequencing in the network, it should not start concurrent transactions,
but even then I don't see something to be done on server side, so this error
code still sounds not very appropriate to me.
For example, for the specific case described below, one can change 3265 to
handle 500 error correctly. But what does it mean "correctly", what if it is
generated because of a real server internal error rather than missequencing
in the network?
So, I believe, it might be an idea to have a special error code for network
missequencing in 3261. Also an explanation about concurrent transaction with
networks not guaranteeing sequence prevention might help.

   Tolga

> Jonathan Rosenberg
> Sent: Monday, December 22, 2003 1:53 AM
> To: Pinal Jean-Pierre
> Cc: [email-masked]'
> Subject: Re: [Sipping] consecutive NOTIFY and automatic unsubscription
> upon 500 error re sponse
>
>