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

[Adam Roach <[e-mail]>]

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