Subject: [BLISS] Comments and Question on draft-ietf-bliss-call-completion-02.txt

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 13 Nov 2008 14:57:57 +0000

Hi All,

I have a few comments and questions relating to
draft-ietf-bliss-call-completion-02.txt.

Abstract: "implementations at the caller's and callee's endpoints
cooperate to place the caller's request for call completion into a queue
at the callee's endpoint".
I think the draft gives some mixed messages regarding the options for
where the caller's and callee's agent may be located and some
clarification is needed. Maybe the abstract should make it clear that
the document does not specify the location of the agents.

Introduction: "As a proof-of-concept, simple agents and monitors can be
devised that interact with users and UAs entirely through standard SIP
mechanisms [RFC3265], [RFC4235] and [RFC3515], as described in the
Appendixes".
The appendixes do I think add to the confusion regarding where the
caller's agent is located as it describes features codes being used to
invoke the service which seems at odd's with the abstract.

Terminology: "CC request: (1) the indication by the caller to the
caller's agent that the caller desires CC for a failed original call". 
Why does there have to be a failed original call should it be possible
to initiate a CC request with no previous call or even if the previous
call was "successful". The concept of "failure" really only applies to
the user and cannot be specified.

Terminology: "Call-completion queue: a buffer at the callee' monitor
which stores incoming calls which have failed or may have failed"
Presumably this means that it is left to the implementation to decide
what failed means and that potentially all calls will be in this "queue"
?

Section 4.2: "However, SIP call completion operations MAY carry an 'm'
parameter to label call completion actions as to the original cause of
the failure. 
Surely it is not the cause of the failure that is important it is the
flavor of call completion that is being requested (i.e. initiate
ccRecall on caller becoming free or when next used).

Section 5.1: "The agent can order the UA(s) at which the relevant
calling user is available to generate a CC call to the callee".
The agent can only do this if it is centralised rather than being in the
endpoint that made the original call. So is a reason why the agent may
be located in the server but is it really a requirement for callback to
mature at a different UA to which it was originated. This is possibly
added value that an agent could provide but maybe not something that
should be stated in this draft.

Section 5.4: "Question: Should the specification of the original call be
done in the SUBSCRIBE body rather than in an event-param?".
I think I would vote for using the event-param.

Section 5.6: "Question: Should the callee's monitor supply a URI which
should be used in the CC call?"
I think it should.

Section 5.6: "Question: The CC must be marked in some way as a CC call
in order for the callee's monitor to know that the CC activation is
being acted upon by the caller's agent.  And the marking must include
the original Call-Id to allow correlation with the original call.
Possibilities for a marking are a special URI-parameter on the request
URI or a special header".  
We need to make sure it works across intermediate B2BUAs that translate
Call-Ids, so Call-Id should not be the means of correlation (otherwise
it would require intermediate B2BUAs to perform appropriate translations
on this information, but this would not work if different routes were
taken).

Section 5.6: "Can a call appear to succeed from the monitor's point of
view but fail from the calling user's point of view?"
It is not clear to me what constitutes success from the monitor's point
of view. Does just getting back a 180 constitute success? If so, from
the caller's perspective the call could still fail to be answered, so it
would be up to the caller to invoke CCNR (again) if that is what he
wants

Section 6: I think that the URI of the monitor (i.e. Call-Info) should
be included also in a 180 Ringing because the caller may need to know
that callback is available before deciding to give up on the ringing
call.

Section 6: "In this case, the caller's agent forks the SUBSCRIBE to two
destinations, with appropriate Request-Disposition.  The first SUBSCRIBE
is to the URI from Call-Info.  The second SUBSCRIBE is to the original
request-URI, and reaches the same callee's monitor.
It is not clear to me why the caller's agent would fork the SUBSCRIBE.
Why would it not just send it to the URI from the Call-Info ?

Appendix A.  "Example Caller's Agent". 
This is an example of using a feature code to invoke the feature from
the "UA" would it be possible to also include an example where the agent
is in the UA ?

Regards
Andy
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss