> -----Original Message----- > From: Worley, Dale (BL60:9D30) > Sent: Monday, August 17, 2009 4:00 PM > To: Beeton, Carolyn (CAR:9D60) > Cc: [email protected] > Subject: Re: [sipX-dev] PersistentSubscriptionMgr and eventType > > On Mon, 2009-08-17 at 15:19 -0400, Carolyn Beeton wrote: > > I have finally come to the root cause of my sipxsaa restart > woes: it > > has to do with the SipPersistentSubscriptionMgr and how it accesses > > the IMDB records for the subscription; specifically, > whether it uses > > the eventType ('dialog') or the eventTypeKey ('dialog;sla') > to access them. > > > > I'm not sure which one is "correct", or if it matters as > long as it's > > consistent (the subscription is identified by the various tags, not > > the > > eventtype...) I'm not clear on the use of the eventId parameter. > > I think you're running into an error in the existing code: > The eventType and the eventTypeKey have to be tracked > separately, and looking at subscription.xml, I see that they > are not. (If they didn't have to be tracked separately, > SipSubscriptionMgr wouldn't bother to do > so.) > > The eventId parameter carries the value of the "id" parameter > of the Event field, so that two subscriptions with the same > event value but different id values can be distinguished. > We've not tested that, so I don't know if it works. But the > semantics we should be implementing > are: > > subscriptions are identified (in regard to the SIP protocol) > by the eventType and eventId values. > > When a subscription is established, we compute he > eventTypeKey, which is the "type of data" parameter used to > look up the values to deliver. > > (I hope that makes things clearer.) > > Dale
I'm not sure. The SipSubscriptionMgr actually tracks only the eventTypeKey (see for example line 426). In subscription.xsd, the eventType field is described as "The "event type key" from the Event header. This will not include event-type parameters unless they specify something about the event info to be generated. In particular, the 'id' parameter will not be included." I think it is clearly describing eventTypeKey, but is unfortunately named eventType. The SipPersistentSubscriptionMgr.cpp uses the eventTypeKey from SipSubscriptionMgr in updateDialogInfo, but in updateVersion it gets eventType directly from the message. I think here it should be getting eventTypeKey from SipSubscriptionMgr. It seems to me that the eventTypeKey is all we need to track. The eventTypeKey is determined at SUBSCRIBE time by an event-specific callback (so for SAA, it uses the entire field with parameters in order to track 'dialog;sla' - perhaps this isn't quite correct, in that it should explicitly strip off an id=xxx tag, but that would be in the application's control) By changing all references in the PersistentSubscriptionMgr to use the eventTypeKey for the subscription (i.e. from SipSubscriptionMgr), my persistence problems go away. (Well, I also have to have the IMDB persistence fix mentioned separately) 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/
