Subject: [BLISS] More comments on draft-ietf-bliss-call-completion-03

From: "Dale Worley" <[email-masked]>
Date: Sun, 01 Mar 2009 15:53:33 -0500

* 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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 03 Mar 2009 14:45:05 +0000

Hi Dale,

A couple of comments below.

Regards
Andy

>-----Original Message-----
>From: Dale Worley [mailto:[email-masked]] 
>Sent: 01 March 2009 20:54
>To: BLISS
>Cc: Hutton, Andrew
>Subject: More comments on draft-ietf-bliss-call-completion-03
>
>* 1004  Hutton: Marking
>

[AndyH] - The text in what is now in section 5.2. of -03 when it states
various things that the callers agent "can" do but if I understand the
text correctly these are all outside the scope of the document. However
whether the agent can do these things or not depends on the architecture
of the solution (i.e. where the caller's agent is located) so I think it
is best just not to mention the things that the agent "can" do but are
outside the scope of the document as it just complicates the draft.

>   received or cannot remember any monitor URI.)

[AndyH] - This relates to me previous message on the list I am not sure
that a SIP UA implementation will be able to "fork" the request as it is
really not a proxy and probably does not have the capability within it's
SIP stack to do this. I think we should try to remove this requirement
for the UA to "fork" the request.

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 06 Mar 2009 16:01:07 -0500

> outside the scope of the document as it just complicates the draft.

It's out of scope *how* the agent does these things, but it is a
requirement on the agent that it *can* do them.  My goal for that
section is to notify implementors as to what the agent must be able to
do.  Conversely, having enumerated the necessary capabilities of the
agent, the reader can verify that the defined procedures later in the
document do not require any further capabilities.  Otherwise, the
implementor will have to comb through the procedures to develop his own
list of agent<-->UAC facilities.

Dale