Re: [reSIProcate] DUM REFER crash
Im not disagreeing with the "programming error"... I sure have my fair
share of those.
I think that the stack shouldn't send a REFER, if the subscription
handlers arent there to respond/support it.
OR
The stack shouldn't "automagically" creates this subscription in the
first place if there is no handler for it..
-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf
Of Jason Fischl
Sent: Friday, August 18, 2006 2:04 PM
To: Matt Porter
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] DUM REFER crash
You need to install a handler. It should assert in this case rather than
crash. However, it is a programming error. I don't think this can occur
from events from the wire.
On 8/18/06, Matt Porter <mporter@xxxxxxxxxxxxx> wrote:
> Dialog.cxx
>
> DebugLog (<< "Making subscription from NOTIFY: " << msg);
> ClientSubscription* sub = makeClientSubscription(msg);
> mClientSubscriptions.push_back(sub);
> ClientSubscriptionHandle client = sub->getHandle();
> mDum.mInviteSessionHandler->onReferAccepted(mInviteSession->getSession
> Ha
> ndle(), client, msg);
> mInviteSession->mSentRefer = false;
> sub->dispatch(request);
>
>
>
> ClientSubscription.cxx
>
> void
> ClientSubscription::dispatch(const SipMessage& msg) {
> ClientSubscriptionHandler* handler =
> mDum.getClientSubscriptionHandler(mEventType);
> assert(handler);
>
> !!! UGG
> handler is null, I have no handlers for event=refer
>
>
> Maybe I should have a subscription handler for a NOTIFY, event=refer.
> crashing seems to be an extreme side affect, if I don't..
> At least check the pointer before calling the method.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>