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

Hi Kevin,

for me it's okay to remove the example.

What about the example in the last sentence of the next paragraph?

"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"."

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: Kevin P. Fleming [mailto:kpfleming@digium.com]
> Gesendet: Dienstag, 28. Dezember 2010 17:27
> An: Hülsemann, Martin
> Cc: andrew.hutton@siemens-enterprise.com; bliss@ietf.org
> Betreff: Re: AW: [BLISS] WGLC for draft-ietf-bliss-call-completion-07
>
> On 12/27/2010 09:29 AM, Martin.Huelsemann@telekom.de wrote:
> > 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)."
>
> 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.
>
> >
> >
> >
> > Regards, Martin
> >
> >
> >
> >
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] Im
> >> Auftrag von Kevin P. Fleming
> >> Gesendet: Sonntag, 21. November 2010 18:11
> >> An: bliss@ietf.org
> >> 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: kfleming@digium.com Check us out at
> >> www.digium.com&  www.asterisk.org
> >> _______________________________________________
> >> BLISS mailing list
> >> BLISS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/bliss
> >>
>
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> skype: kpfleming | jabber: kfleming@digium.com Check us out
> at www.digium.com & www.asterisk.org
>