* 1004 Hutton: Marking
Section 5.6: "Question: The CC must be marked in some way as a CC call
in order for the callee's monitor to know that the CC activation is
being acted upon by the caller's agent. And the marking must include
the original Call-Id to allow correlation with the original call.
Possibilities for a marking are a special URI-parameter on the request
URI or a special header".
We need to make sure it works across intermediate B2BUAs that translate
Call-Ids, so Call-Id should not be the means of correlation (otherwise
it would require intermediate B2BUAs to perform appropriate translations
on this information, but this would not work if different routes were
taken).
This is indeed problematic. In the call-completion design group we call
it "the correlation problem" and no ideal solution has been found.
The current thinking is based on the fact that the PSTN protocols do not
enforce this correlation, that is, the ETSI specification for
call-completion requests does not require the recipient to verify that
the caller has previously made a call to that destination, and indeed,
there may not be enough information in the request to verify it.
(Although the ETSI specification does imply that the originating
exchange should do such verification itself.)
So the suggestion under consideration is to abandon all attempts at
correlation (which we don't seem to be able to do successfully) and
instead warn that the callees' monitor (which receives CC requests)
should beware that illegitimate CC requests could be used for
cyber-stalking, and take appropriate countermeasures.
* 3006 Hutton: m values
Section 4.2: "However, SIP call completion operations MAY carry an 'm'
parameter to label call completion actions as to the original cause of
the failure.
Surely it is not the cause of the failure that is important it is the
flavor of call completion that is being requested (i.e. initiate
ccRecall on caller becoming free or when next used).
We have to define the m values. Each m value corresponds to both a
flavor of initial call failure (which is what causes that code to be
generated) and a flavor of call completion (which is the behavior that
that code elicits).
A fuller description of the meaning, cause, and effect of the m
parameter is in later sections; section 4.2 is meant to be a summary.
In particular, section 5.3 contains this:
The monitor has a method of monitoring the status of the UA(s) and/or
their users to determine when they are "available" for a CC call,
that is, in a suitable state to receive a CC call. In a system with
rich presence information, the presence information may directly
provide this status. In a more restricted system, this determination
MAY depend on the mode of the CC call in question, which is provided
by the 'm' parameter. E.g., a UA is considered available for CCBS
("m=BS") when it is not busy, but a UA is considered available for
CCNR ("m=NR") when it becomes not busy after being busy with an
established call.
* 3007 Hutton: Callbacks
Section 5.1: "The agent can order the UA(s) at which the relevant
calling user is available to generate a CC call to the callee".
The agent can only do this if it is centralised rather than being in the
endpoint that made the original call. So is a reason why the agent may
be located in the server but is it really a requirement for callback to
mature at a different UA to which it was originated. This is possibly
added value that an agent could provide but maybe not something that
should be stated in this draft.
I don't follow this argument. If the agent is integrated into the UAC,
then the agent can trivially "order" the UAC to generate a CC call, the
agent and the UAC being the same device.
* 3008 Hutton: Forking
Section 6: "In this case, the caller's agent forks the SUBSCRIBE to two
destinations, with appropriate Request-Disposition. The first SUBSCRIBE
is to the URI from Call-Info. The second SUBSCRIBE is to the original
request-URI, and reaches the same callee's monitor.
It is not clear to me why the caller's agent would fork the SUBSCRIBE.
Why would it not just send it to the URI from the Call-Info ?
First, beware that the descriptions in section 6 are meant to be an
example, and are simplified versions of the descriptions in section 5.
The relevant text for this issue is in section 5.5:
Additionally,
the caller's agent needs to include the original request-URI in its
set of monitor URIs, because the call may have forked to additional
callees whose responses the caller has not seen. (A SUBSCRIBE to the
request-URI alone is used in cases where the caller's agent has not
received or cannot remember any monitor URI.)
Dale
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
