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

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

Henning,

I am not sure what you have in mind or how it caters for the so-called
queueing requirement from TISPAN.

John 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]] 
> Sent: 07 April 2007 19:39
> To: Elwell, John
> Cc: Francois Audet; Adam Roach; SIPPING WG
> Subject: Re: [Sipping] Call Completion: In Defense of 
> Explicit Operations
> 
> This seems like a special case of a call log handler, which might be  
> useful beyond CCNR. Why not simply subscribe to a call log event  
> package (to be defined) and let the UA manage the call backs? That  
> way, you can do call backs for calls placed from other devices or  
> even previously completed calls, just like people routinely 
> dial from  
> their "recent calls" list.
> 
> I don't know if Francois was referring to the same thing as 
> "a simple  
> dialog package".
> 
> Henning
> 
> On Apr 7, 2007, at 2:28 PM, Elwell, John wrote:
> 
> > 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
> 

_______________________________________________
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