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 --- On Wed, 12/23/09, Jan Fricke <fanatik...@gmx.de> wrote: > From: Jan Fricke <fanatik...@gmx.de> > Subject: Re: [sipxtapi-dev] Presence problem second notify answered with 481 > To: sipxtapi-dev@list.sipfoundry.org > Date: Wednesday, December 23, 2009, 3:33 AM > Hello again, > I figured out that sipxtapi does not find the dialog on > second notify > because it seems the remote-tag of the stored dialog is > empty. > > I debugged SipSubscribeClient::handleNotifyRequest. > > The SipDialogMgr should store the dialog (including callId, > from-tag, > to-tag) on first notify. It seems to do this correct at > mpDialogMgr->updateDialog(notifyRequest, > notifyDialogHandle); > > > But when the second notify message arrives foundDialog is > false because > > UtlBoolean foundDialog = > mpDialogMgr->dialogExists(notifyDialogHandle); > > SipDialogMgr::dialogExists iterates through all dialogs. > The > corresponding (with the correct callId and localTag) has no > remote-tag. > That should be the reason why sipxtapi does not recognize > that the > second notify belongs to the dialog of the first notify. > > I could not figure out whats going wrong at storing the > dialog. Is there > anybody who can assist me with that? > > > > Hi members, > > hope someone can help me. > > My setup: > > SipX 4.0.1 > > sipXtapi 3.3 (SVN Rev 11467) compiled with Visual > Studio > > > > I try to subscribe presence states of some phones by > subscribing the > > resourcelist at our sipx. > > The subscription is answered with an 202 followed by a > Notify message. > > The second Notify message from the presence server is > answered by > > sipxtapi with 481 Transaction does not exist. > > Below you find the subscribe and notify messages. > > > > What does transaction does not exist mean? The second > notify belongs to > > the dialog initiated by the subscribe message (same > call-id same from > > and to header tags). The CSeq is increased by one and > a new via branch > > was created. So I see no problem. Same dialog, new > transaction. > > > > Thanks in advance > > > > Jan > > > > _______________________________________________ > sipxtapi-dev mailing list > sipxtapi-dev@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ > _______________________________________________ sipxtapi-dev mailing list sipxtapi-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
