On Wed, 2009-08-19 at 15:28 -0400, Carolyn Beeton wrote: > I am not clear about how to interpret 3265 about NOTIFY error responses: > > RFC3265 3.2.2 (Notifier NOTIFY Behavior) says: > "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 the > request (e.g., "401 Authorization Required".) > > If the NOTIFY request fails (as defined above) due to a timeout > condition, and the subscription was installed using a soft-state > mechanism (such as SUBSCRIBE), the notifier SHOULD remove the > subscription." > > 3.2.4 (Subscriber NOTIFY Behavior) does not say whether SENDING an error > response should cause the subscription to be removed. > > RFC3265 3.3.4 says: > "A subscription is destroyed when a notifier sends a NOTIFY request with > a "Subscription-State" of "terminated"." > > So - if we receive an error response to a NOTIFY (e.g. 500), are we > required to send a NOTIFY with subscription-state=terminated? or can we > silently remove the subscription (which is what we do now)?
I believe that the authors didn't write it clearly. I think what was intended was that if a NOTIFY receives an error response, the notifier drops the subscription immediately and does not need to send a further NOTIFY to tell the subscriber. It doesn't help interpreting the text that at no point in 3265 does the text clearly distinguish "knowledge of the subscription at the subscriber" and "knowledge of the subscription at the notifier" -- and all of the interesting cases are when those two might not be the same. If the NOTIFY receives a 481 (subscription unknown) response, then of course there is no point sending a further NOTIFY, as the notifier has positive knowledge that the subscriber does not know of the subscription. If the NOTIFY receives a 500 (which might mean Out Of Order), there is no good reason to assume that a terminating NOTIFY will get through to the application layer, as opposed to getting a 500 response itself. A 408 response is more interesting: The notifier knows that a terminating NOTIFY *might* get through, but the odds are fairly good that the transport problem still exists. *** Beware that if the error contains "Retry-After: xxx", then the error does *not* terminate the subscription, per the 3265. In many cases, UAs (including sipXecs) add "Retry-After: 0" to 500 responses for this reason. In some cases, subscribers do not add this header when it would be useful for them to do so. And in some cases, notifiers will not terminate subscriptions upon receiving 500 *without* Retry-After, in order to compensate for that class of subscribers. We have some related issues which discuss these problems: XX-363 Handling of 500 responses to NOTIFY requests XTRN-10 Suggest to Polycom adding "Retry-After: 0" header in 500 Out Of Order responses XX-433 When returning 500 error to a NOTIFY for "CSeq out of order", add "Retry-After: 0" header > What I am seeing with the CSEQ too low problem, is that Polycom sends > "500 Internal Server Error", then attempts to reSUBSCRIBE on the same > call-id. I don't think this is quite kosher either, but it doesn't work > because we have ended the subscription without telling them - so we > return 481 and the subscription dies (and they do not attempt a fresh > subscription). I've seen this. What the Polycom is doing is attempting to determine if the notifier terminated its subscription when it received the 500. I don't remember whether the P'com puts Retry-After: 0 into the 500 or not, but it knows that it cannot rely on the notifier to handle 500's properly. So it sends an immediate re-SUBSCRIBE to determine if the subscription is still live. In the cases I looked at, if the re-SUBSCRIBE succeeds, the P'com will continue to use the subscription, but if the re-SUBSCRIBE fails, the P'com will start a new subscription. Obviously, if the re-SUBSCRIBE gets 481 but the P'com does *not* start a new subscription, the P'com is malfunctioning. > Note that I have attempted to implement the main part I think we're > missing: i.e. to terminate the subscription on receipt of the 500 > response and to tell the set via NOTIFY(subscription-state=terminated); > but then the set does not attempt to reSUBSCRIBE at all. So what would > probably work the best given what I have to work with is NOT to end the > subscription (either silently, as we do now, or with a > NOTIFY(terminated), as I have attempted) and then the reSUBSCRIBE would > trigger a fresh NOTIFY... but I don't think this complies with the spec > on either our part or Polycom's. Do compare with the discussions attached to the issues I mentioned. > Any comments? Welcome to the swamp! Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
