I assume we should backport this to the 1.1 release branch, yes?
Best regards,
Byron Campen
Thanks Matt – I just committed this fix.
Scott
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Matt Porter Sent: Thursday, February 08, 2007 2:14 PM To: resip Subject: Re: [reSIProcate] refer with refSub = falsestillcauseClientSubscriptionHandler be used
This is definitely something to be aware of when using the Dum.
Always have a ClientSubscriptionHandler for refer.
Even if you never issue a REFER, if the far side sends you a NOTIFY with no event in it at all…blammo!
See…. Dialog.cxx ( around line 496 )
if (mInviteSession != 0 && (!msg.exists(h_Event) || msg.header(h_Event).value() == "refer"))
It’s a 1 line fix to Dialog.cxx… change it to this code, and you wont have to worry about it.
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin Sent: Wednesday, February 07, 2007 7:36 AM To: maodonghu; resip Subject: Re: [reSIProcate] refer with refSub = false stillcauseClientSubscriptionHandler be used
I agree that behaviour would be nice. In the meantime, you can always add a ClientSubscriptionHandler and have your application reject the NOTIFY with rejectUpdate().
Scott
From:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx on behalf of maodonghu Sent: Tue 2/6/2007 11:52 PM To: resip Subject: [reSIProcate] refer with refSub = false still causeClientSubscriptionHandler be used
resip
I call refer with refSub = false, but if the the other party still send NOTIFY, the dum will assert(ClientSubscriptionHandler), I think if refSub = false, the NOTIFY should be reject by dum, not go to try get a ClientSubscriptionHandler