Re: [reSIProcate] DUM REFER crash
DUM would respond to this NOTIFY w/a 481 if there is no matching dialog and
a 489 if there is a matching dialog.
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Matt Porter
> Sent: Friday, August 18, 2006 1:01 PM
> To: Jason Fischl
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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.
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel