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

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: 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
>