[reSIProcate] Multiple REFER handling in resiprocate

Robert Szokovacs rszokovacs at gammatelecom.hu
Thu Sep 2 05:18:02 CDT 2010


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 at gammatelecom.hu> 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 at resiprocate.org
> > > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MultiRefer3.patch
Type: text/x-patch
Size: 348 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100902/f442f96c/attachment.bin>


More information about the resiprocate-devel mailing list