On Fri, 2009-08-14 at 10:03 -0400, Carolyn Beeton wrote: > 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.
This is a known problem; I think there's an issue for it. (The subscription is torn down on the set's side when the set sends a NOTIFY and sipX responds 481.) > 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. My guess is that this is due to the 20 second delay in persisting -- the IMDB table is written 20 seconds after the first change is made. What would be a good solution? Dale _______________________________________________ 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/
