RE: [Sipping] Call Completion: In Defense of Explicit Operations

["Francois Audet" <[e-mail]>]

Thanks Adam. That's exactly my feeling.

 

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]] 
> Sent: Sunday, April 08, 2007 08:29
> To: Elwell, John
> Cc: Audet, Francois (SC100:3055); SIPPING WG
> Subject: Re: [Sipping] Call Completion: In Defense of 
> Explicit Operations
> 
> Elwell, John wrote:
> > Francois,
> >
> > Clearly the TISPAN people want more than that.
> >
> >   
> 
> I think we understand that they *want* it to behave that way. 
> What I believe is getting lost is the cost imposed by the 
> requirements as written. In particular, there appears to be 
> no dialog, only a unidirectional declaration of requirements 
> without listening for any feedback.
> 
> To use an analogy: let's imagine that I wanted to buy a car. 
> I could write down the list of features I wanted and then 
> send a representative to the car dealer with that list. Now, 
> imagine if the car dealer explained that they have something 
> on the lot that has all of my features for $25,000, *except* 
> it's not a stick shift -- and that, in fact, a model with 
> those features *and* a stick shift would be such an odd 
> special order that it would add $400,000 to the price of the 
> car because of the need to re-tool the assembly line.
> 
> A sensible representative would take this information back to 
> me and ask whether the additional cost was warranted. Of 
> course, I would probably say, "no."
> 
> An insane representative would, without contacting me, raise 
> a stink about the ridiculous cost for this feature and 
> attempt to stand their ground, eventually imposing an 
> additional $400,000 cost on me.
> 
> What I'd like to know for certain is that TISPAN 
> *understands* the difficulty required to implement this one 
> very small and rarely-used aspect of the feature, and that 
> they have explicitly stated that it is important enough to 
> justify the additional cost it imposes on the solution.
> 
> /a
> 
> >   
> >> -----Original Message-----
> >> From: Francois Audet [mailto:[e-mail]] 
> >> Sent: 07 April 2007 19:39
> >> To: Elwell, John; Adam Roach; SIPPING WG
> >> Subject: RE: [Sipping] Call Completion: In Defense of 
> >> Explicit Operations
> >>
> >> Hi John,
> >>
> >> Do you think that this implementing this feature in
> >> the way Adam and I were alluding to, i.e., where queuing
> >> is handled by the clients but without some of the more
> >> complex "queue management" feature would be acceptable
> >> in those countries?
> >>
> >> That would allow us to have a very simple implemenation
> >> without compromising the semantics of SUBSCRIBE or 
> >> using a separate protocol (BFCP).
> >>
> >>
> >>     
> >>> -----Original Message-----
> >>> From: Elwell, John [mailto:[e-mail]] 
> >>> Sent: Saturday, April 07, 2007 11:29
> >>> To: Audet, Francois (SC100:3055); Adam Roach; SIPPING WG
> >>> Subject: RE: [Sipping] Call Completion: In Defense of 
> >>> Explicit Operations
> >>>
> >>> I know this feature is quite popular in the PSTN residential 
> >>> market in various countries in Europe, particularly Germany 
> >>> and also the UK to some extent. Customers seem prepared to 
> >>> spend a few euro cents for the convenience it gives in a 
> >>> presence-less environment. So I think the operators of those 
> >>> networks want to make sure they don't lose this when they 
> >>> evolve to SIP. Given that in SIP you could do things 
> >>> differently and hopefully better, PSTN interworking would 
> >>> appear to be the essential driver behind the TISPAN 
> >>> requirements, but presumably an important driver in the eyes 
> >>> of the carriers concerned. For the enterprise market I just 
> >>> don't see it as important. We used to have it on PBXs right 
> >>> back in the 70s and 80s and it was popular then, but 
> >>> voicemail has pretty well taken over in the enterprise. I 
> >>> hope this sheds some light.
> >>>
> >>> John
> >>>
> >>>       
> >>>> -----Original Message-----
> >>>> From: Francois Audet [mailto:[e-mail]]
> >>>> Sent: 05 April 2007 23:18
> >>>> To: Adam Roach; SIPPING WG
> >>>> Subject: RE: [Sipping] Call Completion: In Defense of Explicit 
> >>>> Operations
> >>>>
> >>>> Wouldn't it be possible to do this CCBS/CCNR stuff with a simple 
> >>>> dialog package, and ditch this "queue management" mechanism?
> >>>>
> >>>> This seems to me to be a classic case of Engineers-gone-wild.
> >>>>
> >>>> I see this in the poetzl draft:
> >>>>
> >>>>     Completion of Calls on no Reply (CCNR) provides the 
> >>>>         
> >> caller with 
> >>     
> >>>> the
> >>>>     ability to complete a requested call to a callee 
> >>>>         
> >>> without having to
> >>>       
> >>>>     make a new call attempt when the callee becomes not 
> >>>>         
> >> busy after 
> >>     
> >>>>     having initiated an activity.  The CCNR service 
> >>>>         
> >> description is 
> >>     
> >>>>     defined in ETSI EN 301 134 [6]. 
> >>>>
> >>>>     The call completion services provide the capability to queue 
> >>>>     several CCBS/CCNR requests to the same callee on a FIFO 
> >>>>         
> >>> basis. It 
> >>>       
> >>>>     therefore requires functionalities like notifying 
> >>>>         
> >>> changes of queue
> >>>       
> >>>>     states and managing queues.  
> >>>>
> >>>> In other words, we are defining this really complex stuff 
> >>>>         
> >>> just because 
> >>>       
> >>>> it used to work like this in some ETSI standard for PSTN.
> >>>>
> >>>> Is there a better justification than that? What am I missing?
> >>>>
> >>>> Couldn't we handle some basic level of queueing at the endpoints 
> >>>> themselves, and use a simple dialog package, and avoid all 
> >>>>         
> >>> this stuff 
> >>>       
> >>>> that creates all the complexity?
> >>>>
> >>>> This CCBS/CCNR feature is one of the feature that has the most 
> >>>> variation
> >>>>
> >>>> in implementations in PSTN that I know of. To me, picking 
> >>>>         
> >> a really 
> >>     
> >>>> complicated variant and replicating it in SIP (either by 
> >>>>         
> >>> bastardizing 
> >>>       
> >>>> the protocol, or by using an entirely different protocol 
> >>>>         
> >>> altogether) 
> >>>       
> >>>> is not a good idea.
> >>>> My take is
> >>>> that there will be such a small uptake in implementation 
> >>>>         
> >>> that it will 
> >>>       
> >>>> effectively useful only in a few confined environments 
> >>>>         
> >> where the it 
> >>     
> >>>> can be mandated by law.
> >>>>
> >>>> I'd must rather have a simpler easier to implement 
> version of the 
> >>>> service.
> >>>>
> >>>>         
> >>>>> -----Original Message-----
> >>>>> From: Adam Roach [mailto:[e-mail]]
> >>>>> Sent: Thursday, April 05, 2007 12:10
> >>>>> To: SIPPING WG
> >>>>> Subject: [Sipping] Call Completion: In Defense of Explicit
> >>>>>           
> >>>> Operations
> >>>>         
> >>>>> Despite what appeared to be early agreement in the 
> >>>>>           
> >> working group 
> >>     
> >>>>> (and on the MIG mailing list) that we wanted to 
> >>>>>           
> >>> discourage the use 
> >>>       
> >>>>> of SUBSCRIBE and NOTIFY as general purpose RPC 
> >>>>>           
> >>> mechanisms. This is 
> >>>       
> >>>>> the primary objection that I have raised to 
> >>>>> draft-poetzl-sipping-call-completion,
> >>>>> which uses SUBSCRIBE and NOTIFY to manipulate call queue state.
> >>>>>
> >>>>> In the spirit of sending text, I described an alternate set of 
> >>>>> mechanisms in draft-roach-sipping-callcomp-bfcp, which 
> >>>>>           
> >>> performs the 
> >>>       
> >>>>> same task without having implied side effects from the 
> >>>>>           
> >>> creation of a 
> >>>       
> >>>>> subscription.
> >>>>>
> >>>>> I'll further note that the use of SUBSCRIBE to both create a 
> >>>>> subscription and manipulate a call queue falls under the 
> >>>>>           
> >>> category of 
> >>>       
> >>>>> "one operation with two separate effects." We have a very poor 
> >>>>> institutional memory indeed if we cannot recall why 
> >>>>>           
> >> operations of 
> >>     
> >>>>> this nature are Really Bad Ideas (cf. REFER creating a 
> >>>>>           
> >>> subscription; 
> >>>       
> >>>>> REGISTER with call processing upload; and BYE with an 
> >>>>>           
> >>> "Also" header 
> >>>       
> >>>>> field).
> >>>>>
> >>>>> All of this notwithstanding, in Prague, there seemed to 
> >>>>>           
> >>> be a curious 
> >>>       
> >>>>> indifference to pursuing the path laden with such Really 
> >>>>>           
> >>> Bad Ideas. 
> >>>       
> >>>>> I suspect that this indifference is a result of the 
> >>>>>           
> >>> arguments raised 
> >>>       
> >>>>> so far against the mechanism I have proposed, which I have done 
> >>>>> little to refute so far (largely because I believed that 
> >>>>>           
> >>> the merits 
> >>>       
> >>>>> of a system with explicit operations were self-evident 
> >>>>>           
> >>> enough that 
> >>>       
> >>>>> the objections would seem trifling in comparison).
> >>>>>
> >>>>> As far as I can tell, the objections raised so far have 
> >>>>>           
> >>> fallen into 
> >>>       
> >>>>> three primary categories:
> >>>>>
> >>>>>    1. "The use of BFCP is troubling because, in a
> >>>>>           
> >>>> decomposed gateway,
> >>>>         
> >>>>>       the BFCP goes to the Media Gateway, while the
> >>>>>           
> >>>> signaling goes to
> >>>>         
> >>>>>       the Media Gateway Controller."
> >>>>>
> >>>>>       This objection, raised on one of the slides during 
> >>>>>           
> >>> the SIPPING
> >>>       
> >>>>>       meeting on March 23rd as the official reason TISPAN
> >>>>>           
> >>>> rejected the
> >>>>         
> >>>>>       approach, is based on a simple misconception.
> >>>>>
> >>>>>       The BFCP goes wherever the SDP says the BFCP goes. 
> >>>>>           
> >>> In the case 
> >>>       
> >>>>> of
> >>>>>       a decomposed gateway, this could be the Media
> >>>>>           
> >>>> Gateway, the Media
> >>>>         
> >>>>>       Gateway Controller, or any other random
> >>>>>           
> >>>> network-connected server
> >>>>         
> >>>>>       that the Media Gateway Controller wants. I agree that it 
> >>>>> probably
> >>>>>       is most sensible to send it to the Media Gateway
> >>>>>           
> >>>> Controller, and
> >>>>         
> >>>>>       this is trivial to achieve.
> >>>>>
> >>>>>    2. "In the case of PSTN interwork, there is no way to 
> >>>>>           
> >>> guarantee 
> >>>       
> >>>>> that
> >>>>>       the ISUP (or other) signaling from the PSTN side 
> >>>>>           
> >>> lands on the 
> >>>       
> >>>>> same
> >>>>>       gateway that the client has a BFCP connection to."
> >>>>>
> >>>>>       This is true, and it is a relatively difficult
> >>>>>           
> >>>> problem to solve
> >>>>         
> >>>>>       (not impossible, though; I proposed several potential 
> >>>>> solutions in
> >>>>>       San Diego). It is meaningless to raise it in 
> >>>>>           
> >> objection to an
> >>     
> >>>>>       alternate proposal, since it exists in almost
> >>>>>           
> >>>> precisely the same
> >>>>         
> >>>>>       form in draft-poetzl-sipping-call-completion; and 
> >>>>>           
> >>> any solution
> >>>       
> >>>>>       that can be applied to one solution can be applied to
> >>>>>           
> >>>> the other.
> >>>>         
> >>>>>    3. "We don't want to add another protocol."
> >>>>>
> >>>>>       I suspect this argument is the one that is 
> >>>>>           
> >>> receiving the most
> >>>       
> >>>>>       traction, probably because most of the people 
> >>>>>           
> >>> involved in the
> >>>       
> >>>>>       discussion are not familiar with BFCP. The protocol 
> >>>>>           
> >>> itself is 
> >>>       
> >>>>> very
> >>>>>       straightforward and extremely easy to implement. In fact,
> >>>>>       exclusively for the purpose of answering this email (and
> >>>>>       demonstrating this very point), I threw together a BFCP
> >>>>>       implementation sufficient for implementation of the Call
> >>>>>       Completion service described in 
> >>>>> draft-roach-sipping-callcomp-bfcp.
> >>>>>       It took me two hours, and compiles down to less 
> >>>>>           
> >> than 4 kb of
> >>     
> >>>>>       object code on an intel processor. It's attached to
> >>>>>           
> >>>> this message
> >>>>         
> >>>>>       to help the participants in the conversation
> >>>>>           
> >>>> understand just how
> >>>>         
> >>>>>       very little is being added to applications by this
> >>>>>           
> >>>> use of BFCP.
> >>>>         
> >>>>> So, is that it? The first two objections are simply red 
> >>>>>           
> >> herrings, 
> >>     
> >>>>> and the third is based on a misconception regarding the 
> >>>>>           
> >> level of 
> >>     
> >>>>> effort required to implement BFCP. Are we really going to 
> >>>>>           
> >>> down the 
> >>>       
> >>>>> path of doing things incorrectly over what amount to 
> >>>>> misunderstandings?
> >>>>>
> >>>>> /a
> >>>>>
> >>>>>
> >>>>>
> >>>>> P.S. In case anyone wants a more full-featured BFCP stack, I'll 
> >>>>> point to the confiance project on SourceForge, available 
> >>>>>           
> >>> under the 
> >>>       
> >>>>> Academic Freedom License, which is compatible with commercial
> >>>>>           
> >>>> development. See
> >>>>         
> >>>>> http://confiance.sourceforge.net/
> >>>>>
> >>>>>           
> >>>> _______________________________________________
> >>>> Sipping mailing list  
> >>>>         
> >> https://www1.ietf.org/mailman/listinfo/sipping
> >>     
> >>>> This list is for NEW development of the application of SIP Use 
> >>>> [e-mail] for questions on 
> current sip Use 
> >>>> [e-mail] for new developments of core SIP
> >>>>
> >>>>         
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP