Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 4 Dec 2001 11:32:27 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2001 8:40 AM
> To: [email-masked]
> Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple
> Subject: Re: [Simple] 200 vs. 202
> 
> 
> OK. Thanks for the tutorial - I think I get it now.
> 
> But, all the complexity and loose ends suggests to me that there is
> something fundamentally wrong with the mechanism here.

Well, the problem is that we are trying to add forking capabilities into a
method thats not ideally suited for it. Given the frequency that I
realistically expect to see forking SUBSCRIBE, I am not too worried.

> As you 
> say, this
> is really an events issue, not a SIMPLE issue. 

Do we have consensus though? I'd like to declare this issue resolved. Adam's
proposal was to accept the first NOTIFY, and ignore the 2xx. I'd like to
suggest a mild variant to that that I think is even simpler. My proposal is
to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, that
establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes first,
you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE may or may
not be for the dialog that was accepted; it doesn't really matter.

Agreement?

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> 
> 	Paul
> 
> [email-masked] wrote:
> > 
> > > From: Paul Kyzivat [mailto:[email-masked]]
> > >
> > > Sorry if I was pointing out the obvious.
> > >
> > > But if you have to save state from the subscribe in order to
> > > decide what
> > > notify to accept, and if, once you accept a notify, you 
> are going to
> > > establish a long lasting dialog and even refresh it 
> periodically by
> > > sending new subscribe requests, do you save anything by not
> > > establishing
> > > the dialog as part of the initial subscription?
> > 
> > The issue being discussed is that the NOTIFY can arrive
> > before the response to the SUBSCRIBE. In fact, if the
> > SUBSCRIBE is forked, this is the most common scenario.
> > 
> > One of my early (strawman) proposals was to wait until the
> > SUBSCRIBE completed before responding to the NOTIFY. This
> > is really rather complex to implement correctly.
> > 
> > An improvement on this scheme was proposed by Jonathan:
> > accept the NOTIFYs that arrive while the SUBSCRIBE is
> > pending, and then un-subscribe to any that do not match
> > the SUBSCRIBE response.
> > 
> > After some analysis, I determined that this could
> > probably be simplified (from an implementation point of view)
> > further by simply accepting the first NOTIFY that could
> > reasonably belong to the pending SUBSCRIBE, and reject the
> > rest with 481s. The logic behind this simplification is
> > that the SUBSCRIBE response isn't special; it just represents
> > the response that happened to race to the forking proxy
> > the fastest. It's not "better" than any of the other
> > potential dialogs in any way.
> > 
> > Sorry for continuing this discussion on the SIMPLE list;
> > as Jonathan has pointed out a couple of times, this really
> > has turned more into a sip-events issue than a SIMPLE issue.
> > 
> > /a
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2001 16:58:32 -0500

Jonathan Rosenberg wrote:
> method thats not ideally suited for it.

Can't argue with that. It's unfortunate that we have a forking mechanism
that really only works for INVITE even though it is defined for other
methods and (as we see here) is potentially wanted/needed for them as
well.

> Given the frequency that I

As devices are deployed that support presence, it seems like there
could develop a problem with undesired forking. You want forking
for invites, and perhaps don't have any simple way to prevent
forking of subscribes as well.

This won't be a problem if the presence function is combined with the
registrar function and driven off registrations. But it will be a
problem with devices that want to handle presence themselves, like the
MS endpoint. All you need is people with both a desktop and laptop
machine that try to maintain one identity for both.

> not be for the dialog that was accepted; it doesn't really matter.

I don't have a preference between those two alternatives.

I won't stop progress by continuing to argue, but I don't find either
solution very appealing. 

	Paul