Subject: Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07

From: <[email-masked]>
Date: Mon, 27 Dec 2010 16:29:38 +0100

Hi,

I tried to rephrase it:

"The caller's UA sends an INVITE to a request URI. One or more forks of this request reach one or more of the callee's UAs. If the call-completion feature is available, the callee's monitor (note there can be a monitor for each of the callee's UAs) inserts a Call-Info header with its URI and with "purpose=call-completion" in appropriate non-100 provisional or final response messages to the initial INVITE and forwards them to the caller. On receipt of a non-100 provisional or a final response with the indication that the call-completion feature is available, the calling user can invoke the feature. The reason for invoking usually is a situation where the INVITE fails and the resulting dialog(s) are terminated, or a 200 OK to the INVITE was received from some other UA (e.g. the callee's voicemail)."

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von Kevin P. Fleming
> Gesendet: Sonntag, 21. November 2010 18:11
> An: [email-masked]
> Betreff: Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
>
> On 11/09/2010 08:13 PM, Hutton, Andrew wrote:
> > Hi Martin,
> >
> > See below.
> >
> > Regards
> > Andy
> >
> >>> Hi,
> >>>
> >>> The following comments are based on feedback I obtained from some
> >>> developers. Sorry that they are sent last minute.
> >>>
> >>> 1. Section 4.2 "Call-Completion procedures" (1st Para.). The text
> >>> indicates that call completion procedures are not required if the
> >>> callee's UAs return a success response. This is incorrect and in
> >>> conflict with the definition of "Failed Call" in the definitions.
> >>> The requirement for call completion is independent of the
> >>> success/failure of the SIP INVITE request.
> >>>
> >>>
> >>> 2. Section 4.2. (2nd para.) Again it is implied that the call
> >>> completion procedures seems tied to the state of the preceding
> >>> INVITE initiated dialog with the statement "Eventually,
> the INVITE
> >>> fails, or the resulting dialog(s) are terminated".
> However it is not
> >>> the case that the call completion procedures are
> independent of the
> >>> state any proceeding dialog. For example it should be possible to
> >>> initiate call completion even before the original INVITE
> dialog is
> >>> terminated.
> >>
> >> I've tried to combine the 2 paragrapgs:
> >>
> >> "The caller's UA sends an INVITE to a request URI. One or
> more forks
> >> of this request reach one or more of the callee's UAs.
> However there
> >> might be the situation that the calling user considers the
> result of
> >> the call insufficient to satisfy his needs, e.g. the
> INVITE fails and
> >> the resulting dialog(s) are terminated, or the INVITE
> might succeed
> >> at some other UA."
> >>
> >
> > [AndyHutton] - I think it needs to be made clear that the
> SUBSCRIBE for call completion can be initiated whatever the
> state of the original INVITE dialog. For example a 180 or
> 200OK response could be received to the original INVITE
> request and the user decides to invoke call completion before
> terminating the INVITE dialog. Maybe a statement to this
> effect could be made in section 4.2 and/or section 6.2.
>
> I agree. When the UAS sends any response that includes the
> call-completion information, the UAC is free to SUBSCRIBE for
> call completion services.
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> skype: kpfleming | jabber: [email-masked] Check us out
> at www.digium.com & www.asterisk.org
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 28 Dec 2010 10:27:09 -0600

> "The caller's UA sends an INVITE to a request URI. One or more forks of this request reach one or more of the callee's UAs. If the call-completion feature is available, the callee's monitor (note t…

This looks much better to me, all except the last sentence.

I'm not sure we need an example of why a user might wish to invoke call 
completion services at this point in the document; the rationale for 
this entire set of services is spelled out earlier in the document, and 
providing an example like this sometimes results in implementors 
incorrectly assuming that invoking the services as a result of other 
circumstances is not allowed by the RFC.

If we do leave the example in, I'd prefer it to be worded like this, though:

====
Frequently, the call-completion feature will be invoked by the caller 
(by requesting that their UA do so) when the initial INVITE did not 
result in a session being established with the callee. This could occur 
if all of the callee's UAs respond with failure responses (4xx or 5xx 
response codes), or even if one of the callee's UAs responds with a '200 
OK' but that UA does not actually connect the caller to the callee (a 
voicemail system, for example).
====

It isn't possible for 'some other UA' to respond with a 200 OK to the 
INVITE; the only UAs that can respond to the INVITE are those that are 
included in the set of "callee's UAs" as defined earlier in the 
paragraph. Another UA could become involved if one of the callee's UAs 
responds with a 302, but I don't think you want to complicate this text 
with trying to accommodate that example.

>> at www.digium.com&  www.asterisk.org

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org