Re: AW: [Sipping] Call Completion: In Defense of Explicit Operations

[Adam Roach <[e-mail]>]

Thank you, Paul. You've summarized the key points in a very coherent 
fashion.

/a

Paul Kyzivat wrote:
>
>
> Huelsemann, Martin wrote:
>> I think the part of the solution where are no doubts is that we can 
>> use SUB/NOT to inform the user about his call-completion state 
>> (queued, or he is the one who shall start the recall). IF we decide 
>> for a SIP solution, which I think we should do if there are no 
>> technical reasons against, because BFCP seem to be easy to implement 
>> with the necassary knowledge, but it is still another protocol.
>> The question is, when SUBSCRIBEs are used anyway, why can't we reuse 
>> them for queue manipulation actions? Why put another RFC into the 
>> terminal, when RFC 3265 would be enough. The simpler those terminals 
>> are, the cheaper they will be, and the more people will use them.
>> Yes, using the SUBSCRIBE also for queue manipulations would be one 
>> operation with two effects, but where is the harm? There is a similar 
>> use in the policy package, which submits an SDP in the SUBSCRIBE 
>> request and gets back a policy for that SDP in the NOTIFY request.
>
> Lets go through this again:
>
> Suppose it does work that way. Then conceptually what is the event 
> state that is being subscribed to? Apparently it is the queue of 
> potential callers. In principle, every time this state changes there 
> should be a notification sent to *all* the subscribers.
>
> Now it could be that policy is used to restrict how much visibility 
> subscribers have to the event state. So the views of some may be such 
> that they can't see the change, and so get no notification of it. But 
> arranging things that way requires structuring the state very 
> carefully. For instance, the policy might state that a subscriber can 
> only see entries that refer to them. But this wouldn't be very 
> interesting unless their entry included "position in queue". That 
> would result in getting a notification each time your entry advanced 
> in the queue. If that is annoying there could be a filter that says to 
> only display entries that are "first in queue".
>
> None of that says anything about queue manipulation - just using 
> sub/not to observer a queue in a useful way for this purpose.
>
> Note that we do have an example where the act of subscribing creates 
> state that can itself be subscribed to. It is watcherinfo. But in that 
> case there are two event packages in use - e.g. presence and 
> presence.watcherinfo. Subscribing to presence creates watcher state 
> that can be observed by subscribing to presence.watcherinfo. Having a 
> SUBSCRIBE modify the state of the event being subscribed to introduces 
> a sort of Heisenberg Uncertainty Principle - you can't observe the 
> event without affecting it.
>
> Specifically, it becomes impossible to observe the queue without 
> becoming one of the requesters. For instance, suppose the queue was 
> managed on a server separate from the UAs that receive calls to the 
> target AOR. They may want to observe the queue themselves. But 
> attempting to do so would seem to cause them to become candidates to 
> call themself. This could be mitigated by requesting that the entry be 
> suspended, but the point remains.
>
> Further manipulation of the queue, such as suspend and resume, also 
> doesn't seem to fit the sub/not model very well. If its done as part 
> of the body (as the current draft specifies) then it should be 
> considered a filter, but filters don't change state of the event - 
> only the view of it. There isn't any good place to specify this kind 
> of action in a subscribe request, for the obvious reason that 
> SUBSCRIBE isn't intended to be used in that way.
>
> I have seen reference to the policy event package as precedent for 
> using bodies to create the state being subscribed to. I think that 
> case is less of a problem because it does fall into a suitable 
> conceptual model as a filter. In theory one is subscribing to all 
> policies. Supplying a body can be viewed as simply a filter 
> restricting notifications to ones pertaining to a particular set of 
> media, etc.
>
>     Paul


_______________________________________________
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