Hi Medhavi:
I am not sure I fully understand the situation or the state machine
implications that you are describing. It would be most helpful if you
could create a unit test case to recreate this problem. Then we can be
sure that we understand the problem, fix it and that it will stay fixed
as we run the unit tests to prevent regressions.
You can find the existing unit tests for SipSubscribeClient in
sipXtackLib/src/test/SipSubscriptionClientTest.cpp.
Cheers,
Dan
--- Medhavi Bhatia <[EMAIL PROTECTED]> wrote:
> We notice that there are no callbacks happening when a 404 is
> instantly
> received to a subscribe request. On making the following change it
> seems
> that the SIP dialog seemed to have upgraded to an established dialog
> while
> the subscribe state may be associated with an early dialog (missing
> to
> tag). The following lookup fails:
>
> IN: SipSubscribeClient::refreshCallback (case
> SipRefreshManager::REFRESH_REQUEST_FAILED:)
>
> UtlString dailogString(dialogHandle ? dialogHandle :
> earlyDialogHandle);
> subClient->lock();
> SubscribeClientState* clientState =
> subClient->getState(dailogString);
>
> When we add the reverse condition to lookup the earlyDialogHandle, it
> seems
> to work coming back with Subscription Expired event (clientState can
> be
> located and the code following it works):
>
> if (clientState == NULL)
> {
> // Lets reverse the condition above since the
> above code
> doesnt work on the first 404
> UtlString dialogString(dialogHandle ?
> earlyDialogHandle
> : dialogHandle);
> clientState = subClient->getState(dialogString);
> }
>
> Not sure if this is the correct fix, so we are posting it here to get
> some
> feedback.
SIPez LLC
SIP VoIP, IM and Presence Consulting
http://www.sipez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
