> From: Robert Szokovacs [[email protected]] > > The "B" stack refuses the retransmitted 183 NOTIFY with 500, because it's cseq > is smaller than the 180's, which seems correct as per 12.2.2 of RFC3261: > " > 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. > " > > The "A" stack in turn terminates the subscription and the transaction dies, > because the mediaserver application expects to receive more NOTIFYs, at least > one with "subscription-state: terminated", but it never comes. The "B" stack > doesn't notify the mediaserver application, so has no way of knowing something > went wrong. > > What would be the correct behavior?
As we've discussed, how should an out-of-order NOTIFY be handled? Of course, it must be responded to with a 500 response. The problem is that in practice we don't want the notifier to terminate the subscription. RFC 3265 says that the notifier must terminate the subscription; RFC 5057 says that the notifier should not; draft-ietf-sipcore-rfc3265bis follows RFC 5057. In practice, the notifier can omit removing the subscription with little harm. If the subscriber terminated its knowledge of the subscription, when the notifier sends the next NOTIFY, the subscriber will respond with 481, which will cause the notifier to delete the subscription. Better, when the subscriber responds with a 500 Out Of Order response, it should add a "Retry-After: 0" header. Even if the notifier is following RFC 3265 rules, this will prevent the notifier from removing the subscription. (I forget who told me of this trick. It may have been Adam Roach.) We have found this to work well in practice. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
