[reSIProcate] Multiple REFER handling in resiprocate

[Robert Szokovacs]

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: MultiRefer.patch
Type: text/x-patch
Size: 543 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100830/1421436e/attachment.bin>