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 sipxtapi-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
