> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Paul Kyzivat > Sent: 28 July 2008 18:52 > To: Jonathan Rosenberg > Cc: [email protected] > Subject: Re: [BLISS] thoughts on draft-ietf-bliss-call-completion > > Lots of comments below. > > Jonathan Rosenberg wrote: > > 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. > > > > 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. > > While I agree that it is important to consider what the > incentives are > for implementing this stuff, I don't think this should be viewed as > primarily benefiting the caller at the expense of the callee. > At least > not if this is considered an *optional* feature at the callee. > > A callee will offer this capability if he considers it advantageous - > namely if he considers the incoming calls to his benefit, and missing > them to be a loss. If the callee doesn't view incoming calls > that way he > is free to omit the feature. [JRE] Or he may use some other capability, like call queueing / call waiting.
> > To the caller who wants to get through, there are various potential > solutions. One is to simply repeatedly reattempt the call. > This can be > done manually by the UAC user, but it can also be implemented > in the UAC > itself. > > Why isn't *that* a sufficient solution? Several reasons: > 1) it increases signaling load on the network > 2) there is no "fairness" - no guarantee that the first to try > is the first to get through, or even that the caller the > callee would most like to talk to gets through first. > 3) the calling user has to stand by awaiting success. There > is no opportunity to do other things and be alerted when > the call can get through. > > Who benefits varies for these: > 1) the network carriers benefit. This may be incentive enough. > 2) using repeat dialing, the UA that can generate call attempts most > frequently has the highest probablility of getting > through quickly. > The has the potential to aggrevate (1). (A clever UAC may even > initiate additional INVITEs before the earlier one has had a > response.) Its not clear if fairness for callers is of benefit > to the callee or not - perhaps if some callers get mad for having > had to wait a long time. To be effective, the queuing must > prevent people from getting through without entering the queue > so long as a queue exists. But that locks out callers that don't > have support for the queuing mechanism. That makes rollout of > the queuing support problematic. > Additional benefit can accrue to the callee if he is given the > opportunity to cherry pick the queue - choosing how it is > ordered. > 3) this clearly is benefit to the caller. The benefit to the callee > is a happier caller. For instance, this might make long call wait > times be more palatable. > > IMO the "caller" call completion service and the "callee" call > completion service are logically separate. As a caller, I just want a > way to complete my calls, and I want it regardless of what > capabilities > the callee does or doesn't have. So the UAC should have a bag > of tricks > that it can use to accomplish call completion. Repeat dialing and the > ccna/ccbs queing are two tricks in the bag. There may be other > possibilities. (E.g. probing with OPTIONS checking for busy.) > > The "callee" call completion service is probably the callee > half of the > queuing mechanism, offered as an option to callers that > support it. It > is there if and when it suits the callee to offer it. [JRE] For PSTN use, the callee generally does not have a say - it is up to the network provider whether it operates CCBS on callee's behalf or not. John _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
