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

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

That was not really what I was thinking of, but it does
seems like a reasonable idea.

A simple implemenation would use a dialog package, and
for the people who need this queuing (i.e., TISPAN), then
we could add this call log.

I think Henning might be on to something. If this mechanism
is more useful than just the TISPAN queue management feature,
then people may actually implement it. 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]] 
> Sent: Saturday, April 07, 2007 11:39
> To: Elwell, John
> Cc: Audet, Francois (SC100:3055); 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