RE: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

["GARCIN Sebastien RD-CORE-ISS" <[e-mail]>]

hi 

>>The objections that I have repeatedly raised with the "abuse" of SUBSCRIBE to activate a service aren't purely academic

I am still missing the "non-academic" arguments that would convince me not to the procedures in draft-ploetz.

Thanks for clarifying that part.

sébastien

-----Message d'origine-----
De : Adam Roach [mailto:[e-mail]] 
Envoyé : jeudi 2 novembre 2006 16:43
À : Jonathan Rosenberg
Cc : IETF Sipping List
Objet : Re: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

Jonathan Rosenberg wrote:
> Its not clear to me that this mechanism works well in the face of 
> forking. Seems like you could end up with disparate queues for each of 
> my phones.

That's pretty much what I intended, yes. As far as I can tell, the net result -- that is, the behavior of the system -- would end up being identical (or, at least, substantially the same) with queues maintained on each of your devices versus a single, centralized queue -- unless there's more than one of you, in which case neither solution will behave particularly gracefully (although I believe the forking setup has better recovery properties under such circumstances).

When I get a spare moment, I'll work through a few scenarios to demonstrate how the externally observed system behavior is the same between distributed management of several queues and centralized management of one queue.

> Similar issues arise when the originating user has multiple devices. 
> So if I call you from phone 1, and later you are available, does the 
> ringback happen only at phone 1 or all of my phones? Seems like the 
> latter is much more desirable. That too implies that a UA-based 
> solution on the originating side has some problems.

That depends. Are you asserting this as a new requirement? No one has raised this capability as a requirement so far, and the previously offered solution certainly didn't have this property.

To be clear: I agree that this is probably an improvement on the service; however, the more requirements we pile on, the harder a solution becomes -- and we've become experts at putting so many requirements on a problem that the solution space dwindles down to nothing.

> There is clearly a relationship between all of this and presence; I 
> think you need to call that out.

Martin beat me to it, but I'll reiterate his comment: the relationship here isn't related as much to presence as it is to dialog state. And that is called out in the discussion about centralized queue management.

> On whether BFCP is the right thing or not for this problem, I'm not 
> sure. In one sense, you could characterize this as really a problem 
> with RFC3265 in general; that for certain event packages, notification 
> of an event to all watchers can cause them to take actions that result 
> in a further change to that same state. This is a race condition.

Not in general -- this race condition arises in the draft-poetzl document because it's doing something with SUBSCRIBE that SUBSCRIBE was never meant to do: changing the state of the thing that is watched.

Let's go back to first principles: SUBSCRIBE is a request to retrieve the state of a resource, and receive that state whenever it changes. 
It's a way for an observer to *LOOK* at a state.

Now, as I'm always having to tell my kids: you look with your eyes, not with your hands. If the act of subscribing to a state changes that very state, then you're no longer looking -- you're touching. SUBSCRIBE doesn't touch the state it's monitoring. (Now, we have defined some
*meta* state regarding the very state of that subscription, but you need to subscribe to that separately, and the act of subscribing to that meta-state doesn't change the meta-state).

If you violate the basic principles on which a protocol was developed, then, yes, you end up with protocol characteristics that are highly undesirable. The race condition you describe is one. The objections that I have repeatedly raised with the "abuse" of SUBSCRIBE to activate a service aren't purely academic: if you use a protocol in a way that is well outside its original design, then clearly identifiable bad things happen.

> I share John's concerns as to whether this really interoperates with 
> the PSTN. Perhaps if you had some call flows demonstrating it, this 
> would help.

Martin has put together some pretty nice call flows showing how this interoperates with the PSTN. Perhaps he could be convinced to share them with the wider group?

/a

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

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