(My apologies for the slow replies, as I've been busy and also had some mail problems due to some new anti-spam system on the Bliss mailing list.)
From: Jonathan Rosenberg <[EMAIL PROTECTED]> Very much related to that, ccbs has an effect of introducing work in one domain (the one of the callee) that primarily (if not exclusively) benefits the other (the one of the caller). This provides an unfortunate negative incentive for implementing this in a callee domain. I think we need to take care to minimize the amount of work required on the callee's side to support this. So for example, I am reluctant to introduce requirements to do things like suspend/resume, as these introduce additional work and state on behalf of the callee's agent. Call-completion can provide value to both the caller and the callee. In the current US PSTN, only the caller is charged, but (I suspect) that's because the carriers make more money charging the caller per-usage than they would by charging potential callees per-month. (Contrast with call waiting, which is charged per-month at the callee's end.) My expectation is that initial CC deployment will be (1) in systems operated by PSTN carriers and gateways to the PSTN, as continuations of their current lines of business, and (2) in PBXs, which will market it as a continuation of the "camp-on" feature. Our goal is to have these various deployment islands interoperate without any further work (especially without work on the part of any transit SIP carriers). Supporting this goal drives some of the more troublesome requirements we have. Once the deployment islands interoperate, we hope to have a critical mass of users so that additional systems will implement CC as a matter of course. What does a calling domain do when it wants to invoke this service and the terminating side doesn't support it. Do we have a recommended 'poor mans' version of this that requires no additional support? i.e., I am aware of implementations that actually periodically send INVITEs. Indeed, doing so may be incentive to properly deploy a sub/not solution to avoid such deluge... No, we've been considering such a recommendation as outside our scope. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
