-----Ursprüngliche Nachricht-----
Von: Shida Schubert [mailto:[email protected]]
Gesendet: Mittwoch, 15. August 2012 19:16
An: Hülsemann, Martin
Cc: [email protected]; [email protected];
[email protected];
[email protected]; 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, <[email protected]>
<[email protected]> wrote:
Hi Robert,
sorry I somehow missed this mail. Some answers inside.
Regards, Martin
-----Ursprüngliche Nachricht-----
Von: Robert Sparks [mailto:[email protected]]
Gesendet: Dienstag, 21. Februar 2012 16:38
An: Hülsemann, Martin
Cc: [email protected];
[email protected];
[email protected]; Jesske, Roland; [email protected];
[email protected]
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.
