Subject: [BLISS] Updated open issues list for draft-ietf-bliss-call-completion-05

From: "Dale Worley" <[email-masked]>
Date: Sun, 06 Dec 2009 15:53:05 -0500

The new -05 version of draft-ietf-bliss-call-completion moves things
along considerably.  I've updated the open-issues list (excepting the
purely editorial items) and appended it to this message.  I'll follow up
with fuller discussion of the open items.

Dale
------------------------------------------------------------------------
[Open issues list, annotated and updated based on the -05 draft.  New
text is indented.]

Now that we are close to completion on
draft-ietf-bliss-call-completion, I am compiling a comprehensive list
of open issues.  The list is divided into three sections, which need
to be tackled in order:  "Substantial" issues which involve the
sequence of operations or dataflow among the participants, "Technical"
issues like the particular format of headers, and "Editorial" issues
which are entirely about how the document is written.  The issues are
assigned numbers as we insert them, starting at 1001, 2001, or 3001,
depending on the group that it was initially inserted in.

Status of issues (in my opinion):

    Substantial
	1001 resolved
	1002 resolved
	1003 open
	1004 resolved
	1005 resolved
	1006 resolved
	1007 resolved
	1008 open
	1009 open
	1010 open
	1011 open
    Technical
	2001 resolved
	2002 resolved
	2003 resolved
	2004 open

** Substantial

* 1001  Do we need to correlate a CC SUBSCRIBE with its original INVITE?

Do we need to correlate a CC SUBSCRIBE with its original INVITE as a
security mechanism?

    We have decided that since the PSTN CC mechanism does not verify
    that the CC request comes from a phone that previously made a call
    to the destination, SIP CC will not attempt to do so.

* 1002  Describe use of dialog event package as a fallback strategy

I'm marking this as a substantial change, as we seem to intend to
include the fallback as an integral part of the CC mechanism, even if
it is technically separate.  There may need to be a discussion as to
how to structure the I-Ds/RFCs...

We also should think about interoperation, where both techniques are
used together.

    This is taken care of by section 4.3.

* 1003  Hutton: CC URI

"Hutton, Andrew" <[email-masked]>
Section 5.6: "Question: Should the callee's monitor supply a URI which
should be used in the CC call?"
I think it should.

[Responded to.  Proposed that MAY->SHOULD in section 5.7:  The
notification MAY also contain also a URI which should be used in the
CC call.  Text change proposed.]

    The text in question is now in 7.3:

    The notification MAY also contain a URI which should be used for
    suspension requestst.

    Should we change this to SHOULD?

* 1004  Hutton: Marking

"Hutton, Andrew" <[email-masked]>
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).

[Replied to.  This is part of the "correlation problem", 1001.]

    As previously, CC recalls are marked with "m=XX" in the
    request-URI.  And we have decided to not implement correlation, so
    that original call Call-ID does not need to be carried.

* 1005  Hutton: Failure

"Hutton, Andrew" <[email-masked]>
Section 5.6: "Can a call appear to succeed from the monitor's point of
view but fail from the calling user's point of view?"
It is not clear to me what constitutes success from the monitor's point
of view. Does just getting back a 180 constitute success? If so, from
the caller's perspective the call could still fail to be answered, so it
would be up to the caller to invoke CCNR (again) if that is what he
wants

[section 5.5 of -03 seems to cover this]

    See the 4th para of 4.2:

    The calling user indicates to the caller's agent that he wishes to
    invoke call-completion services on the recent call.  Note that from
    the SIP point of view, the INVITE may be successful, but from the
    user's point of view, the call may be unsuccessful.  E.g., the call
    may have connected to the callee's voicemail, which would return a
    200 status to the INVITE but from the caller's point of view is "no
    reply".

* 1006  Hutton: 180 Ringing

"Hutton, Andrew" <[email-masked]>
Section 6: I think that the URI of the monitor (i.e. Call-Info) should
be included also in a 180 Ringing because the caller may need to know
that callback is available before deciding to give up on the ringing
call.

