We have been having intermittent problems with SAA on our scstrial.ca, and I think the root cause is that we terminate subscriptions when we receive 500 Internal Server Error.
The Polycom sets object to Cseqs being sent out of order, and we appear to do this from time to time. They send us 500 Internal Server Error but then continue on to OK all the (mixed-up) NOTIFYs. This appears to be correct, based on rfc3261: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. " However, we terminate their subscription when we receive the 500 response. Things are then handicapped (the set will not receive line-seize NOTIFYs) until eventually they try to reSUBSCRIBE to us on that same subscription, which they consider to be up and running. We reject it with 481 Does Not Exist, and since the Polycom links the incoming and outgoing subscriptions, they internally cancel both subscriptions. Now the feature is entirely dead, until we eventually try to reSUBSCRIBE to them. We receive 481, but that triggers us to reestablish a new subscription, which triggers them to subscribe to us, and we are now good until the next time we mix up the cseq. Today, this scenario happened twice. Is terminating a subscription on response of 500 Internal Server Error ok? Things would work a lot better if we did not... and I think it would comply better with 3261 21.5.1: "The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds. If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field." I vaguely remember an old discussion wherein Dale suggested that they put a Retry-After header in the 500 message, which we don't exactly handle, but at least we don't terminate the subscription if one is present. However, since the spec says that they MUST reject with 500 and only MAY use the Retry-After header, is terminating a subscription of receipt of 500 response without Retry-After too extreme? 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/
