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

From: "Elwell, John" <[email-masked]>
Date: Sat, 07 Apr 2007 20:35:21 +0100

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:[email-masked]] 
> 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:[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
> 

_______________________________________________
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 18:08:32 -0400

John,

I can't say I fully understand all the requirements, but here's what  
I had in mind:

Each UA subscribes to the call log for its AOR, presumably via  
incremental updates and maybe with some time limit ("I'm just back  
from vacation. Only give me calls that arrived earlier today, not  
three weeks ago."). Each time-stamped call is marked with its  
completion status, such as 'no response', 'busy', 'outgoing', etc.,  
just like you'd find on most cell phones today. When a UA becomes  
available again, e.g., after busy or being out of the office, the UA  
can easily reconstruct the "queue" of missed calls and dial any one  
of them, in whatever order it chooses. Since it has the complete  
list, it can easily determine whether some other UA for the same AOR  
has already returned a call. There doesn't seem to be a need to  
manage the queue on the proxy.

Being able to return calls from other devices seems to be a nice  
feature; naturally, web call logs do most of that today, but they are  
a bit harder to manage.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Apr 2007 08:55:14 -0400

Henning,

I really like the kind of service you are suggesting. I'd like to see it 
be available. Its the kind of thing that can make a sip-based service be 
better than a traditional service.

Of course it is not an *exact* replacement for the traditional call 
completion service(s), or even a very close one. Whether that is 
important will depend on the customers involved. For someone buying a 
replacement system, the need to avoid retraining a bunch of users may be 
important. (But probably not as important as the people making the 
buying decision think it is.)

My impression is that a key requirement is for interop with a pstn 
service that contains an implementation with queuing. That constrains 
the set of solutions.

IMO the big but unconsidered issue is providing some reasonable user 
experience for the caller regardless of the capabilities of the callee. 
No matter what is decided here, not all callees will support it. As much 
as IMS might like to think they will have a closed system, they won't. 
Calls will be made to callees on the PSTN in different countries that 
follow various standards, to cell phones from various providers, to an 
assortment of PBXs, gateways to sip systems, to Skype, etc. If I have 
trouble getting through with a call, and want help completing it, I want 
that help regardless of who I am trying to call. A really simple 
solution, such as one that simply repeatedly redials, will be better 
than a queuing system if it works for more callees. A system that 
separates caller support from callee support, and is capable of using 
any of a variety of techniques based on what the callee supports, would 
be even better.

	Paul

Henning Schulzrinne wrote:
> John,
> 
> I can't say I fully understand all the requirements, but here's what I 
> had in mind:
> 
> incremental updates and maybe with some time limit ("I'm just back from 
> vacation. Only give me calls that arrived earlier today, not three weeks 
> ago."). Each time-stamped call is marked with its completion status, 
> such as 'no response', 'busy', 'outgoing', etc., just like you'd find on 
> most cell phones today. When a UA becomes available again, e.g., after 
> busy or being out of the office, the UA can easily reconstruct the 
> "queue" of missed calls and dial any one of them, in whatever order it 
> chooses. Since it has the complete list, it can easily determine whether 
> some other UA for the same AOR has already returned a call. There 
> doesn't seem to be a need to manage the queue on the proxy.
> 
> feature; naturally, web call logs do most of that today, but they are a 
> bit harder to manage.
> 
> Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Apr 2007 09:06:43 -0400

On Apr 9, 2007, at 8:55 AM, Paul Kyzivat wrote:

> important will depend on the customers involved. For someone buying  
> a replacement system, the need to avoid retraining a bunch of users  
> may be important. (But probably not as important as the people  
> making the buying decision think it is.)

Ignoring the part of where this is implemented, I'm curious (simply  
because I have never experienced the original service...) as to how  
the user experience would differ. I'm envisioning an automated mode  
that emulates the call-back style mode CCNR seems to imply, not  
necessarily an explicit call log listing with "click to dial"  
functionality.

In addition to the basic call log, there would need to be an  
indicator (caller preference?) to be called back, which can be easily  
reflected into the call log.

A separable issue is whether a "network"-based solution will lead to  
more widespread availability.

> service that contains an implementation with queuing. That  
> constrains the set of solutions.
>
> IMO the big but unconsidered issue is providing some reasonable  
> user experience for the caller regardless of the capabilities of  
> the callee. No matter what is decided here, not all callees will  
> support it. As much as IMS might like to think they will have a  
> closed system, they won't. Calls will be made to callees on the  
> PSTN in different countries that follow various standards, to cell  
> phones from various providers, to an assortment of PBXs, gateways  
> to sip systems, to Skype, etc. If I have trouble getting through  
> with a call, and want help completing it, I want that help  
> regardless of who I am trying to call. A really simple solution,  
> such as one that simply repeatedly redials, will be better than a  
> queuing system if it works for more callees. A system that  
> separates caller support from callee support, and is capable of  
> using any of a variety of techniques based on what the callee  
> supports, would be even better.
>
> 	Paul
>
> H

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Apr 2007 09:45:04 -0400

Henning Schulzrinne wrote:
>> replacement system, the need to avoid retraining a bunch of users may 
>> be important. (But probably not as important as the people making the 
> because I have never experienced the original service...) as to how the 
> user experience would differ. I'm envisioning an automated mode that 
> emulates the call-back style mode CCNR seems to imply, not necessarily 
> an explicit call log listing with "click to dial" functionality.

If I understood what you were proposing, it would be the *callee* that 
would initiate the callback, based on the call log, whereas CCNR has the 
*caller* initiate the callback.

There are several differences in user experience here:
- with ccnr, the caller is alerted first. If not present,
   the attempt won't occur. With a callee initiation based
   on the call log, the callback will probably happen without
   knowledge of availability of the caller. So it may go
   unanswered.
- if the caller has restrictions on who he can call,
   the callback attempt may be blocked. This wouldn't
   happen if the caller did the initiation.
- the caller probably gets the bill for the call.

	Paul

> In addition to the basic call log, there would need to be an indicator 
> (caller preference?) to be called back, which can be easily reflected 
> into the call log.
> 
>> experience for the caller regardless of the capabilities of the 
>> callee. No matter what is decided here, not all callees will support 
>> it. As much as IMS might like to think they will have a closed system, 
>> they won't. Calls will be made to callees on the PSTN in different 
>> countries that follow various standards, to cell phones from various 
>> providers, to an assortment of PBXs, gateways to sip systems, to 
>> Skype, etc. If I have trouble getting through with a call, and want 
>> help completing it, I want that help regardless of who I am trying to 
>> call. A really simple solution, such as one that simply repeatedly 
>> redials, will be better than a queuing system if it works for more 
>> callees. A system that separates caller support from callee support, 
>> and is capable of using any of a variety of techniques based on what 
>> the callee supports, would be even better.
>>
>>     Paul
>>
>> H
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Apr 2007 10:23:52 -0400

On Apr 9, 2007, at 9:45 AM, Paul Kyzivat wrote:

>>> Of course it is not an *exact* replacement for the traditional  
>>> call completion service(s), or even a very close one. Whether  
>>> that is important will depend on the customers involved. For  
>>> someone buying a replacement system, the need to avoid retraining  
>>> a bunch of users may be important. (But probably not as important  
>>> as the people making the buying decision think it is.)
>> Ignoring the part of where this is implemented, I'm curious  
>> (simply because I have never experienced the original service...)  
>> as to how the user experience would differ. I'm envisioning an  
>> automated mode that emulates the call-back style mode CCNR seems  
>> to imply, not necessarily an explicit call log listing with "click  
>> to dial" functionality.
>
> If I understood what you were proposing, it would be the *callee*  
> that would initiate the callback, based on the call log, whereas  
> CCNR has the *caller* initiate the callback.
>

This sounds like presence, possibly staged in some "queued" order.  
Does the caller get to choose "dial now or abandon"?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Apr 2007 11:18:04 -0400

Henning Schulzrinne wrote:
>> would initiate the callback, based on the call log, whereas CCNR has 
>> the *caller* initiate the callback.
>>
> This sounds like presence, possibly staged in some "queued" order. Does 
> the caller get to choose "dial now or abandon"?

There is a small aspect of presence involved, in a very loose sense.

What happens is that when the target becomes free the top caller in the 
queue gets alerted. If that is answered quickly enough, another call 
attempt is made. If not, then I think that caller is removed from the 
queue - hence an abandon.

At least that is how I remember the telcordia version of the feature 
working.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Apr 2007 12:29:57 -0400

> What happens is that when the target becomes free the top caller in  
> the queue gets alerted. If that is answered quickly enough, another  
> call attempt is made. If not, then I think that caller is removed  
> from the queue - hence an abandon.
>

This sounds like regular presence, except that NOTIFYs are staged in  
queue order and have a short validity period. If no call arrives, the  
proxy just sends the next NOTIFY.

> At least that is how I remember the telcordia version of the  
> feature working.
>
> 	Paul