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

["Elwell, John" <[e-mail]>]

Francois,

Clearly the TISPAN people want more than that.

John 

> -----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