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

[Robert Sparks <[e-mail]>]

On 8/16/12 4:09 AM, [e-mail] wrote:
> Thanks Shida.
>
> I think you describe exactly the underlying model, only we have been careless and have not described this aspect proper in the draft. The presence instance is initiated together with the creation of the call-completion entity.
>
> If we can agree on this model, I will cath up on this and add this model to the draft.
>
>
> Regards, Martin
That will help - thanks.
I'll put the draft into revised-id needed.

RjS
>
>
>
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Shida Schubert [mailto:[e-mail]]
>> Gesendet: Mittwoch, 15. August 2012 19:16
>> An: Hülsemann, Martin
>> Cc: [e-mail]; [e-mail];
>> [e-mail];
>> [e-mail]; Jesske, Roland
>> Betreff: Re: [BLISS] AD review: draft-ietf-bliss-call-completion-14
>>
>>
>> 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.
>>>
>>>
>>