Subject: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 19:00:11 -0500

This is a very interesting draft. Neat idea to use BFCP to manage the 
queue.

Its not clear to me that this mechanism works well in the face of 
forking. Seems like you could end up with disparate queues for each of 
my phones. What you are really after is the state of the user (i.e., 
AOR) and not their devices. This seems to make it problematic to 
implement this in the UA at all. I understand your intention is that 
this be in a server in the network; but if it only works in that case it 
needs to be called out.

Similar issues arise when the originating user has multiple devices. So 
if I call you from phone 1, and later you are available, does the 
ringback happen only at phone 1 or all of my phones? Seems like the 
latter is much more desirable. That too implies that a UA-based solution 
on the originating side has some problems.

There is clearly a relationship between all of this and presence; I 
think you need to call that out.

On whether BFCP is the right thing or not for this problem, I'm not 
sure. In one sense, you could characterize this as really a problem with 
RFC3265 in general; that for certain event packages, notification of an 
event to all watchers can cause them to take actions that result in a 
further change to that same state. This is a race condition.

An alternative way to model the queueing discipline to fix the race is 
through a generic capability in RFC 3265, which sends out notifications 
gradually. You need to be careful to not end up embedding queue control 
commands in SUBSCRIBE as you have pointed out previously. However, 
nothing stops a notifier from sending out notifications one at a time. 
That would not permit you to do things like pause your position in queue 
or similar features, but 3265 sometimes feels to be more on-target for 
this service.

I share John's concerns as to whether this really interoperates with the 
PSTN. Perhaps if you had some call flows demonstrating it, this would help.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 2 Nov 2006 16:19:29 +0100

Hi Jonathan, all,

I don't think that there really is a relationship between presence and call completion. Presence is about the general availibility of a certain user, call completion provides the possibility to complete a call to a certain destination you've got a busy error response from. Because of this busy indication it is clear that someone in principle can be reached at that destination, and with call completion this will be acheived as soon as the destination user hangs up the receiver, of course depending on your position in the queue. Perhaps there will be another person at the phone then you wanted to talk to, but at least you will get an answer.
 
I don't understand the problem with the notification and the race condition. I thought there would be a seperate BFCP session for each outstanding call completion request. And so the BFCP server at the callee could grant the floor for the user at the top of the queue independently from the other requests. Did I misunderstand this?

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Donnerstag, 2. November 2006 01:00
> An: IETF Sipping List
> Betreff: [Sipping] comments on draft-roach-sipping-callcomp-bfcp-00
> 
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 02 Nov 2006 09:43:05 -0600

Jonathan Rosenberg wrote:
> my phones.

That's pretty much what I intended, yes. As far as I can tell, the net 
result -- that is, the behavior of the system -- would end up being 
identical (or, at least, substantially the same) with queues maintained 
on each of your devices versus a single, centralized queue -- unless 
there's more than one of you, in which case neither solution will behave 
particularly gracefully (although I believe the forking setup has better 
recovery properties under such circumstances).

When I get a spare moment, I'll work through a few scenarios to 
demonstrate how the externally observed system behavior is the same 
between distributed management of several queues and centralized 
management of one queue.

> Similar issues arise when the originating user has multiple devices. 
> So if I call you from phone 1, and later you are available, does the 
> latter is much more desirable. That too implies that a UA-based 
> solution on the originating side has some problems.

That depends. Are you asserting this as a new requirement? No one has 
raised this capability as a requirement so far, and the previously 
offered solution certainly didn't have this property.

To be clear: I agree that this is probably an improvement on the 
service; however, the more requirements we pile on, the harder a 
solution becomes -- and we've become experts at putting so many 
requirements on a problem that the solution space dwindles down to nothing.

> think you need to call that out.

Martin beat me to it, but I'll reiterate his comment: the relationship 
here isn't related as much to presence as it is to dialog state. And 
that is called out in the discussion about centralized queue management.

> sure. In one sense, you could characterize this as really a problem 
> with RFC3265 in general; that for certain event packages, notification 
> of an event to all watchers can cause them to take actions that result 
> in a further change to that same state. This is a race condition.

Not in general -- this race condition arises in the draft-poetzl 
document because it's doing something with SUBSCRIBE that SUBSCRIBE was 
never meant to do: changing the state of the thing that is watched.

