Subject: RE: [Sip] GRUU Mechanism I-D

From: [email-masked]
Date: Thu, 6 Nov 2003 12:12:41 +0200

I share Paul's view.  There are currently too many implementations supporting dialog reuse.

The only suggestion I have is that for any new SIP extension in the future that requires either dialog reuse or GRUU, we use the GRUU approach.

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Paul Kyzivat
> Sent: Wednesday, November 05, 2003 8:00 PM
> To: Robert Sparks
> Cc: Jonathan Rosenberg; [email-masked]; [email-masked]
> Subject: Re: [Sip] GRUU Mechanism I-D
> 
> 
> I would be happy if dialog reuse had never been there. But at 
> this point 
> I think it is impossible to avoid supporting it. And once the 
> effort has 
> been made to support it, deprecating it in favor of a new approach is 
> just that much more work, with more backwards compatibiilty 
> alternatives 
> to consider, etc. At this point I would prefer to live with 
> the mistake.
> 
> 	Paul
> 
> Robert Sparks wrote:
> > I do think it would be very good medicine for the protocol to
> > deprecate all dialog reuse.
> > 
> > My personal preference for modifying REFER is to deprecate the
> > implicit subscription behavior altogether (by strengthening the
> > mechanisms proposed in Sean's and Rohan's drafts perhaps).
> > 
> > I am uncomfortable with the idea of an implicit subscription
> > created with an entirely new dialog id - this would require
> > putting a new dialog correlation algorithm into all implementations.
> > I'm sure we could invent something that worked, but is the 
> complexity
> > worth the gain when just removing the implicit subscription solves
> > the problem and comes with with so much better behavior properties
> > given the GRUU.
> > 
> > RjS
> > 
> > 
> > 
> >>>>This is a good point. Of course, the REAL problem here is 
> that the 
> >>>>REFER request ought to go on the dialog, followed by a separate 
> >>>>SUBSCRIBE to the GRUU, in order to track progress of the 
> refer. That 
> >>>>is, its the implicit subscriptions which makes this complicated.
> >>>>
> >>>>That said, we may need to except REFER from this rule. Bleh.
> >>>
> >>>
> >>>If we need to exempt REFER, then we have admitted that we 
> can't phase 
> >>>out shared dialogs. Then, if we have to continue to support shared 
> >>>dialogs, why do we want to tell people not to use them?
> >>
> >>If there is no way to fix this for REFER, I would have to 
> agree with 
> >>you. However, if there is a possibility to update REFER to take 
> >>advantage of gruu, and thus avoid dialog reuse, then it 
> makes sense. 
> >>AFAICT, the fix to REFER is not hard at all. The recipient of the 
> >>REFER, who creates the NOTIFY, would simply send it to the 
> gruu of the 
> >>referor, and use a different dialog ID. There is still an implicit 
> >>subscription, but the NOTIFY creates a new, separate dialog.
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 01:35:14 -0500

> I share Paul's view.  There are currently too many implementations

Well, the issue isn't so much as to whether its been implemented, as 
to whether it is being used. I would actually be surprised if there 
was a lot of usage of it, and in particular, interoperable usage of 
it, given the various problems we have identified with it since 
publication of rfc3261.

Can people comment on any real usage of dialog reuse they are aware 
of? I suspect REFER on an INVITE dialog is the main (if only) one...

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com