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

From: "Elwell, John" <[email-masked]>
Date: Sat, 07 Apr 2007 19:28:47 +0100

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:[email-masked]] 
> 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:[email-masked]] 
> > 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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 7 Apr 2007 14:38:59 -0400

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:

>> This seems to me to be a cFrom [email-masked] Sat Apr 07 14:39:13 2007
From: Henning Schulzrinne <[email-masked]>
Subject: Re: [Sipping] Call Completion: In Defense of Explicit Operations
Date: Sat, 7 Apr 2007 14:38:59 -0400
To: "Elwell, John" <[email-masked]>
Cc: SIPPING WG <[email-masked]>, Francois Audet <[email-masked]>,
	Adam Roach <[email-masked]>

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:

>> Gatewlassic case of Engineers-gone-wild.
>>

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 7 Apr 2007 13:38:47 -0500

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

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Saturday, April 07, 2007 11:29
> To: Audet, Francois (SC100:3055); Adam Roach; SIPPING WG
> 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
> 
> > Subject: RE: [Sipping] Call Completion: In Defense of Explicit 
> > Operations
> > 
> >     Completion of Calls on no Reply (CCNR) provides the caller with 
> > the
> >     ability to complete a requested call to a callee 
> without having to
> >     The call completion services provide the capabil)
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l37IcnF18853; Sat, 7 Apr 2007 18:38:49 GMT
Content-class: urn:content-classes:message
Subject: RE: [Sipping] Call Completion: In Defense of Explicit Operations
Date: Sat, 7 Apr 2007 13:38:47 -0500
From: "Francois Audet" <[email-masked]>
To: "Elwell, John" <[email-masked]>, "Adam Roach" <[email-masked]>, 
	"SIPPING WG" <[email-masked]>
Cc: 

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

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Saturday, April 07, 2007 11:29
> To: Audet, Francois (SC100:3055); Adam Roach; SIPPING WG
> 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
> 
> > Subject: RE: [Sipping] Call Completion: In Defense of Explicit 
> > Operations
> > 
> >     Completion of Calls on no Reply (CCNR) provides the caller with 
> > the
> >     ability to complete a requested call to a callee 
> without having to
> >     therefore requires functionalities like notifying 
> changes of queue
> > it used to work like this in some ETSI standard for PSTN.
> > 
> > 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
> > 
> > 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
> > effectively useful only in a few confined environments where the it 
> > can be mandated by law.
> > 
> > > 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,
> > > 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.
> > > 
> 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).
> > > 
> > >       The BFCP goes wherever the SDP says the BFCP goes. 
> In the case 
> > > of
> > >       that the Media Gity to queue 
> >     therefore requires functionalities like notifying 
> changes of queue
> > it used to work like this in some ETSI standard for PSTN.
> > 
> > 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
> > 
> > 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
> > effectively useful only in a few confined environments where the it 
> > can be mandated by law.
> > 
> > > 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,
> > > 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.
> > > 
> 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).
> > > 
> > >       The BFCP goes wherever the SDP says the BFCP goes. 
> In the case 
> > > of
> > >       that the Media Gateway Controller wants. I agree that it 
> > > probably
> guarantee 
> > > that
> > >       the ISUP (or other) signaling from the PSTN side 
> lands on the 
> > > same
> itself is 
> > > very
> > > 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
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 

ateway Controller wants. I agree that it 
> > > probably
> guarantee 
> > > that
> > >       the ISUP (or other) signaling from the PSTN side 
> lands on the 
> > > same
> itself is 
> > > very
> > > 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
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
>

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 7 Apr 2007 14:23:32 -0500

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. 

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Saturday, April 07, 2007 11:39
> To: Elwell, John
> Cc: Audet, Francois (SC100:3055); Adam Roach; SIPPING WG
> 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
> 
> > various countries in Europe, particularly Germany and also 
> the UK to 
> > some extent. Customers seem prepared to spend a few euro 
> cents for 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 
> 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
> >
> caller with 
> without having 
> >> to
> >>     therefore requires functionalities like notifying changes of 
> >> queue
> >> In other words, we are defining this really complex stuff just 
> >> because it used to work like this in some ETSI standard for PSTN.
> >>
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping