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

Re: [reSIProcate] Multiple REFER handling in resiprocate


On 2010 September 01, Wednesday 15:48:46 Robert Szokovacs wrote:

Once more, 

After some contemplation, I realized that the correct solution isn't in my 
last mail, but instead the one I attached to this mail (MultiRefer3.patch).

So the complete solution is the combination of two patches: MultiRefer.patch 
and MultiRefer3.patch.

br

Szo

> On 2010 August 30, Monday 14:20:28 you wrote:
> 
> Hi again,
> 
> Meanwhile I have noticed that my patch is incomplete and doesn't work as
> is, because the DUM will thread the second and later REFERs the same as
> the first one, see BasesSubscription::matches(). I attached another patch
> that addresses this problem and hopefully doesn't break anything else.
> 
> br
> 
> Szo
> 
> > On 2010 August 24, Tuesday 15:58:05 you wrote:
> > > Hi Robert,
> > > 
> > > Makes sense to me.  I would be great if you could submit a patch for
> > > this.  Thanks!
> > 
> > Hi,
> > 
> > Here is the least invasive modification I could come up with. Please note
> > that it adds the subscription id to all subscriptions generated by a
> > refer, not just to the second and later ones. If you think it should be
> > done that way, we need more changes, probably check if
> > mServerSubscriptions empty in resip::Dialog, but I'm not sure about that.
> > 
> > br
> > 
> > Szo
> > 
> > > Regards,
> > > Scott
> > > 
> > > On Thu, Aug 19, 2010 at 6:03 AM, Robert Szokovacs
> > > 
> > > <rszokovacs@xxxxxxxxxxxxxxx> wrote:
> > > > Hi,
> > > > 
> > > > we're developing a server application where the client can send
> > > > multiple REFER requests in the same dialog. According to RFC3515,
> > > > section 2.4.6, each REFER creates a subscription and they are
> > > > identified by an Event header in the NOTIFYs. The RFC states that
> > > > this Event header must include an id parameter, equal to the CSeq
> > > > header of the REFER request that created the subscription. Currently
> > > > the DUM code doesn't do this (see BaseSubscription::BaseSubscription
> > > > in resip/dum/BaseSubscription.cxx), it just puts "refer" in the
> > > > Event header (or if the request had an Event header, it is kept and
> > > > used in the NOTIFY too).
> > > > I think this is not the correct behaviour and it can be easily fixed.
> > > > Should I send a patch here?
> > > > 
> > > > br
> > > > 
> > > > Szo
> > > > _______________________________________________
> > > > resiprocate-devel mailing list
> > > > resiprocate-devel@xxxxxxxxxxxxxxx
> > > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
--- BaseSubscription.cxx.orig	2010-09-02 12:04:58.000000000 +0200
+++ BaseSubscription.cxx	2010-09-02 12:04:16.000000000 +0200
@@ -52,7 +52,8 @@
       }
       else
       {
-         return mEventType == "refer";
+         return (mEventType == "refer" && 
+             Data(msg.header(h_CSeq).sequence()) == mSubscriptionId);
       }
    }
 }