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)? 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). 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. Any comments? Carolyn _______________________________________________ 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/
