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 protected] [mailto:[email protected]] > Im Auftrag von Kevin P. Fleming > Gesendet: Sonntag, 21. November 2010 18:11 > An: [email protected] > 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 protected] Check us out > at www.digium.com & www.asterisk.org > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
