[Sipping] Call Completion: In Defense of Explicit Operations

[Adam Roach <[e-mail]>]

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