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

Re: [reSIProcate] DUM REFER crash


Guys, the DUM does not respond with any error code, it asserts in
debug.. and crashes in release.
I verified this with the very latest code in SVN.

In my opinion....
1.      the stack should never crash/assert because of a faulty message
from the wire.
2.      the stack should check for a Handler (in Dialog.cxx) before
pushing ClientSubscription's in the list.
3.      the stack should throw a UsageUseException if
InviteSession::refer is called when there is no handler for the event.

Take it or leave it, I think this is going to the same "Blackhole" that
all my other comments on the stack go and that's fine.
I don't why there is so much push back from the maintainers about things
like this / feature requests.


-----Original Message-----
From: Derek MacDonald [mailto:derek@xxxxxxxxxxxxxxx] 
Sent: Monday, August 21, 2006 12:45 PM
To: Matt Porter; 'Jason Fischl'
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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