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.
>
> It currently appears to use one when adding a new row to the IMDB, and
> the other when updating it - hence the NOTIFY CSEQ numbers always
> started over at 1 when sipxsaa restarts (regardless of the 20 second
> timer, which would only kick in on a complete restart - another issue
> altogether).
> updating NOTIFY version (SipPersistentSubscriptionMgr::updateVersion):
> SipPersistentSubscriptionMgr::updateVersion to =
> '<sip:47.135.152.41:5170>;tag=01eee6ab' eventType = 'dialog', eventId =
> '', cseq = 4
>
> adding new subscription
> (SipPersistentSubscriptionMgr::updateDialogInfo, as evidenced by dumping
> the table on startup):
> SipPersistentSubscriptionMgr:: table row: toUri =
> '<sip:47.135.152.41:5170>;tag=01eee6ab', notifycseq = 1, component =
> 'saa', eventtype = 'dialog;sla'
>
> 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
_______________________________________________
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/
