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 protected] https://www.ietf.org/mailman/listinfo/bliss
