[These are keyed to the issue identifiers in the list of open issues we keep on the BLISS-CC mailing list.]
> * 1003 Hutton: CC URI > > "Hutton, Andrew" <[email protected]> > Section 5.6: "Question: Should the callee's monitor supply a URI which > should be used in the CC call?" > I think it should. This text has been moved to section 5.7 of -03. The current text is: "The notification MAY also contain also a URI which should be used in the CC call. In practice, this may be the AOR of the callee." I think we should change the MAY to SHOULD. > * 1005 Hutton: Failure > > "Hutton, Andrew" <[email protected]> > 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 In section 5.5 of -03, the text is: Note that from the SIP point of view, the INVITE may be successful, but from the user's point of view, the call may be unsuccessful. E.g., the call may have connected to the callee's voicemail, which would return a 200 status to the INVITE but from the caller's point of view is "no reply". I think this satisfies your concern. > * 3004 Hutton: Failure of initial call > > "Hutton, Andrew" <[email protected]> > 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. > * 3005 Hutton: Queue > > "Hutton, Andrew" <[email protected]> > 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"? It does appear that these definitions need to be revised so that "failed" is not seen as restrictive. > * 1006 Hutton: 180 Ringing > > "Hutton, Andrew" <[email protected]> > 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. That is a good point, and I think that the group agreed with it when you made it, but the -03 text does not reflect that consensus. I will propose some edits about this. > * 3002 Hutton: Location of agents > > "Hutton, Andrew" <[email protected]>: > 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. Yes, I think that sentence in the Abstract needs to be revised. The idea we want to convey is that the agent/monitor can be in the UAs themselves, or be in "servers" that are presumably involved in the endpoint's networks. > * 3003 Hutton: Appendixes > > "Hutton, Andrew" <[email protected]> > 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. > * 3009 Hutton: Example > > "Hutton, Andrew" <[email protected]> > 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 ? We could write such an example, but I don't think that it would add much to the document. The call flow example in section 6 of -03 shows what behavior would look like if the agent/monitor were integrated into the UAs. Indeed, the point of the Appendixes is to show that one can separate the agent/monitor from the UAs and still use SIP signaling to coordinate the agent/monitor with their respective UAs. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
