I have noticed the following things while investigating SAA issues: 1: when our SipSubscribeServer receives a 500 or other error response to a NOTIFY it sent, it calls endSubscription and removes its internal references to the subscription, but does not send a NOTIFY with subscription-state=terminated, as described in RFC3265 3.3.4:
"A subscription is destroyed when a notifier sends a NOTIFY request with a "Subscription-State" of "terminated"." This means that when the set continues to use the subscription dialog, it is rejected by sipXecs. 2: although the SipPersistentSubscriptionMgr persists the CSEQ of the NOTIFYs it sends, there appears to be a timer involved, such that if a service is restarted soon after sending a NOTIFY, it will use a CSEQ which is too small. This causes Polycom sets to reject the new NOTIFY, which in turn causes problem #1. I'm going to see whether I can improve these behaviours. 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/