[Responded to.  I think there is a consensus for this change, but -03
doesn't include it.  Text change proposed.]

    This has been incorporated by stating that the Call-Info header should
    be added to both provisional and final responses.  This change is in a
    number of places in the text; search for 'provisional'.

* 1007  Suspend/resume

OK, what was the consensus regarding suspend/resume procedures?

    Suspend/resume is done via PUBLISH.  See section 5 para 7 et seq.

* 1008  Absence of correlation requries elucidation of security issues

If CC does not enforce correlation with incoming calls, we need to
document how implementations should ensure privacy.

    Section 11 (Security Considerations) needs to be updated to take care
    of this.  The text in -05 still describes CC correlation.

* 1009  Retain option

We need to establish how the retain option is handled.

    I think we still need to flesh out how retain is implemented.  My
    impression is that in the PSTN, the two endpoints negotiate
    whether retain will be used, and we need to duplicate that
    process.

* 1010  Effect of non-correlation on the event model

In principle, each SUBSCRIBE that arrives identifies some particular
state data.  This is problematic in CC, because we really want to have
each SUBSCRIBE (or rather, each group of SUBSCRIBEs with the same
Call-Id) to identify one "state" (whether that CC request is chosen
for callback), even if there is no overt difference between two
SUBSCRIBEs (other than a different Call-Id).  If we are doing
correlation, then each SUBSCRIBE can be modeled as monitoring the
state associated with the original call.  But if we do not do
correlation, SUBSCRIBEs do not map into original calls, even in
theory, and we need to construct a new event subscription model.  This
is probably not difficult, but does need to be done.

    Section 5 discusses this.  I think this has not been fully
    clarified, though, as section 5 says that the SUBSCRIBE is
    "addressed to the managed URI" but that the CECE it refers to is
    "identified by the request URI".

* 1011  Forking of the CC SUBSCRIBE to multiple destinations

Andrew Hutton notes that the SIP stack in some UAs may not be able to
send several SUBSCRIBEs to several destinations using the same
Call-Id.

The answer is that it is not *necessary* for these SUBSCRIBEs to be
forks of the same transaction.  If they have separate Call-Ids, there
are certain inefficiencies but no loss of functionality:  A monitor
might receive forks of more than one of these SUBSCRIBEs and not
realize that they are merged requests, and will establish multiple
queue elements.  But only one of these queue elements will be selected
for callback.

    We need to add some text to section 6.2 about this.  (I think in older
    versions there was a requirement that the same Call-Id should be
    used.)  This shouldn't be difficult to address as it is actually an
    efficiency measure.

** Technical

* 2001  Hutton: SUBSCRIBE

"Hutton, Andrew" <[email-masked]>
Section 5.4: "Question: Should the specification of the original call be
done in the SUBSCRIBE body rather than in an event-param?".
I think I would vote for using the event-param.

    This is (probably) obviated by the decision to not do call correlation.

* 2002  Timers

The protocol timers still need to be specified.  See the note in
section 7.6.

    The discussion of timers is now in 9.4 and 9.6, and appears to be
    sufficient.  (The timer specifications needed for CC are minimal.)

* 2003  Rate of Notifications

John has the following question regarding section 7.11 and the rate of
notifications:

   The call completion service typically involves a single notification
   per notifier and per subscription but MAY involve several
   notifications separated by a call completion call that failed due to
   a busy call completion target.  Typically, notifications will be
   separated by at least tens of seconds.  Notifiers SHOULD NOT generate
   more than two notifications in any ten-second interval.

   John: A common situation might be a successful subscription to CCBS,
   resulting in an initial NOTIFY "queued", and then the callee becomes
   free a couple seconds later, resulting a second NOTIFY "ready".
   Similarly following resume.  It does not seem reasonable to suppress
   or delay that second NOTIFY.  I think the recommendation is too
   severe.  Perhaps NOTIFYs in response to SUBSCRIBEs need to be
   excluded from this.

   Dale: I'm quite willing to modify this prescription.  I only included
   it because RFC 3265 says that there must be a prescription; I believe
   that if a monitor generate NOTIFYs only in response to relevant
   events, its NOTIFY rate will be low enough.

   However each of in the two cases you mention, there are only two
   NOTIFYs, so the prescription as stated cannot be violation, since a
   violation requires 3 NOTIFYs.

Regarding -05:
   The current 9.1 modifies that restriction to "SHOULD NOT generate
   more than { three } notifications...".  9.1 also includes a
   better explanation of the consequences of this rule.  I think the
   increase in the limit is to allow transitions from queued to
   ready to more often be sent promptly, which would reduce the
   problem John identifies.

* 2004 Failure codes for CC SUBSCRIBE

[New for -05.]  The text is inconsistent regarding the failure code
for a CC SUBSCRIBE for a call that the monitor has no record of:  7.2
says 404, 9.7 says 481.  It seems to me that 404 should be reserved
for SUBSCRIBEs for which the monitor cannot identify the managed AOR,
and 481 used for SUBSCRIBEs that designate a proper AOR but not a
known call for that AOR.