Hi Jan: I think I understand the problem. Thank you for your explanation. It would be very helpful if you could send me a clean sipXtapi log file with the debug level enabled. This way I can use the transaction data in your log to test and analyze the issue.
Cheers, Dan --- On Wed, 1/6/10, Jan Thiemo Fricke <[email protected]> wrote: > From: Jan Thiemo Fricke <[email protected]> > Subject: Re: [sipxtapi-dev] Presence problem second notify answered with 481 > To: [email protected] > Cc: [email protected] > Date: Wednesday, January 6, 2010, 12:19 PM > Hi Dan, > I had a further look into the code of sipxtapi the last > days. > Some things I figured out: > > - The 481 just occurs in SipXtapi 3.3 (in 3.2 everything > works fine) > - The problem just occurs if Subscription needs > authentication > (subscribe, 401, subscribe, 202; If I subscribe reg-event I > don't need > authentication and there is no problem) > > I believe there is a problem with the dialog management > with > authentication. SipXtapi does not recognize 202 after the > subscribe with > authentication. It answers the first Notify with 200OK > because it's > possible that the 2xx response arrives after the first > notify. But after > the second notify sipxtapi decides that there is something > wrong. > > The point is that the second subscribe (with authentication > data) does > not trigger the update of the earlyDialog. When the 202 > arrives the > dialog is not updated because the earlyDialog CSeq is still > 1 and the > CSeq of the 202 is already 2 because it was increased by > second subscribe. > > SipRefreshManager::handleMessage (Line 651) checks if the > response > matches the last transaction > SipDialogMgr::isLastLocalTransaction returns false because > dialog->isSameLocalCseq(message) (Line 360) is false > (because dialog > CSeq is 1 and message CSeq is 2) > > > It tried to compare presence related files of 3.2 with 3.3 > but was not > able to make head nor tail of it. > > I'd be glad if you could help me!! If you need some further > information > just let me know. > > Jan > > Am 25.12.2009 23:14, schrieb Daniel Petrie: > > Hi Jan: > > The remote tag (To field) on the initial SUBSCRIBE > request should not be set as it is initiating a new > transaction as the dialog is not established yet. Then > when the 200 response comes back, it should have the remote > tag (To field) set. In updateDialog the dialog manager > should match a dialog with no remote tag (early dialog) with > the 200 response transaction information and then set the > remote tag of the dialog in the list. In some cases > the NOTIFY request beats the SUBSCRIBE response to the > client initiating the SUBSCIRBE request and dialog. > However I believe the dialog manager handles this case. > > > > Cheers, > > Dan > > > _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