Let's go back to first principles: SUBSCRIBE is a request to retrieve 
the state of a resource, and receive that state whenever it changes. 
It's a way for an observer to *LOOK* at a state.

Now, as I'm always having to tell my kids: you look with your eyes, not 
with your hands. If the act of subscribing to a state changes that very 
state, then you're no longer looking -- you're touching. SUBSCRIBE 
doesn't touch the state it's monitoring. (Now, we have defined some 
*meta* state regarding the very state of that subscription, but you need 
to subscribe to that separately, and the act of subscribing to that 
meta-state doesn't change the meta-state).

If you violate the basic principles on which a protocol was developed, 
then, yes, you end up with protocol characteristics that are highly 
undesirable. The race condition you describe is one. The objections that 
I have repeatedly raised with the "abuse" of SUBSCRIBE to activate a 
service aren't purely academic: if you use a protocol in a way that is 
well outside its original design, then clearly identifiable bad things 
happen.

> I share John's concerns as to whether this really interoperates with 
> the PSTN. Perhaps if you had some call flows demonstrating it, this 
> would help.

Martin has put together some pretty nice call flows showing how this 
interoperates with the PSTN. Perhaps he could be convinced to share them 
with the wider group?

/a

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 3 Nov 2006 13:52:24 +0100

Hi,

I have drawn two basic flows for a PSTN interworking, available at 
http://www.softarmor.com/sipping/drafts/Roach%20Call%20Completion%20interworking.pdf.
I think they show an interwoking according to Adams proposal, Adam please correct me if I'm wrong.

The interworking itself seems to be feasible to me, but looking at the flow where CCBS is invoked in the PSTN, I share Johns concern that the call completion INVITE (or respectivly the IAM with the call completion indication) has to be routed exactly via that MGC that has the function of the BFCP client and that handles that specific GRUU/GRID instance, and it's not determinstic that this will be the case in the PSTN as far as I know.
It has to be that particular MGC, because only this MGC knows the GRUU/GRID and could interwork it because of the IAM Calling Party Number and CCSS indication. 

So at least from a PSTN point of view there would be an advantage if the call completion call could be handled independently from a specific GRUU/GRID, perhaps as a kind of fallback mechanism for an interworking with networks that don't support GRUU.

Regards, Martin

> Von: Adam Roach [mailto:[email-masked]] 
> Gesendet: Donnerstag, 2. November 2006 16:43
> An: Jonathan Rosenberg
> Cc: IETF Sipping List
> Betreff: Re: [Sipping] comments on 
> draft-roach-sipping-callcomp-bfcp-00
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Nov 2006 17:40:08 -0500

Huelsemann, Martin wrote:

> Hi Jonathan, all,
> 
> I don't think that there really is a relationship between presence
> and call completion. Presence is about the general availibility of a
> certain user, call completion provides the possibility to complete a
> call to a certain destination you've got a busy error response from.

I completely disagree.

When you invoke the CCBS service, the ringback you get when they are 
"available" is exactly presence. However, in the PSTN, it is limited to 
the only concept of presence they have - whether you are on a call or not.

In an IP world, I can be unavailable for voice service even though I'm 
not in a call strictly speaking. For example, if I've got five parallel 
IM sessions, and as a consequence, I set my voice service to "closed" 
through presence, what is the desired behavior of the SIP-based CCBS 
system? I would assert that I *dont* want the callback to come now. If 
it does, I won't answer it anyway since I'm busy with other things. So, 
the call goes to voicemail or goes unanswered. That does not seem like 
the desired behavior.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Nov 2006 17:40:08 -0500

I completely disagree.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Nov 2006 22:07:18 -0500

amen.

Going further, being in a call (even a voice call) doesn't mean that I'm 
*not* available to take another call. This is a place that they never 
got the feature interactions right - namely with caller id. It may be 
that you are the person I most want to talk to, but when you tried to 
call me before I was already involved in two calls and just didn't have 
a way to manage another. Later I am only involved in one call and would 
be thrilled to have you call me back.

Presence provides ways to say all of this, and so it could be a great 
way to provide a "better" version of this feature than is available in 
the PSTN.

What it doesn't easily do is provide a faithful emulation of what the 
PSTN does. Providing a faithful emulation seems to be incompatible with 
providing a more interesting and potentially more useful implementation 
in the new world of more capable devices.

	Paul