Dear SIP stack developers, We recently ran into the following interop issue: client receives a NOTIFY out-of-order and sends a 500 error response, presence server terminates the subscription
The above behavior is consistent with RFC3265 section 3.2.2: 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.However, in this case the appropriate action would be for the PS to resend the NOTIFY (with a fresh CSeq).Our client did not include a Retry-After header in the 500 response, RFC3261 does not discuss this. So, suggestion to improve interoperability: please add a Retry-After: 0 header to errors which can be solved by retrying, in particular this 500 errorBest regards,Jeroen _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
