From: Jonathan Rosenberg <[EMAIL PROTECTED]> A key part of the mechanism in here is that it focuses on the 'server to server' aspect of the problem. It defines only what would need to flow between domains or between organizations to accomplish this feature between organizations. I think that aspect of it needs to be emphasized. For example, some diagrams which show this, including different models for how the agents can be co-located.
We have attempted to make that clear. For instance, section 5.1 of draft-ietf-bliss-call-completion-02 starts: 5.1. Caller's Call-Completion Agent The call-completion architecture augments each caller's UA (or UAC) which wishes to be able to use the call-completion features with a "call-completion agent". An agent may be an integrated part of the UA, a separate end-system, integrated with a proxy serving the UA, or a function of an application server that provides these services to many UAs. An agent may service more than one UA as a collective group if it is common that a caller or population of users will be shared between the UAs, and especially if the UAs share an AOR. The caller's agent must be capable of performing a number of functions relative to the UA(s). The method by which it does so is outside the scope of this document, but an example method is described in appendix A. ... and then enumerates the needed interactions between the agent and the caller's UA(s). Section 5.2 has similar text about the monitor. Appendixes A and B give outlines of how a simple agent and monitor can be constructed using standard SIP mechanisms. Perhaps I don't see what needs to be elaborated. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
