Reading the BLISS charter, I would have said that this issue should have been included in the work even if it is not included in the the minimum baseline UA requirements.
"The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks including non-centralized environments, and for the desire to work across domain boundaries and to interwork with the PSTN, when applicable. The focus will not be on rigorous definition of what the specific feature is and exactly how it works. Rather, the focus will be on documenting the variations that exist in the wild sharing common interop problems, figuring out a minimum baseline requirement for a UA and servers (minimum set of primitives etc.), defining minimum levels of functionality and functional primitives required to realize a broad class of related features, and on interoperating with other elements which might implement one of those features in different ways." What I am detecting at the moment is that participants are proposing to exclude it because they think the cost of solution outweights the usage, but that they are failing to take into account the need to interwork. Regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Stumer, Peggy (Com US) > Sent: Tuesday, August 05, 2008 3:39 PM > To: Huelsemann, Martin; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [BLISS] thoughts on > draft-ietf-bliss-call-completion; sus/res > > 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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
