It certainly needs to interwork, but can a basic level of interworking be achieved without suspend/resume? There are advantages in lowering the bar for would-be implementations, and also speeding up the process in BLISS for getting an RFC out.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of DRAGE, Keith (Keith) > Sent: 05 August 2008 17:53 > To: Stumer, Peggy (Com US); Huelsemann, Martin; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [BLISS] thoughts on > draft-ietf-bliss-call-completion; sus/res > > 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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
