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 protected]>
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 protected]>
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 protected]>
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 protected]>
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 protected]>
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.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
