Call Completion using BFCP draft-roach-sipping-callcomp-bfcp IETF 67 – San Diego November 7, 2006

Overview Uses requirements from draft-poetzl-sipping-call- completion-01 Uses normal SIP option tags to indicate support and negotiate use Uses BFCP (hopefully RFC 4582 by now) to place callback requests in queue, and manipulate the queue Uses RFC 3087 techniques to prioritize incoming call completion calls over other calls, correlate caller with previous call attempt. Feedback so far has been strongly (although not unanimously) in favor of this general approach.

Why BFCP? Requirements from draft-poetzl-… include specific semantics around queue management No existing SIP methods inherently deal with queue management BFCP is semantically congruent with the problem: several users need to be granted exclusive access to a single resource in a controlled fashion

Issue 1: Conveying URIs Current draft uses Contact header field in a provisional response to indicate where to send INVITE for BFCP session. Current draft uses Contact header field in 200 response to INVITE (for BFCP session) to indicate where to send INVITE for call re- attempt. The solution is intended to allow dedicated servers to provide the service, but the preceding behavior gets in the way. Also, this is arguably an abuse of what “Contact” was supposed to mean in the first place.

What’s This Server Stuff? CallerProxyServerCallee INVITE Busy Here ACK INVITE (for BFCP) 183 Conveys URI for BFCP Session 200 BFCP SessionDialog Subscription BYE 200 Proxy Forks INVITE INVITE ACK Initial Call Attempt CCBS Service Activation Call Re-Attempt Something in here must Convey URI For INVITE re-attempt

So, What’s the Problem, Then? CallerProxyServerCallee INVITE Busy Here ACK INVITE (for BFCP) If this 200 Conveys Callee URI in Contact, then ACK and BYE go to the wrong place 200 BFCP SessionDialog Subscription BYE 200 INVITE ACK Initial Call Attempt CCBS Service Activation Call Re-Attempt

Issue 1: Options 1.Convey re-attempt URI in BFCP –Unfortunately, this doesn’t fit well in with what BFCP does 2.Add new header field (e.g. “To-Recall:”) –Service-specific header field is a bit outside “the SIP way” of doing things –Recall Dave’s “To-Explode-My-Phone” rant. 3.Put it in a REFER?

Issue 1 Proposal: Use REFER CallerProxyServerCallee INVITE (for BFCP) 200 BFCP SessionDialog Subscription REFER 200 INVITE ACK CCBS Service Activation Call Re-Attempt BYE 200 REFER Conveys Callee URI

Issue 2: Endpoint Queues vs. Server Queues BFCP Session

Issue 2: Endpoint Queues vs. Server Queues BFCP Session Dialog Subscription Dialog Subscription

Issue 2: Endpoint Queues vs. Server Queues Current mechanism works with both User Agents and Servers maintaining call completion queues. User experience is identical or substantially similar regardless of where the queue lives, or how many queues exist We could artificially constrain solution by making an unnecessary MUST-strength prohibition against one of these modes of operation – but why would we? In particular, keep in mind that we define protocols, not architectures. Artificial architectural prohibitions seem outside our jurisdiction.

Issue 3: Feature Creep Several people have raised additional potential requirements, beyond those expressed in draft-poetzl-…, and well outside the capabilites of any solution offered so far; e.g.: –What if the caller owns several devices? Is it a solution requirement to let all such devices know when a callee of interest is available? –What is the callee owns several devices; he hangs up one and then runs away from it but can be contacted on a different one? It is a solution requirement for the call completion call to track them down on a device other than the one that they just touched? How hard do we want to make this? We can continue to pile on requirements until the problem becomes unsolvable.

Issue 4a: GRUUs The draft currently doesn’t require GRUUs, although it suggests their use so as to allow callers to address individual callee terminals when setting up BFCP sessions. Apparently, the suggestion that the mechanism is compatible with, and even enhanced by, GRUUs is causing significant consternation. Do we need to do something here? I think this is just a matter of people not having enough time to read the draft carefully yet.

Issue 4b: Caller Correlation Most of the issues people have raised with GRUUs isn’t with the GRUUs themselves as much as the requirement to hold on to a URI that is used for the call re-attempt at some later point. This issue arises (only) in the PSTN interwork case – which is one of the key drivers for the service. Currently, the URI lets the callee know two things: 1)That the incoming call is a call completion call, and 2)That the caller is the same entity who was just granted permission to re-attempt their call. Without this, it is very easy for me to “jump in line” ahead of you. (Except in closed-garden networks)

Issue 4b: Caller Correlation The problem is that this IAM may go to a different gateway than this one does.

Issue 4b: Caller Correlation PSTN Gateway Correlation URI is sent here during call completion service activation remoteUserFree IAM How does the correlation URI get back here? Ring Answer Callee Caller

Issue 4b: Is This Really a Problem? PSTN Gateway remoteUserFree IAM Correlation URI Conveyed Ring Answer Callee Caller Correlation URI is sent here during call completion service activation Stores URI Gets URI Keep in mind that this issue arises only when these gateways are in the same administrative domain… …which means that we can trivially put a shared database here.

Issue 4b: Proposal Leave the mechanism as-is

Issue 5: GRID is gone from GRUU Because the called party uses the URI from a request to determine that it is a call-completion re-attempt and to correlate the attempt with the proper BFCP session, we need to have distinct URIs for each pending caller With non-GRUUs, this is easy to fix: information can be squirreled away in the user portion of the URI GRUU user portions can’t be fiddled with.

Issue 5: Options 1.Get a new GRUU from the registrar every time someone calls, with the same contact for each –It’s a bit heavy weight –While we can correlate users, we lose the ability to store state in the user portion – that is, the registrar chooses the entire URI, instead of the user agent –Requires callee to hold on to state between informing caller of availability and caller re-attempting call (so we’ll need to run a timer). 2.Get a new GRUU from the registrar every time someone calls, with a different contact for each, and use the user portion of the contact to store information (taking advantage of proposed loose routing semantics) –It’s a bit heavy weight –I think it results in incoming calls to the user’s AOR forking off to the user agent multiple times. 3.Add new “cookie” parameter to URI for use with GRUUs. 4.Go back to having GRIDs