Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 1009 Retain option

["Worley, Dale R (Dale)" <[e-mail]>]

Given the discussion in
http://www.ietf.org/mail-archive/web/bliss/current/msg01120.html and
http://www.ietf.org/mail-archive/web/bliss/current/msg01128.html,
we've agreed that SIP CC always operates in "service retention" mode.
SIP CC depends on the origin or destination system to terminate the CC
subscription immediately after a failed CC call if the system does not
support service retention.  To document this, we need to make some
wording changes to the draft:

Section 3, item "Retain option" is:

   Retain option: a characteristic of the CC service; if supported, CC
   calls which again encounter a busy callee will not be queued again,
   but the position of the caller's entry in the queue is retained

We need to add some information:

   Retain option: a characteristic of the CC service; if supported, CC
   calls which again encounter a busy callee will not be queued again,
   but the position of the caller's entry in the queue is retained.
   Note that SIP CC always operates with the retain option active; a
   failed CC call does not cause the CC request to lose its position
   in the queue.

At the end of section 4.2 is:

   When the call completion call fails there are two possible options:
   the CC feature has to be activated again, or CC remains activated and
   the original CC request retains its position in the queue (retain
   option), optionally with the possibility to update the subscription.

This needs to be replaced with something like:

   When the call completion call fails, the subscription is not
   terminated and it remains in the queue.  (The monitor's policy may
   change the subscription's position in the queue or otherwise alter
   its priority for being activated again.)  That is, SIP CC always
   operates with the retain option active.  However, if either the
   caller's system or the callee's system does not support the retain
   option, that system can terminate the subscription upon failure of
   the CC call.  This will usually happen only when the endpoint is a
   gateway to an SS7 network and the far SS7 endpoint does not support
   the retain option.  In that situation, the SS7 signaling provides a
   message to the gateway to indicate that the CC request has been
   terminated, and the gateway translates that indication into a
   SUBSCRIBE or NOTIFY (as appropriate) that terminates the CC
   subscription.

In section 5:

   When the monitor discovers that an CC INVITE has arrived containing a
   From-URI of a CECE, it deletes the CECE from the set.  However if
   that INVITE fails, it may cause the creation of another CECE with the
   same From-URI, or if the retain option is supported, the CECE is
   retained in the set.

I think that the correct wording change is to delete this paragraph --
since the retain option is always active, these circumstances cause no
net action.

However, we probably need to include a note something like:

   If a CC INVITE fails, it does not cause the creation of another CECE,
   although the original CECE for this CC operation remains in the set.

In section 7.3 is:

   The call-completion event package provides information about the
   callee's monitor's policy.  In particular, like in the PSTN, the
   "'cc-service-retention" datum gives an indication of the "service
   retention" attribute, which indicates whether the CC request can be
   continued to a later time if the call-completion call fails due to
   the callee's UA(s) being busy.  If the callee's monitor supports the
   service-retention option, the monitor SHOULD include the cc-service-
   retention parameter.

I think this paragraph should be deleted.

In section 9.8 is:

   If the call-completion subscription was successful and the retention
   option is supported at the callee, the NOTIFY MUST contain the "cc-
   service-retention" parameter.

Delete this paragraph.

In section 10 is:

   cc-header = cc-state / cc-service-retention / cc-URI / extension-
   header

Remove cc-service-retention:

   cc-header = cc-state / cc-URI / extension-header

Section 10.2 is:

   10.2.  service-retention

   The service-retention line indicates the support of the retain
   option.  The retain option, if supported at the callee, will maintain
   the entry in the call-completion queue, if a call-completion call has
   failed due to destination busy condition.  If present, this parameter
   indicates that the retain option is supported, otherwise it is not
   supported.  This parameter MAY be present in NOTIFY requests.

   cc-service-retention = "cc-service-retention" HCOLON "true"

Delete this section.

Dale