Hi Dale, In general I am happy with your responses below.
However this did prompt me to have a look at section 6 of -03 (Examples). This shows that the caller UA generates two SUBSCRIBE's using the same Call-Id and the text below the diagram states: "The caller's agent adds to these URIs an 'm' parameter (if possible). In this case, the caller's agent forks the SUBSCRIBE to two destinations, with appropriate Request-Disposition." This I think is a bit strange as I don't think that many UA SIP Stack implementations provide a service to "fork" in this way. Therefore I think we may need a different mechanism to allow the callee to determine that the two subscribes are related. Regards Andy >-----Original Message----- >From: [email protected] [mailto:[email protected]] >On Behalf Of Dale Worley >Sent: 27 February 2009 21:00 >To: BLISS >Subject: [BLISS] Some of Andrew Hutton's concerns >aboutdraft-ietf-bliss-call-completion-03 > >[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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
