< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] DUM REFER crash


Even if the stack prevented the REFER, 

If the other side of the wire has a faulty stack, and sends you a
NOTIFY, event=refer, just flat out of the blue.
A release build will crash, and the assert doesn't prevent it.

I think its probably safer to not push anything onto the
"mClientSubscriptions", unless there is a handler for it.

But, 
Rather than the stack is "automatically" creating a ClientSubscription
in this case, it should reject the NOTIFY message

I just don't think asserting, or throwing a UsageException is the final
solution for this.
 

-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf
Of Jason Fischl
Sent: Friday, August 18, 2006 2:30 PM
To: Matt Porter
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] DUM REFER crash

On 8/18/06, Matt Porter <mporter@xxxxxxxxxxxxx> wrote:
>
> 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.

Seems like there should be an assert here.