Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14

[Shida Schubert <[e-mail]>]

Hi Robert;

 I think what Martin explained is along the line of what we had discussed 
at the IETF83.. 

 1. Caller calls the callee.

 2. Callee is busy so either callee or call-completion service (CC monitor)
     sends back the availability of call-completion to be used. 

 3. Caller subscribes to the call-completion pkg by sending SUBSCRIBE.

 4. Either at the when response with call-completion availability is sent 
      OR at the point of receiving a SUBSCRIBE message is received, 
      call-completion service instantiate a presence (and logical presence f
      server if it was the first instance of presence) for the 
      duration of the subscription to the call-completion pkg. 

 5. Caller will manipulate the presence state of its own presence at the 
      callee side.. 

 6. As the queue is deleted / removed from the call-completion so does the 
      associated instance of presence from the presence server.

* Another approach is for CC monitor to subscribe to caller's presence 
at its domain but this doesn't always work because there may not be any 
presence server. 

 Regards
  Shida

On Aug 15, 2012, at 8:00 AM, <[e-mail]> <[e-mail]> wrote:

> Hi Robert,
> 
> sorry I somehow missed this mail. Some answers inside.
> 
> 
> Regards, Martin
> 
> 
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Robert Sparks [mailto:[e-mail]]
>> Gesendet: Dienstag, 21. Februar 2012 16:38
>> An: Hülsemann, Martin
>> Cc: [e-mail];
>> [e-mail];
>> [e-mail]; Jesske, Roland; [e-mail];
>> [e-mail]
>> Betreff: Re: AW: [BLISS] AD review:
>> draft-ietf-bliss-call-completion-14
>> 
>> Thanks Martin - more comments inline.
>> 
>> Will you be at the Paris IETF meeting?
>> 
>>>> Major issues
>>>> 
>>>>    - The document's proposed use of PUBLISH is not
>> consistent with the
>>>>      semantics of that method. It attempts to use PUBLISH
>> to affect
>>>>      the subscription state, not the state of the event being
>>>>      subscribed to (it's telling that PUBLISHing to this
>> event package
>>>>      doesn't allow setting the state being subscribed
>> to). Among other
>>>>      things, this prevents separating the state agent
>> from the state
>>>>      authority.
>>> The concept is the following: The caller sends it's own
>>> status information in the PUBLISH request. In this case there
>>> is no change in the CC monitor (the queue) state done by the
>>> PUBLISH request directly, but either an indirect change of
>>> the state based on the information about the caller status.
>>> The CC monitor acts as a state composer, composing the state
>>> of the queue from the states of the different callers.
> 
>> This isn't composition. It's conflation of unrelated things.
> As RFC 3863 says, the values 'open' or 'closed' of the presence basic element also indicate the general availability for other communication means than instant message, such as the availability as a (CC re-) call, so I think there is at least a little relation.
> 
>> You have an application that's operating on two unrelated
>> sources of information. If you really want to use sip events
>> to carry the information about the caller, you should be
>> considering a separate event package for it.
> A dedicated suspend/resume event package was our first idea, in my opinion that would have been the cleanest solution. But at discussions on the mailing list people were very reluctant to agree on yet another event package with such a limited scope, while on the other hand presence/PUBLISH conveys nearly the same information, that is if the caller is willing to accept a call or not.
> 
>> If that feels
>> wrong, it's another sign that PUBLISH is not the hammer
>> you're looking for to pound on this particular nail.
>> 
>> Speaking more generally to the events architecture, an
>> element that has enough information to act as a publisher
>> necessarily has the information it needs to be able to serve
>> subscriptions directly. It is choosing to publish to a state
>> agent to deal with matters outside of the contents of the
>> package itself (not always being connected, having limited
>> bandwidth, etc.). Even in an idealized presence system where
>> the ultimate presence document is composed from many
>> contributing publishers, the individual sources have enough
>> information (and it makes sense within the definition of the
>> package) to accept subscriptions to their part of the total
>> state. Further, subscribing to presence.winfo at the state
>> agent will provide meaningful data to each of the
>> contributing sources.
> But I think presence information can be used by other services to trigger certain events? So it would be possible for the CC monitor to subscribe for presence information of the caller, and act upon that?
> 
>> 
>>> 
>>> 
>>> 
>>> 
>>>>      The document modifies how PUBLISH identifies the
>>>>      resource being manipulated by looking at the From URI and not
>>>>      only at the Request-URI.  How the Callee's agent
>> responds to the
>>>>      request to change this subscription state is underspecified -
>>>>      when can it reject a request? What is the caller
>> supposed to do
>>>>      if the request fails?
>>> As mentioned the PUBLISH is not a RPC, the CC agent on
>> behalf of the callee publishes information about the
>> reachability of the callee for CC recalls. The monitor
>> composes the state. This state can be used to evaluate if it
>> is useful to start a CC recall or not.
>> I think you were still trying to respond to the first point
>> above here.
>> This is a different question, and will stand independent of
>> what technique you use to make the request to change the
>> information about the caller. What happens when that request
>> needs to fail (due to parsing, overload, authorization,
>> application-specific logic, or any of the other reasons UAS
>> have to reject requests)?
> The effect of course would be that the CC service would run a less efficient. If the suspension fails, the monitor woud still think the caller is available for the recall and another recall would be started unnecessarily. Respectively CC would be deactivated after the recall timer expiry. We regarded this as acceptable for exceptional situations, as sus/res is not the most important feature of the CC service.
> 
> 
>>>>        - As written, there does not appear to be any protection
>>>>          against an attacker causing everyone else that
>> might be in a
>>>>          queue to be marked not-available, ensuring his
>> call moves to
>>>>          the front of the queue. He only needs to know
>> the AoRs of the
>>>>          callers he might be competing with and send
>> PUBLISH requests
>>>>          with those AoRs in the From header field.
>>>>        - What keeps a new caller from just adding the m=
>> attribute to
>>>>          a new INVITE in order to get the preferential
>> treatment by
>>>>          the network and the callee's UA described in
>> several sections
>>>>          of the document? Was an approach that used a temp-GRUU
>>>>          considered instead? It would not have the
>> property of being
>>>>          as easy to guess as adding an m= URI parameter to an AoR.
>>> As for many mechanisms in the CC draft also here we had to
>>> consider the interworking to the PSTN. There we have only a
>>> very basic CC prioritization indicator in the IAM, saying not
>>> much more than 'this IAM is prioritized for CC'. That's why
>>> the callee's monitor MUST record the From URI from the
>>> initial call, to have the chance to check it against incoming
>>> INVITEs and verify id this INV is in fact for CC. Clarifying
>>> text for this is needed in the draft.
>> That clarifying text needs to capture the scenarios above,
>> and answer the questions. For instance, if there is nothing
>> to keep an attacker from marking everyone else in the queue
>> as not available, the document needs to call that out as a
>> security consideration. (I hope this isn't what the group
>> plans to end with).
> I hope it's more clear now in the draft, if not please indicate.
> 
> 
>>>>    - What keeps this from happening? Adam calls and I
>> reject his call
>>>>      because I'm waiting for another  (I press X and the
>> phone just
>>>>      reports that I'm busy). Adam's phone subscribes for
>>>>      call-completion and gets a NOTIFY of "ready" - his
>> phone calls
>>>>      mine again, forcing me to re-reject him. This repeats until I
>>>>      take my phone off the hook (or engage a global DND)
>> causing me to
>>>>      not be able to receive the call I was waiting for.
>>> If the callee's monitor does not want to enable the caller
>> to make use of the CC service, it will not insert a Call-Info
>> header field with "purpose=call-completion" in the final
>> response message.
>> Where is the text in the document that defines that behavior?
>>> Of course Adam's phone could try to sunscribe for CC at
>> your phone, but in this case your phone simply rejects the
>> subscription, which should not affect your reachability for
>> the call you are waiting for.
>> Similarly, where in the text is this made clear? It is
>> separable from the the scenario above - Adam could write a
>> script to subscribe to every address at an enterprise. What
>> normative text causes all those subscriptions to be rejected?
> I will check this again.
> 
>