On 12/27/2010 09:29 AM, [email protected] 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: [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
--
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
