Hi all, May I ask, is the intention of specifying this feature in order to interwork with this age-old feature in the legacy TDM network, or, do we not consider the age-old CCBS/NR (ISDN) feature and instead define a new, stream-lined call completion type of capability?
In the interest of interworking with legacy networks supporting this feature (it is an important enterprise feature especially in Europe), the suspend/resume procedure should be defined since it is a mandatory procedure when one supports CCBS and/or CCNR. Likewise, IMO, all mandatory ISO/IEC/ECMA PICS items for this supplementary service should be supported/mappable in this SIP draft procedure if there is an intent to interwork with the ISDN feature (which is desirable from a customer's perspective who is migrating to VoIP). If there is no intent to provide the capability to interwork/map this draft feature with the age-old ISDN feature, then one should consider redefining and incorporating such presence and IM alternatives that can actually enhance the age-old feature in many significant ways. Best Regards, Peggy Stumer Siemens Enterprise Com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Huelsemann, Martin Sent: Tuesday, August 05, 2008 8:56 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [BLISS] thoughts on draft-ietf-bliss-call-completion; sus/res > > 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. > > 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. > I agree that at the end of the day there is a interest of the caller as well as of the callee to get a failed call completed as soon as possible. Especially business users set a high value on reducing the average waiting time for their customers when they are busy. They don't want many redials to be started, which could mean their most important customer is the unlucky one who has to wait the longest until his redial succeeds. And if a callee decides that CC is offered to the caller (I think regarding policies we are much more flexible than it was/is in the PSTN), he will also be interested that CC runs in the most effective way. The effectiveness of course is increased if busy callers don't have to be considered for CC recall processing, for which they have to be suspended. Because of this I still think sus/res is an important feature for CC. The question is, is it important enough to describe it in the basic CC draft? Or, like we have talked about in Dublin, is it better to have it in a seperate draft, describing enhanced CC features (needed e.g. for 3GPP)? BR, Martin _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
