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.