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

[Adam Roach <[e-mail]>]

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